That’s kind of true, but I came from Go, which has really fast compile times, which makes it really productive.
That said, I don’t use Go much anymore, so I’ve obviously found some value in Rust. I would like to see improvements though, but it’s fast enough for me to stick with it.
On the other hand in Go you have to literally implement every other standard library function inline yourself because of its lacking expressiveness and it is total cancer to read, at least in the cases of the Go programs I looked at to debug some things which I wouldn’t really consider productive.
standard library
The standard library is absolutely massive, so it has pretty much everything you’d need.
expressiveness
The syntax is so simple that there are rarely any surprises. Yeah, it’s not very expressive, but that’s a feature, not a bug, because I’ll pretty much never run into a clever bit of syntax that takes me time to understand. There’s a very strong idiomatic style, and quite often “one right way” to accomplish something.
if err != nil { return err }
will appear all over your code, but after reading and writing a lot of Go, it’s not distracting anymore.
That said, I do have criticisms that lead me to avoid Go:
- no protections against data races - no
Mutex[T]
,map[T]U
isn’t atomic, etc interface{}
being an container instead of a compiler hint - this means(*int)(nil) == nil
butinterface{}((*int)(nil)) != nil
; that has caused so many bugs- no destructors - automatically closing files, mutexed, etc
- can copy beyond the end of a slice, overwriting data in the backing array
I could go on. My point is that there are far too many footguns for a language that’s designed to be simple. However, once you know what you look for, Go is really easy to read and write.
That said, I don’t use Go anymore and write mostly in Python and Rust, Python for the prototypes/scripts, and Rust for anything I want to maintain longer term. I’m not looking for a middle ground anymore, but if I was, Go is really productive and easy to read, while having nice syntax for smaller microservices.
What I had in mind when talking about that standard library thing was one case in particular that I had found where someone had to implement deduplication of elements in a vector/array/list (or whatever Go called it, don’t remember that bit) locally because Go does not support function generic over the type of container element.
And the whole if err != nil { return err } bit is a huge part of what makes Go code unreadable. I have also found at least half a dozen bugs related to that construct where people just did not print any of the relevant information in error cases because of the lazy copy&paste of that construct in cases I had to debug.