5 ms·

Ironic since I’ve been thinking: FreeBSD : Go :: Linux : Rust

• bluejekyll 3y ago
  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.
• avgcorrection 3y ago
  The Go/Rust rivalry is just a peanut gallery meme. It’s never been a real thing IMO.
  • baq 3y ago
    Yeah, go competes with Java and Python. Rust is in a different class of tools.
    • pgwhalen 3y ago
      I would narrow it even further: Go competes with Java. Their forte is both programming-in-the-large on the backend. It's much harder to manage a large codebase/application with Python, but it excels at data science and research programming, which Go and Java do not. (Obviously, there is overlap between all, and you could do anything in any language.)
  • wharvle 3y ago
    Go is what I reach for if my other options might be Java or Python but I don’t want deployment and support to be really stupid and awful. Rust’s close alternative is C++. Maybe also C? I don’t know if Rust can fill its niche of ultra-portable libraries that are relatively easy to import and use in tons and tons of other languages & systems.
    • mattsan 3y ago
      Other than LLVM portability concerns, I think Rust can for sure replace C/C++ libraries (I'm talking DLLs etc). Sure, there will be a small C ABI shim but the developer experience writing in Rust I think is worth it. Also, nowadays whenever I want to write a fast Python extension, I don't think twice before using pyo3, super simple to write and build.