Michał Górny (he/they) ∞🙀🚂🐧 on Nostr: #RustLang is the perfect language for the "move fast, break things" era. No, I'm not ...
#RustLang is the perfect language for the "move fast, break things" era. No, I'm not implying it encourages you to break stuff. All I'm saying is that all these modern languages are specifically designed for that mindset. They optimize for corporate greed — nicely dressed as "valuing developer's time".
Developers aren't supposed to slow down and think things over. They should finish feature after feature, project after project, profit after profit. When things break, that's bad for profit. However, putting an effort to prevent things from breaking is not cost-effective.
People love to point out memory safety problems with C. However, there are two other important problems affecting C libraries — ABI and API stability. An uncontrolled ABI breakage means that existing programs suddenly breaks. An uncontrolled API breakage means that programs don't build anymore. Combine both and you're in a tight fit.
There are reasonably good solutions to both these problems. However, they require conscious effort, they require thinking — and that is costly. There are also cheap workarounds. If you link libraries statically, you don't need to worry about their ABI changes. If you vendor dependencies, you don't even need to worry about API changes. That's much cheaper for the company — though in reality, it just moves the burden down the line, to distribution developers and users, who end up fighting old, broken or even vulnerable vendored dependencies.
The problem with Rust and #Cargo is that it embraces these hacks into glorified 20M+ executables. Everything is linked statically, everything is vendored. You can move fast without actually breaking things — at least for the significant majority of users. To the minority, you always have the usual excuse — "we're sorry, we're just volunteers, we can't spend more energy on this, and you should get newer hardware anyway". Not that doing things better wouldn't benefit all users.
#Gentoo
Developers aren't supposed to slow down and think things over. They should finish feature after feature, project after project, profit after profit. When things break, that's bad for profit. However, putting an effort to prevent things from breaking is not cost-effective.
People love to point out memory safety problems with C. However, there are two other important problems affecting C libraries — ABI and API stability. An uncontrolled ABI breakage means that existing programs suddenly breaks. An uncontrolled API breakage means that programs don't build anymore. Combine both and you're in a tight fit.
There are reasonably good solutions to both these problems. However, they require conscious effort, they require thinking — and that is costly. There are also cheap workarounds. If you link libraries statically, you don't need to worry about their ABI changes. If you vendor dependencies, you don't even need to worry about API changes. That's much cheaper for the company — though in reality, it just moves the burden down the line, to distribution developers and users, who end up fighting old, broken or even vulnerable vendored dependencies.
The problem with Rust and #Cargo is that it embraces these hacks into glorified 20M+ executables. Everything is linked statically, everything is vendored. You can move fast without actually breaking things — at least for the significant majority of users. To the minority, you always have the usual excuse — "we're sorry, we're just volunteers, we can't spend more energy on this, and you should get newer hardware anyway". Not that doing things better wouldn't benefit all users.
#Gentoo