@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 Nice article, I quite agree with a lot of the stuff there.
I’m a bit unclear about what you mean by System V ABI, which I’m probably not aware of.
And for the safety of Rust vs. C, I’m pretty sure C tools are actually getting quite good on this part and I’m not really sure it’s a limitation of the language but more like a limitation of current implementations.

@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?

@curls @sir Not exactly hostility, but exactly accomodation either. Cargo does too much, is too coupled, and Rustaceans too busy building their own world to quite have the time to accomodate other contexts.


But this is not unique to Rust. Many languages have their own build and package tools that are a bit too idiomatic and introvert.
@sir @curls A year later the Nix Rust infrastructure would work around this by reimplementing half of cargo in Rust, Nix and bash and just run rustc directly.


@curls There's a few threads from Meson that were linked on HN at least: github.com/mesonbuild/meson/is github.com/mesonbuild/meson/pu (Cargo team members mostly show up on the PR)

@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.)

@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.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!