Aside from the head start, I believe Go legitimately hits a sweet spot for developers wanting a language that's relatively easy to use yet also fast and fully compiled.
Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot.
The former audience is probably larger than the latter. But popularity isn't everything (JavaScript wins that contest ;)). The important thing is Rust is doing an amazing job in an area that hasn't seen much love.
Personally... I used to write Java and Python code (and enjoy it), but fairly straight forward code would just bog down on me. On the other hand, C and C++ code would always crash in frustrating ways.
Rust hits the sweet spot of not being a pain in my ass all the time.
> I know a bit of C, but not enough to feel like I can effectively use it
I love what the Foreward [1] in the Rust Book has to say about this:
"Traditionally, this realm of programming is seen as arcane, accessible only to a select few who have devoted the necessary years learning to avoid its infamous pitfalls. And even those who practice it do so with caution, lest their code be open to exploits, crashes, or corruption.
Rust breaks down these barriers by eliminating the old pitfalls and providing a friendly, polished set of tools to help you along the way."
Well, every two languages are different, but at least for systems programming, Golang unfortunately started to replace Python, but given how vitally important security is in that domain, Rust makes a lot more sense than Golang, won't you agree?
I don't think "systems programming" is a coherent concept anymore, so I'd reject the premise of the question. Go has already moved away from that word, Rust will be as well.
That you see them as being so different languages reinforces my premise above; they're good at different things, so comparing them doesn't always make a ton of sense.
Once you start putting "systems programming" and "Python" in the same sentence you can be pretty sure that the term "systems programming" has lost all meaning. Or at least using it without elaborating is only going to end up in confusion.
Perhaps one could say that about systems programming languages as well, including Rust. It'll be slow(er) to develop, and there will be much wailing and gnashing of teeth.
The word "systems" is increasingly relegated to a smaller fraction of the codespace than used to be; one wouldn't have considered building a high frequency trading system or a call handling system in a non C/C++ language in the mid 90's, but Java and Erlang get the job done well enough.
As always Alan Perlis said it best (in his "epigrams of programming"):
A programming language is low level when its programs require attention to the irrelevant!
gVisor is a security product (
Container Runtime Sandbox ) made by Google in Go and runs in production so I'm not sure what you mean by "how vitally important security is in that domain".
a) In terms of memory safety, Go is not memory safe in the presence of data races, and Go does not prevent data races at compile time.
On top of this Go does not enable ASLR on most OS's. That means that when Go loads code from other languages, such as C/C++, memory safety issues in those languages are extremely easy to exploit relative to in a language like Rust, which enables tons of mitigation techniques by default.
b) More loosely, Rust has a more expressive type system. It is, in my experience, much simpler to enforce constraints in a 'type driven' way. In my opinion, this leads to safer software.
As an example of (b) I have written authentication code that encodes the authentication protocol's state machine into the Rust type system. What this means is that it is impossible to jump between two states in an undefined way. Beyond that, because of Rust's affine type system, it is impossible to reference invalidated states.
For authentication code, especially when you add complex stateful transitions such as rate limiting, whitelisting, etc, this is an extremely effective way to reason about your security critical code.
I think there is a case to be made that there is a real, significant difference between the languages regarding security.
One could make an argument about data races, for example. Rust prevents them at compile time, Go does not.
You could also make an argument about compile-time guarantees more generally.
I'm not sure it's really a great argument, but you could make it. I think the parent's statement that it's only Go because it's made by Google is demonstrably false.
I'd say on the contrary. They chose it even while knowing they'll gonna need to hack generics. (Same in k8s, generics hacked together in a few different ways)
Also Go's 1.0 predated Rust by about 5 years. They started around the same time, but many people won't use a language that's not stable where their existing code may break with each new release. Go has had a ~5 year head start in developing a library ecosystem, tooling, commercial users, etc.
It takes a long time for a language to build momentum and a user base. Python was just starting to get popular when I graduated from college in 2005, and it was already 16 years old at the time.
This is true, but even today in 2018, Golang still suffers from the dependency-management hell, the notorious GOPATH, and many other issues it should not have being almost a decade old! Even Rust, which some call "lower-level language", which it is not, has Cargo after it learned from Ruby and Node how important is to have easy package management, and being able to install a new project without knowing almost anything about the language.
totally fair, but Go did stablize the language itself. i can with zero effort and 100% confidence run any old Go code i have lying around. that's pretty awesome.
I do a fair amount of Rust and Go, and I am not sure what axis you refer to with the phrase "killing". (Unless it is killing joy, for a lot of people </snark>)
Most apps out there are extremely serviceable with a language environment that runs up to 2x slower than what is possible with Rust. Youtube, edX, reddit, coursera all run on python, Facebook on PHP/Javascript, WhatsApp on Erlang.
In exchange for ceding low-level control, these languages provide a frictionless approach to evolving a system. You get dynamic features that are simply wonderful for creativity. Javascript is a blot on the landscape, but look at the effortlessness of d3.js.
GC is wonderful and does not gets in the way for most apps (from mobile to enterprise). Any time spent thinking about lifetimes sucks the fun out of coding. Lifetimes are fantastic for concurrent programming, no doubt, but there are simple patterns in Go that work well in practice.
Lightweight threads remove another point of friction; they allow you to model the concurrency inherent in a problem without much trouble. I'd prefer Go to get more of Erlang's failure handling and signal delivery mechanisms.
Go is a middling language, but its libraries and ecosystem are solid and have a coherent feel. They work out of the box without having to consult StackOverflow a zillion times.
The language I would love to have is Swift retrofitted with Erlang's process system.
Letting GC take care of lifetimes is a big plus for many applications. Rust's ownership model buys you a lot --- no GC overhead (space, not just time), fearless parallelism, more powerful static invariants --- but it costs you development effort, and depending on your application the costs can outweigh the benefits.
Rust improvements like NLL will hopefully reduce the costs. I think we will discover more ways to leverage the benefits, over time. However, I also think it might be interesting to let people opt into a Rust dialect that hides lifetime issues, e.g. using a lot of implicit Rcs and (Ref)Cells.
If the Rust ecosystem was up to snuff on the HTTP front, I'd be writing a lot more of it. At the moment, Go's HTTP implementation is just pretty much unbeatable. I'm confident it'll get there — and there's a ton of great work going on to get it there — but at the moment, it's still the Wild West.
Go also hits the sweet spot for CLI apps, in my opinion. The error handling is obtrusive and annoying otherwise, but for command line apps where you're just aborting whenever you hit any kind of snag, it's not a significant pain point.
I think this is a pretty major piece as well. Go was introduced many years earlier, backed by Google marketing and had strong HTTP services as a day one feature; it was designed for probably the most popular use case by perhaps the most influential fount of new tech. Given all that has Go really done all that well? Has it gone much beyond network services and a couple other niches (Docker/K8s etc?) It's not really displacing C/C++ in 'systems' use cases. It's not a go-to language for Machine Learning. The runtime+GC obviates most embedded work. You don't see any meaningful uptake of Go among Google's peers; Apple, Microsoft, Oracle, etc. I wonder just how important Go really is.
Frankly I don't know if Go passes any barometer for "important". I don't think it's significantly disrupting any particular space, so if that's the measure of a language's importance, I don't think Go's quite meeting that. I find it unlikely it ever will.
I don't think it was ever intended to be important in those terms, however. It was designed primarily to solve specific sets of problems at Google, but I don't think any sights were set on the C, Java or other related language worlds at large. From that perspective, I would argue that Go's actually been fairly successful.
I'd argue the Rust team is much more eager to be a real disrupter. I think in that sense, they're succeeding in ways and have not yet achieved success in others.
> Given all that has Go really done all that well?
My intuition is that the only languages that have grown faster are those that were blessed as "native" for a popular platform. For it's age it seems to be doing really really well.
But given Go's mix of advantages and disadvantages, should we expect it to be doing better? I doubt it.
Still to be seen if it becomes a Ruby or a Java, though.
Hyper 0.12 is right around the corner with the excellent h2 crate. We've been using the master branch on production the whole 2018 and it's super fast, stable and ergonomic.
Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot.
The former audience is probably larger than the latter. But popularity isn't everything (JavaScript wins that contest ;)). The important thing is Rust is doing an amazing job in an area that hasn't seen much love.