3 ms·

Can you explain your comment a little more? I don’t understand the relationship between these that you’re suggesting.

influx 3y ago
FreeBSD and Go are slow to change, extremely hesitant to introduce API changes, and adhere more towards tradition. Rust and Linux are changing rapidly and aren’t as worried about completely uprooting entire systems. See for example sys v init vs systemd. Go didn’t get generics until 1.18 and promises backwards compatibility. In Rust, the popular command line parser Clap completely changed its API between 3 and 4 such that you’ll need to update your code. As much as I like predictably and simplicity, I think Rust will largely be more successful similar to Linux winning over FreeBSD.
- pgwhalen 3y ago
  All mainstream languages treat backwards compatibility as paramount at this point, it's table stakes at this point. Rust is no exception. I will admit that because the library ecosystem in Rust is younger, you do see things like Clap's breaking changes more often than in other languages.
jitl 3y ago
Go and FreeBSD share the similarity of a large base system that’s useful out of the box: in go the runtime and large, useful stdlin, in FreeBSD the base system composed of the kernel and standard programs. Both also encourage a certain cultural aesthetics around that base of accepting and going with the flow of the base’s limitations. For FreeBSD, things like composing posixly-correct sh scripts, BSD Makefile stuff. For Go, boilerplate, if err != nil, for a long time “you don’t need generics”. In contrast, Linux and Rust are both smaller core systems with more exposed complexity, but also require a large user space to make the core useful. Linux is just a kernel so you gotta bring everything else in the OS. Rust you need libraries for things most other languages (including Go) include, like regex, async, etc. However both Linux and Rust have a culture of adapting the system to work exactly how you like, in Linux again you bring everything you want - want systemd? Cool. Don’t want systemd, that’s cool too. In rust, people go absolutely crazy with macros and abstractions and likely it will still be plenty fast at runtime.

FreeBSD and Go are slow to change, extremely hesitant to introduce API changes, and adhere more towards tradition. Rust and Linux are changing rapidly and aren’t as worried about completely uprooting entire systems. See for example sys v init vs systemd. Go didn’t get generics until 1.18 and promises backwards compatibility. In Rust, the popular command line parser Clap completely changed its API between 3 and 4 such that you’ll need to update your code. As much as I like predictably and simplicity, I think Rust will largely be more successful similar to Linux winning over FreeBSD.

pgwhalen 3y ago
All mainstream languages treat backwards compatibility as paramount at this point, it's table stakes at this point. Rust is no exception. I will admit that because the library ecosystem in Rust is younger, you do see things like Clap's breaking changes more often than in other languages.

jitl 3y ago

Go and FreeBSD share the similarity of a large base system that’s useful out of the box: in go the runtime and large, useful stdlin, in FreeBSD the base system composed of the kernel and standard programs. Both also encourage a certain cultural aesthetics around that base of accepting and going with the flow of the base’s limitations. For FreeBSD, things like composing posixly-correct sh scripts, BSD Makefile stuff. For Go, boilerplate, if err != nil, for a long time “you don’t need generics”. In contrast, Linux and Rust are both smaller core systems with more exposed complexity, but also require a large user space to make the core useful. Linux is just a kernel so you gotta bring everything else in the OS. Rust you need libraries for things most other languages (including Go) include, like regex, async, etc. However both Linux and Rust have a culture of adapting the system to work exactly how you like, in Linux again you bring everything you want - want systemd? Cool. Don’t want systemd, that’s cool too. In rust, people go absolutely crazy with macros and abstractions and likely it will still be plenty fast at runtime.