[peterevans]

Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old.

Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++.

(Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.)

What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.

[nordsieck]

> What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land.

One of the less talked about reasons Go is successful at replacing these languages is the devops story - essentially no runtime dependencies.

[candiodari]

This can be easily done in C and C++, by static linking. In java, by building custom jars. This is in fact common practice in large companies, for exactly the reason you mention.

[segmondy]

Go has replaced C/C++ in some circles.

Go look at most recent go projects. Kubernetes will never have been done in PHP/Python/Ruby. It would have been a Java or C++ project. Same with cockroachDB, Docker, Etcd, Fleet, Lime, InfluxDB, Prometheus, etc.

[stochastic_monk]

I think Rust will stick. Until its metaprogramming abilities can match or outpace C++ and be as fast, it won’t replace C++. I do expect it to replace a lot of Java use cases, and perhaps some Go.

[sanderjd]

> Generics may not make a huge deal for you because there were no generics to use in those other languages.

While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.

[peterevans]

Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade.

If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.

(Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)

[marcosdumay]

> is memory-safety the killer-app feature that makes people want to use Rust?

There are algebraic types with pattern matching, sane generics, actually good type inference, strong types that will help you declare behavior only once (as in normal vs. modular arithmetic), and a huge push for not having undefined behavior (that is mostly but not completely successful).

Any of those (and yes memory safety) would be enough of a killer feature on my view. There are still some things I dislike in Rust, but compared with C it's a complete no-brainer.