> In a language with closures and Go-style goroutines and channels...
Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.
We're certainly hoping that Rust is that language.
In particular, we're trying to get the raw no-compromises performance of idiomatic C++ in a practical, memory-safe (and data-race-free) language. That means that our type system is more complex than that of C or Go, but it also lets us squeeze performance out of the machine without sacrificing safety.
We do have an optional per-thread garbage collector (it doesn't stop the world, only the thread), but it's more like shared_ptr than what you'd usually think of as a GC; it's there if you want it on your objects, and you don't have to use it.
(Disclaimer: I work on Rust.)
(Second disclaimer: Go is an awesome language and, as this talk illustrates, we aren't competing with Go; Go and Rust have totally different goals and Rob Pike's languages were quite the influence on Rust.)
There are several of those languages too, but they suffer from the opposite problem: not enough differentiation to overcome the inertia, tool support, and installed base of C.
I agree. In the end, it's not really surprising that C/C++ continue on. Replacements either include too much to be a strict replacement or do too little to warrant the change.
Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.