Years ago, after over a decade making fistfuls of money as a Java developer and yet becoming almost physically nauseous at the idea of having to look at more Java code, I did a survey of possible ships to jump to. I was on the management track by that point - still more level enough to have my hand in - but salaries weren’t a huge factor. So I wrote a series of projects in three upcoming languages at the time: Vala, Rust, and Go.
I don’t remember now why Vala dropped out so quickly; I think it was some unsavory dependency or relationship with Gnome libraries, but honestly I don’t recall.
But I hated Rust. It felt like a language I was constantly fighting with, and simple, common things were just hard. And it’s not like I didn’t have experience with other paradigms; I cut my teeth on C and Pascal, did a fair amount of Scheme in college, actually implemented a project in Haskell that went into production at one company (and, for that, I sincerely apologize to every developer who worked there after me), and was part of a team that built an ETL engine for what qualifies as “big data” in Erlang at another.
Rust was the worst developer experience of them all, including Erlang, and that’s saying something.
Go was stupid easy to write, and more importantly, to understand other people’s code, and relatively hard to write bad code in. It’s gotten worse over time (Go generics are practically useless compared to the amount of cognitive complexity they add) but that’s the hubris of language developers: they can’t resist adding new crap that’s just enshittifies the language. Although, in the case of generics, there was a solid decade of pressure, mostly new converts who hadn’t yet learned they are entirely unnecessary, to add generics, so I don’t really blame the Go team for that one. And, for the most part, they’ve avoided making large, bad additions.
In any case, I was roasting Rust, not Go.
I love the binaries from Rust projects: they’re small (smaller than Go, without the runtime overhead), they’re fast, and they’re usually statically linked. But the language itself is a nightmare, and the compile times are absurd, so it someone wants to give me a binary, fine. Otherwise, no thanks. Rust may be a “memory safe” language, but that doesn’t mean shit if the code isn’t auditable and people are just passing around binaries.
Re auditability: sure, a Rust programmer could audit a code base. But I’d argue that a non-Go developer with any experience with any C-ish language could audit a Go project and confirm that it’s not doing any sketchy things like calling out to a botnet. I doubt many people would claim the same for Rust.
I think we’re mostly on the same page.
Years ago, after over a decade making fistfuls of money as a Java developer and yet becoming almost physically nauseous at the idea of having to look at more Java code, I did a survey of possible ships to jump to. I was on the management track by that point - still more level enough to have my hand in - but salaries weren’t a huge factor. So I wrote a series of projects in three upcoming languages at the time: Vala, Rust, and Go.
I don’t remember now why Vala dropped out so quickly; I think it was some unsavory dependency or relationship with Gnome libraries, but honestly I don’t recall.
But I hated Rust. It felt like a language I was constantly fighting with, and simple, common things were just hard. And it’s not like I didn’t have experience with other paradigms; I cut my teeth on C and Pascal, did a fair amount of Scheme in college, actually implemented a project in Haskell that went into production at one company (and, for that, I sincerely apologize to every developer who worked there after me), and was part of a team that built an ETL engine for what qualifies as “big data” in Erlang at another.
Rust was the worst developer experience of them all, including Erlang, and that’s saying something.
Go was stupid easy to write, and more importantly, to understand other people’s code, and relatively hard to write bad code in. It’s gotten worse over time (Go generics are practically useless compared to the amount of cognitive complexity they add) but that’s the hubris of language developers: they can’t resist adding new crap that’s just enshittifies the language. Although, in the case of generics, there was a solid decade of pressure, mostly new converts who hadn’t yet learned they are entirely unnecessary, to add generics, so I don’t really blame the Go team for that one. And, for the most part, they’ve avoided making large, bad additions.
In any case, I was roasting Rust, not Go.
I love the binaries from Rust projects: they’re small (smaller than Go, without the runtime overhead), they’re fast, and they’re usually statically linked. But the language itself is a nightmare, and the compile times are absurd, so it someone wants to give me a binary, fine. Otherwise, no thanks. Rust may be a “memory safe” language, but that doesn’t mean shit if the code isn’t auditable and people are just passing around binaries.
Re auditability: sure, a Rust programmer could audit a code base. But I’d argue that a non-Go developer with any experience with any C-ish language could audit a Go project and confirm that it’s not doing any sketchy things like calling out to a botnet. I doubt many people would claim the same for Rust.