Hacker News Reader

> C is a bad language in many respects, and Rust greatly improves on the situation. Replacing code written in C with code written in Rust is good in and of itself

That's empty dogma.

C issue is that C compilers provide very little in term of safety analysis by default. That doesn't magically turn Rust into a panacea. I will take proven C or even static analysed C above what the borrow checker adds to Rust any day of the week.

I like the semantic niceties Rust adds when doing new development but that doesn't in any way justify all rewrites as improvement by default.

> C issue is that C compilers provide very little in term of safety analysis by default.

Yes this is precisely a respect in which C is bad. Another respect is that C allows omitting curly braces after an if-statement, which makes bugs like https://www.codecentric.de/en/knowledge-hub/blog/curly-brace... possible. Rust does not allow this. This is not an exhaustive list of ways in which Rust is better than C.

> I will take proven C or even static analysed C above what the borrow checker adds to Rust any day of the week.

Was coreutils using proven or statically analyzed C? If not, why not?

> This is not an exhaustive list of ways in which Rust is better than C.

Which is why your first and only example is a bug from over a decade ago, caused by an indentation error that C compilers can trivially detect as well.

Can detect, but how many are forced? Have you tried using Gentoo with "-Wall -Werror" everywhere?

You have some theoretical guardrails that aren't used widely in practice, many times even can't be used. If they could just be introduced like that, they'd likely be added to the standard in the first place.

The fact that the previous commenter can even ask the question if someone has analyzed or proven coreutils shows how little this "can detect" really guarantees.

The end your "can trivially detect" is very useless compared to Rust's enforcing these guarantees for everyone, all the time.

-Wall -Werror is rare? That is more like the default for serious projects. The non-daily flags for code checking are -Wpedantic and -fanalyzer stuff.

It's rare enough that you can't have your entire Gentoo built with it, especially not after a compiler update.

But how many C programmers actually use that 'ability' to 'trivially' detect indentation errors?

And how many C programmers just ignore the warning while thinking, "I have decades of experience the compiler is just blabbering false positives"?

Rust forces some things preventing the bypass of guardrails.

> the compiler is just blabbering false positives

That seems to come from taking a meaning of errors and warnings from other languages to C. In other language an error means there might be some mistake, and a warning is a minor nitpick. For C, a warning is a stern warning. It is the compiler saying "this is horrible broken and I do compile this to something totally different from what you thought. This will never work, and you should fix it, but I will still do my job and produce the code, because you are the boss." An error is more akin to the compiler not even knowing what that syntax could mean.

Honestly, this is because I like C. I want control.

> Another respect is that C allows omitting curly braces after an if-statement, which makes bugs like https://www.codecentric.de/en/knowledge-hub/blog/curly-brace... possible.

This is a silly thing to point to, and the very article you linked to argues that the lack of curly braces is not the actual problem in that situation.

In any case, both gcc and clang will give a warning about code like that[1] with just "-Wall" (gcc since 2016 and clang since 2020). Complaining about this in 2025 smells of cargo cult programming, much like people who still use Yoda conditions[2] in C and C++.

C does have problems that make it hard to write safe code with it, but this is not one of them.

[1] https://godbolt.org/z/W74TsoGhr

[2] https://en.wikipedia.org/wiki/Yoda_conditions

And how many software are compiled with zero warnings?

And how many C programmers ignore such warnings because they are confident they know better?

It seems like you're trying to fix a social problem (programmers don't care about doing a good job) with a technical solution (change the programming languages). This simply doesn't work.

People who write C code ignoring warnings are the same people who in Rust will resort to writing unsafe with raw pointers as soon as they hit the first borrow check error. If you can't force them to care about C warnings, how are you going to force them to care about Rust safety?

I've seen this happen; it's not seen at large because the vast majority of people writing Rust code in public do it because they want to, not because they're forced.

> This simply doesn't work.

I think it works, and quite well even. Defaults matter, a lot, and Rust and its stdlib do a phenomenal job at choosing really good ones, compared to many other languages. Cargo's defaults maybe not so much, but oh well.

In C, sloppy programmers will generally create crashy and insecure code, which can then be fixed and hardened later.

