Comment by crote | Hacker News Reader

Comment by crote | Hacker News Reader

The problem is that coreutils isn't done. It is still getting new features - it even had a release today [0]! And if new features are being added, then we're getting new bugs as well. Using Rust eliminates an entire class of rather serious bugs, so in a greenfield environment it would almost certainly be a better choice for a critical project like coreutils.

In practice it's of course more complicated. Any rewrite will also introduce a lot of bugs, so short-term the rewrite will probably have a negative result. I think it's a weird decision for Ubuntu to switch to uutils when it is still incomplete and probably buggier than the GNU version, but perhaps in the long run (5+ / 10+ years?) it might turn out to be the better option.

It's also important to keep the wider ecosystem in mind. Even if C and Rust were functionally identical, a rewrite could still make sense. Imagine if coreutils was written in a language like COBOL: the language choice would severely restrict the number of potential contributors. Who's going to learn it solely for the thankless job of maintaining boring tooling like coreutils? With the current generation of OSS maintainers slowly dying off, you need to recruit new (younger) developers to take over. If all the kids love Rust and hate C, then perhaps a switch to Rust might be a necessary evil to ensure we'll have well-maintained coreutils for another generation. You still need to be careful to avoid the fad of the day, but I think it's pretty clear by now that Rust is here to stay.

As an aside, as [1] shows, the "it'll at best be equal" argument is factually incorrect. There is no good reason to believe that GNU coreutils could not possibly be improved upon.

[0]: https://www.phoronix.com/news/GNU-Coreutils-9.8

[1]: https://www.phoronix.com/news/Rust-Coreutils-0.2.2

I guessed the topic from the page title and am glad to second your comment. Your third paragraph is I think is even more broadly true: I'm not _that_ old, I learned C in the 90s, have contributed to some widely-used C-based open source projects (I don't want to overstate this ), etc. but even with that experience, I would avoid working on a C-based project if I had to simply because using something like Rust is so much more pleasant as a developer from better functionality to package management to the experience of using the toolchain. People do that because it's a job, but working on things like coreutils doesn't exactly pay “this is now interesting” money.

The biggest C-based open source project I personally started is https://github.com/acdha/mountstatus. It's a simply utility I made back in the early 2000s when I worked at a place with a lot of Linux/FreeBSD/Solaris/OS X servers using NFS storage and needed the low-level control to have a process be able to reliably scream for help when we hit the various kernel bugs which would cause an entire mount point to hang in a way which caused any normal filesystem operation to hang, which I did by forking a child process and testing whether it stopped responding. Since that stayed in memory all the time and needed to be portable, C was a natural choice and it worked well enough but there were a few features I never worked on because the pain and suffering level of managing concurrency or pushing metrics to Prometheus was a psychological deterrent, especially when I changed jobs and any time spend on OSS was coming out of my hobby time.

At some point I decided to try rewriting it in Rust, and I was happy with the results and cut v2.0 in 2017. It wasn't _that_ much time – this is a tiny project – but the subjective experience was that it didn't feel so much like a chore and not having to worry about things like package management changed how you approached features which should be simple and stayed simple because Rust package management is simple compared to managing C dependencies on multiple platforms. (As a cautionary note, I became a parent later that year and you can see the decline in free time set in pretty hard)

As soon as I saw the submission title I knew "it's something Linux related complaining about Rust" and it was (ie coreutils).

As you note (and I agree) Rust eliminates a whole class of potential bugs that are proven to be probably the primary vector of CVEs and we live in an era where that's simply unacceptable for core infrastructure. Heartbleed was one very public example. But these memory safety bugs are traded on the black market and end up in tools like Pegasus to spy on (or even kill) politicians and even journalists.

IME people an incredibly warped view of just how subtle and easy it is to introduce a memory safety bug. I think people think it's just bounds checking arrays and buffers. It's not. Writing any kind of multithreaded code (ie anything using primitives like mutexes directly) is incredibly error-prone. When you add in heteregenous cores and out-of-order processing it gets much, much worse.

There's a large company I know with many bright engineers who contributes heavily to tools like valgrind and asan. This is a company with a lot to lose and is deeply concerned about security. Somebody came up with a valgrind check and ran it over their C++ code base and, lo and behold, found issues that had been dormant in their code base for up to a decade. None exploited, as far as anyone knew. But think about it: a decade of checks, automated code-checking, etc had all missed some of these bugs.

People like to complain that writing correct Rust is hard. Thats's true, particularly for novices. But you'll get better. Thing is, writing correct C++ code isn't exactly easy either.

And perhaps writing such code in Rust is hard because writing memory safe code is hard.

The C\C++ memory model is simply not suitable for creating secure internet connected software.

Excellent comment.

  > People like to complain that writing correct Rust is hard. Thats's true, particularly for novices. But you'll get better. Thing is, writing correct C++ code isn't exactly easy either.

Agreed, and I wish all of the "Rust is hard" people would offer this critique _in context_.

The question is not "is Rust harder than C or C++?". The question is, "is writing correct Rust harder than writing correct C or C++?".

You could even think of it in financial terms: "is the cost of writing correct Rust higher or lower than the cost of writing correct C or C++?".

Another interesting qualification to add on is: "...for someone who doesn't already know Rust or C or C++". If you had to onboard a new team member, and they didn't know Rust or C or C++, which language would you want your project to be in? Which would they be able to safely contribute to the fastest? I know what I'm picking.

> IME people an incredibly warped view of just how subtle and easy it is to introduce a memory safety bug.

Agreed, and I think part of the reason is because they take it personally when someone claims programmers (in general) can't consistently write memory safe C/C++.

> If all the kids love Rust and hate C, then perhaps a switch to Rust might be a necessary evil to ensure we'll have well-maintained coreutils for another generation. You still need to be careful to avoid the fad of the day, but I think it's pretty clear by now that Rust is here to stay.

It's very unclear – to me it seems more like there's a vocal minority on people on here commenting on every C post "someone should rewrite this in a memory-safe language".

People tend to forget that C got so popular because it had very simple semantics (with much UBI ofc). Golang is arguably more popular than rust, has much simpler semantics and is much easier to pick up.

In all my years in tech I've rarely seen a more complex tool beat a simpler one (otherwise we'd all be using VMS), I'm not holding my breath for rust's longevity.

Plenty of complex tools have beaten simple ones, especially when it alleviates some other form of complexity.

Version control beat handing around labelled floppies, despite being far more complex, since it's still easier than managing state by hand.

I wouldn't be surprised if rust replaced C for similar reasons. It might be syntactically more complex, but it's still far simpler than stopping your library from being a beginner pwn exercise at a local CTF.

If I understand correctly, in your analogy, golang is floppies and rust is a sophisticated version control system? lol

Golang doesn't fill quite the same niche, though: it's garbage collected, for example. I'd personally question whether we need the main pros of C for basic command line tools (that's a topic for another time), but it does explain why we're seeing far fewer "rewrite it in Go" sentiment. If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.

Language simplicity also isn't that important. Usage-wise you're missing out on a lot of potential features and benefits, and implementation-wise you're not gaining a lot as everyone just writes LLVM frontends these days. If language simplicity was that important, we'd all be writing Lisp these days.

> If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.

well for a good 15-20 years the jvm had awful startup times which probably was why it was not attractive as a systems language. Does being garbage collected matter for a tool like cat? I would say no

Reply on news.ycombinator.com