Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Google has been steadily moving away from "Go is a C++ replacement" (because it's not) and toward "Go is a Python/Ruby replacement." (which fits it _much_ better)

Also, you're descriptions of Go and D are great, but I'd say that Rust is more "Concurrency of Erlang, speed of C++, type safety of ML/Haskell".

View on HN

> Google has been steadily moving away from "Go is a C++ replacement" (because it's not) and toward "Go is a Python/Ruby replacement." (which fits it _much_ better)

I don't see that Go is particularly good general replacement for C++ or Python/Ruby, it seems more of a good tool for the place where Python or Ruby's performance characteristics and less well developed support for concurrency/parallelism make them unattractive, but at the same time the relative heaviness and complexity of C++ makes it unattractive, and so neither seems to be the right choice.

I think we're in violent agreement. I think people have been building stuff in Python/Ruby, and are seeing some of the drawbacks, and realize they're bigger than they thought.

Go is not particularly DRY. It's an entirely different design, not a superior version of the same thing.

Where does language like Dart fall into?

Dart has a broadly similar server side role to Go (the approach is very different) in that it falls between C++ and currently popular dynamic languages, plus it has a client-side role where it aims to be a better JS.

Obviously on the server side it overlaps with Go, but Google has the resources to do multiple efforts in parallel in areas they think are important to find what works best with real world experience.

In the history footnotes, unless Google manages to convince other browser vendors to adopt it.

Its a replacement for Java. C++ is still suited for situations where GC is impossible, Python/Ruby are still suitable for quick scripting. I think Go aims for everything in between.

I quite agree with that. Java & Go have a close typing system (static but not very elaborate, and java < 5 was lacking generics just like go), share a close philosophy (a simple language with no tricky corner, safer memory management, designed for programming in the large), have built-in concurrency mechanisms, and are even quite close when it comes to raw performance.

The history of many of the languages has been the same in regards to generics. C++ didn't have them, then templates where added. C# 1 didn't have them, but were quickly added (correctly) in 2. D didn't have them, later they were added. It is very common for a new language to avoid generics in the beginning, but it seems most come to agree, it was a mistake.

C# had them already internally in 1999, before the 1.0 release, they just decided to focus on other issues for the first release of .NET.

http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...

On the functional languages world, parametric polymorphism has usually always been part of the first versions.

I'm not sure that this is a distinction (C++ vs. Python replacement) that means all that much.

For me, it helped me get less mad about Go. ;)

A Python replacement accepts that GC is mandatory, while a C++ replacement needs to not have a GC, as the most prominent example of this distinction.

For some use cases that would matter, but for a lot of C++ use-cases, no GC isn't really fundamental. Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory. For those kinds of applications, how D's GC compares then just becomes a matter of performance tradeoffs between different GC implementations, not a matter of GC vs. no-GC.

Absolutely. GCs have been improving a lot over recent years, and there's lots of software that's written in C++ that doesn't have to be.

You can write D without any GC at all, though: you lose a lot of the standard library at present, but I've done it. It's not possible, in my understanding, to turn the GC off in Go.

Set the env. var. `GOGC=off`.

D provides a little bit more control.

http://qznc.github.io/d-tut/memory.html

> Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory.

Which large codebases? This is definitely not true for any of the browser engines (Gecko being the smallest at 6M LOC, and going up from there) for example.

WebKit makes relatively heavy use of reference counted objects, though a custom reference counting implementation is used rather than std::shared_ptr. That said, there has been an increasing emphasis on preferring unique ownership to shared ownership of objects where possible.

I'm a little confused by your throwaway comment about Gecko being the smallest browser engine though. WebKit weighs in at less than 3 million lines of code, much smaller than the size you quote for Gecko.

Yeah, I was thinking Chromium when I wrote that and should have been more specific. 6M is all of Firefox.

And Gecko uses reference counting a lot too, of course... but most objects are stack allocated or uniquely owned. It's a very different situation from a language in which all objects are reference counted.

It shouldn't be the standard way of managing memory; it should be a part of the toolkit. In order, it should look like:

1) Stack allocation 2) std::unique_ptr 3) std::shared_ptr

You should be properly thinking about onwership semantics, and unique_ptr should be the default, not shared_ptr.

From what I've read, google is using Go to replace many of their C++ systems. While it may have been developed independently, I still consider this enough rationale to be a "C++ replacement". Of course, C++ currently occupies so many different roles, that the term "C++ replacement" is not very specific. I appreciate your point though, it has many more properties in common with python/ruby.

Absolutely: there are many programs which _were_ being written in C++ which didn't necessarily have to, and Go does have a place there. What I mean is that where C++ is a _requirement_, not a preference, Go won't make inroads.

If rust is that, and I suspect you may be right, I'll be putting some serious time into it. pcwalton, could you comment on whether or not you also feel this accurately describes rust?

Reply on news.ycombinator.com