In Rust, sloppy programmers will generally create slower and bloated code, which can then be optimized and minimized later. That's still bad, but for many people it seems like a better trade-off for a starting point.

> In C, sloppy programmers will [...]

> In Rust, sloppy programmers will [...]

You're comparing apples to oranges.

Inexperienced people who don't know better will make safe, bloated code in Rust.

Experienced people who simply ignore C warnings because they're "confident they know better" (as the other poster said) will write unsafe Rust code regardless of all the care in the world put in choosing sensible defaults or adding a borrow checker to the language. They will use `unsafe` and call it a day -- I've seen it happen more than once.

To fix this you have to change the process being used to write software -- you need to make sure people can't simply (for example) ignore C warnings or use Rust's `unsafe` at will.

Okay, I see what you mean now. I suppose that could be right.

> That's empty dogma.

This dogma is statistically verifiable. We could also replace them with Go counterparts

> I will take proven C or even static analysed C

This just means you don't understand static analysis as much as you do. A rejection of invalid programs by a strict compiler will always net more safety by default than a completely optional step after the fact.

> Replacing code written in C with code written in Rust is good in and of itself, even if there are some costs associated with the transition.

No it isn't. In fact, "Replacing code written in <X> with code written in <Y> is good in and of itself" is a falsehood, for any pair of <X> and <Y>. That kind of unqualified assertion is what the deluded say to themselves, or propagandists (usually <Y> hype merchants) say out loud.

This is what reality looks like: https://www.bankofengland.co.uk/news/2022/december/tsb-fined...

Furthermore, "designing for a future rewrite" is absolute madness. There is already a lot of YAGNI waste work going on. It's fine to design software to be modular, reusable, easily comprehensible, and so on, but designing it so its future rewrite will be easier - WTF? You haven't even built the first version yet, and you're already putting work into designing the second version.

Fashions are fickle. You can't even know what will be popular in the future. Don't try to anticipate it and design for it now.

> Furthermore, "designing for a future rewrite" is absolute madness. There is already a lot of YAGNI waste work going on. It's fine to design software to be modular, reusable, easily comprehensible, and so on, but designing it so its future rewrite will be easier - WTF? You haven't even built the first version yet, and you're already putting work into designing the second version.

If software is in fact designed to be modular, reusable, and easily-comprehensible, then it should be pretty easy to rewrite it in another language later. The fact that many people are arguing that programmers should not even attempt to rewrite C coreutils, for fear of breaking some poorly-understood emergent behavior of the software, is evidence that C coreutils is not in fact modular, reuseable, and easily-comprehensible. This is true regardless of whether or not the Rust rewrite (or another language rewrite) actually happens or not.

> C coreutils is not in fact modular, reuseable, and easily-comprehensible

It's not. I never said it was. Nor are my bank's systems; I don't want them to fuck them up either. My bank's job is not to rewrite their codebase in shinier, newer languages that look nice on their staff's CVs, their job is to continue to provide reliable banking services. The simplest, cheapest way for them to do that is to not rewrite their software at all.

What I was addressing was two different approaches to "design[ing] software [...] in such a way that it is simply possible to do rewrites"

* One way is evergreen: think about modularity, reusability, and good documentation in the code you're writing today. That will help with any mooted future rewrite.

* The other way, which you implied, is to imagine what the future rewrite might look like, and design for that now. That way lies madness.

> I also don't think that Rust itself is the only possible good language to use to write software

you don't really believe this because you said that the only possibly better language would be one that doesn't yet exist

I don't think there is one programming language that is best suited for all types of programs. I think that Rust is probably the best language currently in use for specifically implementing Unix coreutils, but I don't think that this implies that (say) Zig or Odin or Go or Haskell would necessarily be terrible choices (although I really would pick Rust rather than any of those).

But my point was that there's no reason to think that the specific package of design decisions that Rust made as a language is the best possible one; and there's no reason why people shouldn't continue to create new programming languages including ones intended to be good at writing basic PC OS utils, and it's certainly possible that one such language might turn out to do enough things better than Rust does that a rewrite is justified.