Go is very well documented: That was the killer feature for me.
No more search tutorials / videos etc. - just get the go book, read it, and start coding.
Of course there are tutorials and videos everywhere for fun stuff.
But good documentation is more important than we think - even in the 21st century!
First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve.
But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs).
The problem to me with the Rust "no stdlib" model is it leaves you with two equally unattractive options:
1) Write the library yourself (and leave yourself with the associated technical debt of maintaining it)
2) Figure out which of the often dozens of third-party Rust crates you want to use (and rinse and repeat the selection process for every library, and then expose yourself to third-party maintenance debt).But back then? Yeah, I was kind of expecting one of them to "win".
They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them.
The "best language for the job" is mostly a myth.
The choice of language is mostly dictated by what you cannot do, rather than what you can do.
Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit.
If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation.
The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work)
So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
You'd be surprised actually. Java Card is actually designed for memory constrained environments. It's not as featured as Java itself but it uses the same language syntax and class file format.
What's moving the scales in favor of Go, for me, is Rust's borrow checker. I'm aware that it has a bunch of advantages over a garbage collector, but those are paid for with a pretty noticable productivity hit that doesn't seem to go entirely away with experience either; experienced Rustaceans I've consulted with less-common patterns still spent a lot of energy finding a way to make them work with the borrow checker and still sufficiently efficient, and most of that could have been saved for more productive work in a language more open to existing design patterns. Usually I'm neither out for the maximum safety at all costs nor resource-constrained, so I'd rather take Go-ish levels of safety and Go-ish performance and get work done faster.
If there was a Rust with a first-class garbage collector, but keeping all the neat functional elements, the neat semantics, the great libraries and ecosystem, strong types, single binary etc. pp., I'd pick that right away. Go is "easy" at the cost of expressiveness to a degree that makes for reams upon reams of repetitive code or code generation, and Rust-ish functional patterns could greatly condense that and make much more readable, at the expense of having a somewhat higher learning curve. That's a trade-off that I'd much prefer, reading and reviewing Go codebases can be very tedious.
Unfortunately major projects pull on tens of random libraries from the internet which represent real supply chain risk.
People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing those myself isn't all that difficult.
And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.
Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess.
If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation.
Where as with Rust, it's often confusing to the point where if they don't have an examples folder on the library, I'm shit out of luck understanding how to do something.
Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given.
I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo.
Quite aside from docs, Go's tooling situation is also better.
It's not a service they can pull the plug on, it's a software package that would still exist even if the entire Google organization went poof tomorrow. Because if it was a service they could just pull the plug on I would never have started using it.
Anyways, key point was that Google reputation was different, when Go took up. I can imagine if it would launch now it would find different reaction, which could prevent a community forming, thus less of safety.
1. The standard library is very good in the sense it covers a fairly wide range of areas and gives you some idea of how to use Go idiomatically (I feel this is more important in Go than in other languages I've used).
2. The language just feels right to me. I have not met any other language that feels like it was optimized for my brain that well. I recently made an attempt at learning Rust, and I kind of got it, but I eventually gave up because the benefits did not seem worth it to me in light of the steep learning curve. Go just clicks with me. It's not the best language ever by whatever metric you choose, but for my needs, it is the right language.
I'm the same. For me, it was some combination of:
- I can build useful stuff with few dependencies
- I don't have to wait seconds for compilation
- I can trivially build, scp the build artifact, and run it