To me the question in the title is as ill posed as would be "Choosing Between C or JavaScript?".
To me the question in the title is as ill posed as would be "Choosing Between C or JavaScript?".
And let me explain. This guy has been "at a startup" and "at a Golang Meetup." If that isn't thought leadership, I don't know what is.
Good point.
It's a very light article, written for people who listen to Thot Leaders. It misses most of the important points.
Go is designed for web back ends. It has all the stuff you need for that, and the libraries have been thoroughly pounded on and debugged, because Google uses them internally. The language is stable and doesn't change much. It's a good fit to that job.
For other applications, Go may or may not be a good fit. Desktop apps? Probably not. Games? Probably not. Real-time control? No.
Rust now seems to be trying to use every cool idea around, all at once. The borrow checker was brilliant. The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! We have a whole bunch of different HTTP libraries! We've changed the error handling system how many times now? It's all very cleverly done. But it's overdone. I'm out of that world, and not clear on whether there are signs of it settling down yet.
That's a completely different industry, I think.
> The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async!
Generics, lambdas, and threads are must-have basics. Futures and async are the same thing. Rust doesn't "have functional programming", unless you mean chaining `map` and `collect` methods, in which case Java also has functional programming.
HTTP and error handling are third-party libraries. Multiple choices in this area are a direct result of not trying to bundle the kitchen sink with the language. These things don't standardize in a year.
This is a process problem. The development process for Rust does not seem to force convergence.
[1] https://hackernoon.com/programming-in-rust-the-good-the-bad-...
Among the Rust ecosystem things to gripe about, this is a odd one.
async_std vs. tokio is the real split-investment battleground these days, effectively undermining the async/await momentum right as it gets out of the gate.
- heavy Go marketing, which (intendedly or not) makes devs think that Go is "great at everything": you can't tweak memory management? that's a feature¹.
- simplified/misguided categorization into old language models: Golang is the new C, Rust is the new C++.
I think with a long enough time, the roles of the two languages will become significantly clearer.
¹: to clarify, that's a feature in some contexts, but not in others (therefore, not appropriate for "everything").
I also expect this to be the case. But when I try to think of historical context, I come up blank. Was there this much polarization between languages in the past? I remember similar rumblings between Java and C# like 15-20 years ago, but that had more to do with the corporate backing and licensing IIRC. This feels more like political/tribal arguing.