Earlier quoted context omitted.
I'm currently using Go (and Python - we did go from Python 2 to Go, but later continued using Python 3) at work, but for all of the hoopla about it's concurrency, the reality is I'd rather have Rust's superior runtime safety and metaprogramming. A few things have impeded on Rust adoption at work: - Learning curve. Rust is not as bad for learning as C++, but any language with strong metaprogramming and unfamiliar or r…
I kind of like the idea of Rust, but I don't really have much belief in complex programming languages. C++ only has a large following because it piggy backed on C, which people already knew, then it gradually grew its complexity. It is quite a different challenge to get people to use an entirely new language with high complexity. Companies are going to be negative towards adopting a language with a steep learning cur…
I think, rather, C++'s brand of metaprogramming ended up being a big deal. C++ template metaprogramming and now const_expr allow for doing a lot of work at compile time, allowing higher level constructs to compile away to virtually nothing.
That it's compatible with C definitely helps still though, since it means you can still use C libraries and APIs, including the APIs of most operating systems.
In C++ there were programming styles that were "memory safe," relying on a combination of stack based lifetime and 'smart' pointers. While in practice most C++ code is very far from memory safe, I'd say this alone vastly improved software quality over C for big projects.
Rust represents an opportunity to do all the things C++ did right in a fresh language that is actually memory safe and doesn't suffer from the syntax C++ has. To me it's no surprise it was developed by the same people who write browsers - these are people that "get" it when it comes to huge, mission critical codebases. The complexity of Rust isn't a bug, it's a feature.
Go's simplicity is it's biggest strength and weakness, in my opinion. Code generation isn't cutting it as a substition for good low cost abstractions. Don't you hate when you end up in scenarios where you wish things could be typesafe but you realize to get there you'd need to write a codegen? I.E. there's a typesafe GraphQL library for Rust, but the equivalent library in Go will drop you back to interface{} constantly.
I would implore people to try to look past the instinct that simple is better in some cases. There's a balance to strike that yields the best benefits of 'simple' and 'featureful' and I personally believe Rust is closer to it than Go or C++.
I will still be coming back to Go and look forward to Go 2.0, but it'll be hard to look past some of the shortcomings when I'm writing performance critical code and wish I had more safety and control.
(Sidenote: I have a performance critical piece of code at my work written in Go, and it ends up using a ton of memory as a property of the GC. Go's low latency GC is cool, but there are definitely trade offs.)
(Sidenote 2: I wasn't enticed by Swift enough to give it a try, so I have no comments to make on Swift. I'm sure it's fine. It doesn't seem to be what I'm looking for.)