Rust is not a good C replacement
@sir yay, finally an article clearly stating your thoughts about Rust!
I may disagree with many of the points (not all Rust designers were/are C++ devs, concurrency is not just about multithreading, you're wrong about the stability & new features rate and so on),
but I applaud you finally writing it all down.
Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. I don’t care what language you rewrite it in.
Safety is actually very important. Segfaults and buffer overflows cause a shit ton of security exploits.
@sir certainly the fast movement of #rustc has been the main thing slowing down my experimentation with it. Everytime I try an build #remacs run into some random compiler problem. However at the same time spending a lot of time as I do doing multi-threaded C I long to work with a language that properly supports you in getting it right. AIUI moving from C to #golang is easier as it's a minimal bit of extra syntax to learn but I'm not as sure of their concurrency story.
@sir this is so much better than "fuck rust, because yes"
@sir I have *wanted* to learn Rust, but I keep bouncing off of it, and the conclusion I came to at the time is that there is simply too much of it to learn. It might be possible to start writing a subset of Rust, but when I started out trying to read code for straightforward things, I ran into the fact that idiomatic Rust code seems to use every single language feature; you can't *read* a subset.
I have had similar experience. I started looking at it, but after a while I thought to myself: Why am I doing this? Why should I have to jump through all these hoops to be able to write code as safely as, say, Elixir? Why not just use a language that actually has all the features that Rust tries to emulate without actually implementing it.
Computers are fast these days. It's OK to do runtime checks.
@sir "Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams." Any examples/citations of this?
@bb010g Thanks. The comments on that PR elaborate a lot on this subject. This post especially https://github.com/mesonbuild/meson/pull/2617#issuecomment-379417837
@curls You're welcome. It's a hard problem. as someone who's dabbled a fair amount with Nix and packaging for Nixpkgs, the tradeoffs between integrated tools and experiences like Cargo and "larger" build systems like Meson or Bazel are difficult. you want the easy things for developers to be the right things, but that makes more effort for others. Cargo has been getting better about telling you what it wants to do, but you won't ever be free without a maintained reimplementation.
@curls cargo evolves to better serve developers over time along with a language that tries to move past poor design decisions (not removing them outright, but discouraging them in new code). Meson is based on a language where there's never been a really good build system, and it has less to chase and grow compatibility for. I don't see a generic solution in the future outside of a nix-like build system that combines sandboxed execution of whatever with bits of custom glue code.
@bb010g I am a bit fuzzy about the details, as I have no experience with rust, but it seems like cargo is missing features that besides hindering integration, just make it less robust in general. It makes me apprehensive to learn rust in the first place, knowing that realistically Cargo is the only build system I could ever use.
@curls Working with Cargo & Rust yourself will give you better answers, but if you want to ask about what you think Cargo may struggle with, i'll try to give you the best answers I can. (cargo's been really great in my experiences.)
@bb010g Thank you for your input!
@sir "However, its replacement will be simpler - not more complex." Exactly my feelings!
One thing I find surprisingly missing from the "why not rewrite it in Rust" conversations is that Rust is complicated. It changes the economy of programming: if you're able to write a program that works 98% of time in an hour then an extra hour for 99% may not be a good deal.
It also raises the bar: a more complex language needs a better brain, larger working memory. Biology just might not be on your side.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!