(Edit: As this seems to trigger some people: I code in Rust. I’m just stating the facts.)
It sounds like maybe you're used to skipping part of the development process required for stable well-tested software. Maybe that works for UIs? Wouldn't want my runtime authors feeling that way.
Developers, on the other hand, seem to need some help running static checkers regularly. Most don't seem to have well exercised CI toolchains doing it for them. Or aren't aware that they should be doing so - like yourself.
Rust makes use of the tight integration between language, compiler, and checker to allow the language to be easier and more thoroughly checked than possible with checkers built for other languages. Many steps performed for compilation are reused. Which is what makes it so fast.
If you think "why can't I skip this?" you have missed the point and are exactly the target developer these checks are for.
I've written a lot of software. Never had a complaint about compile times in any language. The reality of developing with Rust is that after the first build, only changed files are rebuilt, which makes it just as fast to compile as any other language.
If compile times are what concerns you about a language, that tells me you're not very far along in your career. You have a lot more problems to discover which are very much more serious. If you ever encounter the problems Rust solves, you'll grow to appreciate it's solutions.
My largest rust project is still fairly small at around 8k lines across two dozen files. Still, it builds and links in 30 seconds on my workstation which is several years old and not particularly fancy.
I could see this beginning to become an issue around 100k lines of code, but I'd think most people would be looking to split into multiple crates before that just for readability.
I can think of couple:
- Toolchain size: Nim, Zig ~100MB; Rust >1.5GB
- Compilation Times
- Micro-dependency CultureThis is objectively not true. “Go feels legacy to me and I wouldn’t use it in production in most cases” is reasonable, if you feel that way, but “legacy language” has a definition, and Go isn’t a legacy language.
On top of this, in its excessive caution about adding features while balancing incidental and essential complexity, it just hasn't evolved and kept up to meet the kinds of demands modern languages do like Zig, Rust, C3, Carbon and Odin, and while these languages were innovating, Go was still catching up to 10-20 years ago at any given moment. It was already kind of a weird middle ground, not quite as high level as Ruby, not quite as low level as C++, and this slow catch up game plus lack of keeping up was, for me at least, just the nail in the coffin. But all of this together makes me personally think that it's just not a great fit for most scenarios, but also that it seemed to have started off on the wrong foot with itself and the wider programming community.
That's my take at least.
Is it really fair to compare golang to languages that haven’t hit 1.0? Would you sincerely use zig or carbon in production before Go?
I just feel like “it’s better than the alternatives” is still true, and will be for a while. I would love if software wasn't best written in slightly older languages, but even c++ had growing pains for years.
If you compared it technically and semantically to stuff like swift or kotlin, i think the case would be stronger, but it’s hard to take production concerns seriously when comparing it to zig. (I make a monthly donation to zig, but i wouldn’t use it at work)
Honestly every language has warts, there are no perfect languages. I just personally don't like Go, mostly for the reasons stated above as well as in a recent article I can't find anymore but read a few weeks ago, mostly complaining about its well known ergonomics issues.
But yeah it's fine to use in prod for the same reason Java 6 and IE 6 were for a long time: nothing really matters but money when you're doing work work.