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)
> > ... 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
As a lecturer, Python would be my other choice, nowadays, for a small surface area language.
I suspect Go has the advantage here simply because it barks at you at compile time over certain errors. Pedagogically, something that students have to run that checks the syntactic validity of their program is probably win.
I emigrated from Lisp->C->Tcl->Perl->Python over about 30 years and Python is still the thing I reach for when I have to whip up a program (yeah, Lisp was nice but I could never afford a machine with enough memory for it not to be a toy--memory was expensive at one point, you youngsters).
Go doesn't really interest me that much. It's a little better at a broad range of things, but nothing that pulls me from the existing set of languages. I'd rather use Erlang for concurrency, for example. Maybe if I had Google-sized codebases I'd care more.
Rust interests me because it is in the same range as most languages for most things but is a LOT better at a very few things.
I'm waiting to hear somebody use Rust in a video game engine. I suspect that C++ will vaporize (one can hope) once someone proves that Rust works in production.
Yeah, Python works too, though Go is great at concurrency in a way Python isn't (we were spawning loads of goroutines for tests without any issue, for example, and channels are well supported) so it fits better.
I too am a Python fan for scripting though :)
> Rust interests me because it is in the same range as most languages for most things but is a LOT better at a very few things.
Me too, for similar reasons. It's like C++, but without all the stuff I didn't like about C++ :)
> I'm waiting to hear somebody use Rust in a video game engine.
The ability to use OpenGL in a way that doesn't suck would be nice. Thanks for the pointer.
I need to think about this a lot. I've got a particular project in mind (VLSI design) and the thing that has always stopped me is that the UI toolkits can't deal with concurrent actions. OpenGL and multi-threading are asking for disaster with C/C++.
Rust might let me break that logjam.
Clojure was close, but JOGL still remains a disaster.
"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."
Yes, but by definition, we're discussing optimized code here.
As I said and will repeat without blinking, Rust will always be faster than Go (and the problem in the shootout Go beat Rust on is in my opinion certainly simply an unoptimized Rust implementation, no question), but language deltas of 2x or 3x in practice are dominated by algorithms and IO far more often than 50-100x. For all the long list of reasons that Rust is faster than Go, all of which are true, they add up to much less than developers are used to. Intuitively, when you hear "go is slower than Rust because vtables and bad optimization and GC and its pauses and interfaces" you probably mentally expect Go to be like 10 times slower, when instead it's 2-3.
This is relevant because I don't think Rust advocates should sell "speed!" too hard as the primary thing they have... C++ will pretty much forever be able to keep up on the raw speed front, especially in benchmarks. What it has is complexity management, at speed. But complexity management first.... Rust could probably take a straight-up 2x speed penalty over C++ and still write a renderer than ran faster than C++, because it'll be a better renderer.
> ... 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)