Fun fact: The professor who asked us to use Go in the course also knew Rust and Nim and in general liked programming languages. When I shared the original versi

Fun fact: The professor who asked us to use Go in the course also knew Rust and Nim and in general liked programming languages. When I shared the original version of this article with him, he said this interesting tidbit (which I agree with wholeheartedly): > ... there is no other language I can think of with such a small surface area that I can tell students in the first week to learn and deliver an assignment by the second week ... > This is pretty much why I consider these two to be in less competition than first meets the eye. Rust intrinsically involves putting more effort in to the code. You put more effort in and you get much more out, but there's a lot of code for which that's not the right tradeoff, just as there's a lot of code for which it is. I don't consider the two to be in competition (aside from "which hip new language should I learn today") either, though it's less due to the easy-to-pick-up thing and the Rust mentality that: - If it can be a footgun, be explicit (unsafe, exhaustive matching, unwrap) - If you can do it at compile time, DO IT DO IT DO IT DO IT (all the compiletime type safety, ownership, etc). All abstractions should be zero-cost or with minimal cost (at runtime). Try to write your code so that tests won't be necessary (because a successful compile should be a test), and then write tests anyway! (This mentality is pretty prevalent in both the Rust stdlib/language and external libraries. The equivalent of interface types in Rust (`Box<Trait>`) is generally frowned upon and only brought out when absolutely necessary, for example) Go doesn't really embrace either of these principles, so it doesn't compete that way. You're right, developers already are used to making those choices. > worrying about Go vs. Rust is going to be a much narrower band of validity before you're just prematurely optimizing. Rather a lot of high performance code still has "vtables" in it, used quite extensively. Not necessarily. As mentioned before, the Rust way of doing things generally leads to a lot of optimized stuff. Taking the vtable example -- Go code that I've seen uses vtabley things everywhere (the stdlib is peppered with interface types). Using vtables isn't bad, but when you use it for stuff that could have been solved by static dispatch (for large codebases -- that can be everywhere), then it can become an issue. In Rust a vtable is a last-resort that people will grumble about before picking up and using (but will use it whenever absolutely needed). Sure, a single vtable isn't much of a performance optimization, but when all your APIs use static dispatch due to this mentality, the collective optimization is huuuge. > In practice, I don't expect many people to decide between Go and Rust based on performance needs on similar code... non-zero, yes, but not many. For many applications, I agree. Systems programming is one where this doesn't apply, but for stuff like a distributed consensus algorithm implementation (which I was doing), both Go and Rust are perfect. And I'm pretty sure that if I'd had more practice in Go, I would have been confused which language to write it in. (Right now I love Rust and am not great at Go so of course I would use Rust if given a choice) For stuff like a browser, it's not so much that there are batshit insane sharing patterns, it's more because a browser is huge and performance matters a LOT. (I think pcwalton above explains why better than I can)