5 ms·

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

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, even if there are some costs associated with the transition. I also don't think that Rust itself is the only possible good language to use to write software - someone might invent a language in the future that is even better than Rust, and maybe at some point it will make sense to port rust-coreutils to something written in that yet-undesigned language. It would be good to design software and software deployment ecosystems in such a way that it is simply possible to do rewrites like this, rather than rely so much on the emergent behavior of one C source code collection + build process for correctness that people are afraid to change it. Indeed I would argue that one of the flaws of C, a reason to want to avoid having any code written in it at all, is precisely that the C language and build ecosystem make it unnecessarily difficult to do a rewrite.

jjgreen 1y ago
[flagged]
- baq 1y ago
  'the two things that really drew me to vinyl were the expense and the inconvenience.' https://imgur.com/gallery/vinyl-meme-7jeZtVJ https://imgur.com/gallery/vinyl-meme-7jeZtVJ
- HighGoldstein 1y ago
  This is an apt comparison since nobody except fringe enthusiasts came back to vinyl.
- steveklabnik 1y ago
  I've been using Rust for 13 years, I'll let you know in two if I go back to C. Given I'm about to turn 40, I do appreciate being referred to as a kid though ;)
  - tracker1 1y ago
    I'm 50 and prefer Rust... though tbh I haven't worked much with C or Rust. I just never liked C, preferring to stick to higher level languages, even C# over it. I do like Rust though, even if I feel like I'm pulling my hair out sometimes trying to grok ownership symbols. Most Rust I understand by looking at it... I can not say the same with C.
StopDisinfo910 1y ago
> 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.
- JuniperMesos 1y ago
  > 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-braces 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?
  - josefx 1y ago
    > 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.
    - Avamander 1y ago
      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.
compiler-devel 1y ago
> 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
- JuniperMesos 1y ago
  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.
amiga386 1y ago
> 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-for-operational-resilience-failings 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.
- JuniperMesos 1y ago
  > 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.
  - amiga386 1y ago
    > 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.

jjgreen 1y ago

[flagged]

baq 1y ago
'the two things that really drew me to vinyl were the expense and the inconvenience.' https://imgur.com/gallery/vinyl-meme-7jeZtVJ https://imgur.com/gallery/vinyl-meme-7jeZtVJ
HighGoldstein 1y ago
This is an apt comparison since nobody except fringe enthusiasts came back to vinyl.
steveklabnik 1y ago
I've been using Rust for 13 years, I'll let you know in two if I go back to C. Given I'm about to turn 40, I do appreciate being referred to as a kid though ;)
- tracker1 1y ago
  I'm 50 and prefer Rust... though tbh I haven't worked much with C or Rust. I just never liked C, preferring to stick to higher level languages, even C# over it. I do like Rust though, even if I feel like I'm pulling my hair out sometimes trying to grok ownership symbols. Most Rust I understand by looking at it... I can not say the same with C.

StopDisinfo910 1y ago

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

JuniperMesos 1y ago
> 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-braces 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?
- josefx 1y ago
  > 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.
  - Avamander 1y ago
    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.

compiler-devel 1y ago

> 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

JuniperMesos 1y ago
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.

amiga386 1y ago

> 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-for-operational-resilience-failings 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.

JuniperMesos 1y ago
> 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.
- amiga386 1y ago
  > 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.