17 ms·

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going t

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dropped for pragmatic reasons, so can these architectures. If people really, really want to preserve these architectures as ongoing platforms for the future, they need to step up and create a backend for the Rust toolchain that supports them.

Galanwe 11mo ago
[flagged]
- nixosbestos 11mo ago
  > it's factually just better, am I right? so cool to see people getting it!
- metrix 11mo ago
  While I get your view, I think examples would help to move the conversation along in a more constructive manner
astockwell 11mo ago
Would this logically extend to also include C-reliant languages like Python and Ruby (the latter being mostly a grammar underpinned by C) as technical debt also?
- gpm 11mo ago
  Not really. All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs. There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.
  - dcsommer 11mo ago
    > basically fine How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.
    - gpm 11mo ago
      Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem. My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.
      - bigyabai 11mo ago
        It depends, what language was the sandbox written in?
        gpm 11mo ago
        Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.
    - zahlman 11mo ago
      How many ways to cause a segmentation fault in CPython, that don't start with deliberate corruption of the bytecode, are you aware of? How is "type confusion" a security issue?
- tempest_ 11mo ago
  Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code. A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.
  - physicsguy 11mo ago
    Most Python libraries that relies on C are numerical stuff. From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library. On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.
allisdust 11mo ago
Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back against any and every use, promotion of Rust. The unknown fear seem to be that they will be left behind if it takes off. I completed my battles with Rust. I don't even use it anymore (because of lack of opportunities). But I love Rust. It is here to stay and expand. Thanks to the LLMs and the demand for verifiability.
- kstrauser 11mo ago
  I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); let altitude2 = Feet(16); hover(altitude2); } This fails at build time with: 12 | hover(altitude2); | ----- ^^^^^^^^^ expected `Meters`, found `Feet` | | | arguments to this function are incorrect Guaranteeing that I’ve never mixed units means I don’t have to worry about parking my spacecraft at 1/3 the expected altitude. Now I can concentrate on the rest of the logic. The language has my back on the types so I never have to waste brain cycles on the bookkeeping parts. That’s one example. It’s not unique to Rust by a long shot. But it’s still a vast improvement over C, where that same signed 32 bit data type is the number of eggs in a basket, the offset of bytes into a struct, the index of an array, a UTF-8 code point, or whatever else. This really shows up at refactoring time. Move some Rust code around and it’ll loudly let you know exactly what you need to fix before it’s ready. C? Not so much.
  - OptionOfT 11mo ago
    It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]
wolvesechoes 11mo ago
If people really, really want to have all infra written in Rust, they should step-up and stop using LLVM.
- jsheard 11mo ago
  There is a pure-Rust compiler backend in the works, but that's going to take a long time to mature so it's just pragmatic to use LLVM in the meantime. Especially since the exploitation potential is pretty contrived in this case - if you compile compromised code then you're probably owned anyway, regardless of the backends memory safety.
- OptionOfT 11mo ago
  What is the concern with LLVM? I'm asking because I genuinely don't know.
  - wolvesechoes 11mo ago
    I would assume that because it is written in unsafe C++, it creates technical debt that should addressed rather soon.
  - smithkl42 11mo ago
    I think the issue he's pointing at is that LLVM is itself written in C++ - so the entire "trusted" Rust toolchain depends on trusting a huge C++ app.
    - vlovich123 11mo ago
      Thankfully the “trust” you need out of a compiler is very very different. It would be closer to claiming you need to compile it on a Rust OS too because you’re trusting a large C/C++ app. Separation of concerns solves this because the compiler has minimal impact on the trustedness of the code the Rust compiler generates. Indeed, one would expect that all the ways that the LLVM compiler fails are ways any Rust implementation would fail too - by generating the wrong code which is rarely if ever due to memory safety or thread safety issues. There may be other reasons to write the compiler backend in Rust but I wouldn’t put the trust of compiled Rust code as anywhere near the top of reasons to do that.
krater23 11mo ago
Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.
- woodruffw 11mo ago
  > Memory safety is mostly an issue of the past. Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1]. > But we have tools to prevent that. The new security issues are supply chain attacks. Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or. [1]: https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- 01HNNWZ0MV43FF 11mo ago
  What part of C package management defends against supply chain attacks? Does it audit third-party code for you?
  - illuminator83 11mo ago
    I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain. The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred. Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done. In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.
    - uecker 11mo ago
      I never found it hard to add a C library to my projects using pkg-config. And yes, when the package came from Debian I have some trust that it is not a huge supply chain risk. I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager manager and Cargo or npm or the countless Python managers should all not exist either.
tmtvl 11mo ago
> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under <https://github.com/pop-os/cosmic-applets https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: <https://savannah.gnu.org/projects/coreutils/ https://savannah.gnu.org/projects/coreutils/>).
- 01HNNWZ0MV43FF 11mo ago
  To be fair GUI code is going to be harder to read than a non-interactive utility, in any two languages
- kstrauser 11mo ago
  I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit. If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.
  - cogman10 11mo ago
    That's a style choice that I think comes from former C++ devs. Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.
    - kstrauser 11mo ago
      I don’t think that’s quite right. I haven’t written C++ since the 90s, and I use IDEs (Emacs and Zed), but I still sometimes reach a mental threshold where I look at my screen and see way too many names to have to hold in my mental buffer, then decide to make them more explicit.
jcranmer 11mo ago
Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years). There's other languages that are considered acceptable, even desirable, languages to write applications in (e.g., Java, PHP, Go), but Rust is really the first language to compete sufficiently close to C's competence for people to contemplate adding it to the base-system-languages list. I'd say only Go has ever come close to approaching that threshold, but I've never seen it contemplated for something like systemd. Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious.
- embedding-shape 11mo ago
  > Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community. So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.
  - julian-klode 11mo ago
    If anyone sees that horrible mess of hacks around pre-STL C++'s lacks of namespace in combination with latest C++ features as part of the C++ community I'd be very surprised :D If APT were a hardcore C++ project surely we'd have like adopted namespaces everywhere by now.
  - jenadine 11mo ago
mattbee 11mo ago
The Fil-C project ( https://fil-c.org/ https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.
- tialaramex 11mo ago
  If you're single platform (Fil-C is x86-64 only), if the program is finished (Fil-C doesn't magically make maintaining a C project any easier to handle) and if performance isn't relevant (Fil-C is and despite its originator's confidence always will be bigger and slower than what you have today) then I agree.
- loeg 11mo ago
  Making core package infrastructure 10x slower doesn't seem especially pragmatic.
  - mattbee 11mo ago
    The author's benchmarks suggest 10× would be a pathological case! But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.
    - loeg 11mo ago
      We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)
      - ChocolateGod 11mo ago
        Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days. > We have an alternative that isn't 10x slower, and comes with many other benefits Anyone involved with development around a fruity company would say Swift ;)
coderjames 11mo ago
> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and .ar file formats are both from the 70s; what new benefits will users or developers gain from that thoroughly battle-tested code being thrown out and rewritten in a new language with a whole new set of compatibility issues and bugs?
- ok123456 11mo ago
  There are none. This is a canonical employee trying to force Ubuntu's decisions (rust coretools) on the wider Debian community. Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.
- blub 11mo ago
  Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…
  - julian-klode 11mo ago
    Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.
    - RustSupremacist 11mo ago
      You have never been skilled at being considerate: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
a-dub 11mo ago
rust is kinda ugly. i think i like zig better.
- drnick1 11mo ago
  Actually I agree. I wish Rust kept the basic C syntax for function etc. I really hate def, fn, and other such keywords.
jbv027 11mo ago
It is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.
- Greed 11mo ago
  Wow, I've never considered this aspect of it but you're right. If you want widespread access to incoming developers that can contribute to your project, that really does mean Rust by default at this point if you want a low level language regardless of what you prefer.
- RustSupremacist 11mo ago
  Inviting rank amateurs to established projects while expecting them to operate as free labor in the hopes of future relevance for employment has a distinctly different feel. Missives like the OP feel like preying on a desperate and young generation when paired with the commentary. If all the entry-level jobs are C or C++, do you think companies would have a hard time filling them? Would the unemployed new graduates really shun gainful employment if Rust wasn't part of the equation? Meanwhile, hiring managers left and right are reporting that within hours of a job being posted, they are flooded with hundreds of applications. And you can't find a single person because of the programming language of your stack? And to remedy this, you're going to rewrite your stack in an unproven language? Have you considered that if you can't find anyone that it might not be a programming language or tech stack problem?
- zahlman 11mo ago
  A pity the banks didn't do that with COBOL....
  - pjmlp 11mo ago
    They did, Java and .NET.
- physicsguy 11mo ago
einpoklum 11mo ago
> Critical infrastructure still written in C ... is technical debt that is only going to get worse over time. No. Rust is not magic, it just forces a discipline in which certain safety checks can be made automatically (or are obviated entirely). In other languages like C, the programmer needs to perform those checks; and it's technical debt if the C code is not coded carefully and reviewed for such issues. If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid. > Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. That's not true. First, it's not a well-defined statement, since "what we know now" about language design is, as it has always been, a matter of debate and a variety of opinions. But even regardless of that - C was a language with certain design choices and aesthetics. Rust does not at _all_ share those choices - even if you tack on "and it must be safe". For example: Rust is much richer language - in syntax, primitive types, and standard library - than C was intended to be.
- Avamander 11mo ago
  > If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid. How many decades have we tried this? How many more to see that it just hasn't panned out like you describe?
- alfiedotwtf 11mo ago
  > If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. History shows again and again that this statement is impossible.. Name a large C application that’s widely used, and I’ll show you at least one CVE that’s caused by a memory leak from the project
samdoesnothing 11mo ago
Oh please, in a decade Rust will also be technical debt and people will be wanting to write it in Brust or whatever is the trendy new language.
- steveklabnik 11mo ago
  It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.
  - samdoesnothing 11mo ago
    That makes no sense. It was much longer than 10 years before people considered C to be tech debt for example. Idk if it will be 10 years exactly, but we are seeing better languages emerging (Swift 6, Mojo, probably others) that provide the same safety guarantees and performance/use case profiles as Rust, but are vastly more ergonomic and lovely to use. I fear Linux was hasty integrating Rust because it will likely prevent them from integrating something better in the near future.
    - steveklabnik 11mo ago
      You’re the one that said ten years.
      - samdoesnothing 11mo ago
        I said ten years from now...
      - kasabali 11mo ago
        You're the one who said "ten years since Rust 1.0"
        Klonoar 11mo ago
        The person who they replied to stated a decade. This whole thing is pretty clear cut and dry.
themafia 11mo ago
> It's not as if Rust is that much more difficult to write than C According to what? > Rust is explicitly designed There is no standard. It's accidentally designed. > knowing what we know now about language design and code safety. You've solved one class of bugs outside of "unsafe {}". The rest are still present.
- spacechild1 11mo ago
  > There is no standard. It's accidentally designed. Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment... > You've solved one class of bugs outside of "unsafe {}". It's "only" the single most important class of bugs for system safety. This kind of deflection and denialism isn't helping. And I'm saying this as someone who really likes C++.
  - themafia 11mo ago
    > that you can't design a language without an official standard? No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed. > The phrase "design by committee" isn't typically used as a compliment... While the phrase "emergent incompatibilities" is only known as a detriment. > It's "only" the single most important class of bugs for system safety. Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. Is it actually true? It seems to me this great experiment is actually proving it probably isn't. > This kind of deflection and denialism isn't helping. Once again, I asked for proof that the claim was true, you've brought nothing, and instead have projected your shortcomings onto my argument. > And I'm saying this as someone who really likes C++. Have you ever pushed for C++ to replace C programs because you assume they would be "better" according to some ill defined and never measured metrics?
    - spacechild1 11mo ago
emmelaich 11mo ago
They need to do this carefully and with adversarial testing. There are safety measures in e.g. gnu tar that really should be replicated. But they are not to do with parsing, but the semantics. IOW, what's your specification?
bigstrat2003 11mo ago
I agree that new software should be written in Rust or another, safer language. But I don't agree that it's wise to start retrofitting old software in this way. New code is almost always worse in quality than old code, and I do not believe that the safety gains from Rust are so advantageous that they will offset that factor.
deleted 11mo ago
[deleted]
throw10920 11mo ago
This is a false dichotomy. There are memory-safe languages that are already proven and accepted in core Debian code that don't come with the downsides of Rust.

Galanwe 11mo ago

[flagged]

nixosbestos 11mo ago
> it's factually just better, am I right? so cool to see people getting it!
metrix 11mo ago
While I get your view, I think examples would help to move the conversation along in a more constructive manner

astockwell 11mo ago

Would this logically extend to also include C-reliant languages like Python and Ruby (the latter being mostly a grammar underpinned by C) as technical debt also?

gpm 11mo ago
Not really. All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs. There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.
- dcsommer 11mo ago
  > basically fine How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.
  - gpm 11mo ago
    Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem. My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.
    - bigyabai 11mo ago
      It depends, what language was the sandbox written in?
      - gpm 11mo ago
        Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.
  - zahlman 11mo ago
    How many ways to cause a segmentation fault in CPython, that don't start with deliberate corruption of the bytecode, are you aware of? How is "type confusion" a security issue?
tempest_ 11mo ago
Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code. A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.
- physicsguy 11mo ago
  Most Python libraries that relies on C are numerical stuff. From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library. On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.

allisdust 11mo ago

Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back against any and every use, promotion of Rust. The unknown fear seem to be that they will be left behind if it takes off. I completed my battles with Rust. I don't even use it anymore (because of lack of opportunities). But I love Rust. It is here to stay and expand. Thanks to the LLMs and the demand for verifiability.

kstrauser 11mo ago
I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); let altitude2 = Feet(16); hover(altitude2); } This fails at build time with: 12 | hover(altitude2); | ----- ^^^^^^^^^ expected `Meters`, found `Feet` | | | arguments to this function are incorrect Guaranteeing that I’ve never mixed units means I don’t have to worry about parking my spacecraft at 1/3 the expected altitude. Now I can concentrate on the rest of the logic. The language has my back on the types so I never have to waste brain cycles on the bookkeeping parts. That’s one example. It’s not unique to Rust by a long shot. But it’s still a vast improvement over C, where that same signed 32 bit data type is the number of eggs in a basket, the offset of bytes into a struct, the index of an array, a UTF-8 code point, or whatever else. This really shows up at refactoring time. Move some Rust code around and it’ll loudly let you know exactly what you need to fix before it’s ready. C? Not so much.
- OptionOfT 11mo ago
  It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

wolvesechoes 11mo ago

If people really, really want to have all infra written in Rust, they should step-up and stop using LLVM.

jsheard 11mo ago
There is a pure-Rust compiler backend in the works, but that's going to take a long time to mature so it's just pragmatic to use LLVM in the meantime. Especially since the exploitation potential is pretty contrived in this case - if you compile compromised code then you're probably owned anyway, regardless of the backends memory safety.
OptionOfT 11mo ago
What is the concern with LLVM? I'm asking because I genuinely don't know.
- wolvesechoes 11mo ago
  I would assume that because it is written in unsafe C++, it creates technical debt that should addressed rather soon.
- smithkl42 11mo ago
  I think the issue he's pointing at is that LLVM is itself written in C++ - so the entire "trusted" Rust toolchain depends on trusting a huge C++ app.
  - vlovich123 11mo ago
    Thankfully the “trust” you need out of a compiler is very very different. It would be closer to claiming you need to compile it on a Rust OS too because you’re trusting a large C/C++ app. Separation of concerns solves this because the compiler has minimal impact on the trustedness of the code the Rust compiler generates. Indeed, one would expect that all the ways that the LLVM compiler fails are ways any Rust implementation would fail too - by generating the wrong code which is rarely if ever due to memory safety or thread safety issues. There may be other reasons to write the compiler backend in Rust but I wouldn’t put the trust of compiled Rust code as anywhere near the top of reasons to do that.

krater23 11mo ago

Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.

woodruffw 11mo ago
> Memory safety is mostly an issue of the past. Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1]. > But we have tools to prevent that. The new security issues are supply chain attacks. Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or. [1]: https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
01HNNWZ0MV43FF 11mo ago
What part of C package management defends against supply chain attacks? Does it audit third-party code for you?
- illuminator83 11mo ago
  I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain. The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred. Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done. In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.
  - uecker 11mo ago
    I never found it hard to add a C library to my projects using pkg-config. And yes, when the package came from Debian I have some trust that it is not a huge supply chain risk. I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager manager and Cargo or npm or the countless Python managers should all not exist either.

tmtvl 11mo ago

> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under <https://github.com/pop-os/cosmic-applets https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: <https://savannah.gnu.org/projects/coreutils/ https://savannah.gnu.org/projects/coreutils/>).

01HNNWZ0MV43FF 11mo ago
To be fair GUI code is going to be harder to read than a non-interactive utility, in any two languages
kstrauser 11mo ago
I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit. If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.
- cogman10 11mo ago
  That's a style choice that I think comes from former C++ devs. Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.
  - kstrauser 11mo ago
    I don’t think that’s quite right. I haven’t written C++ since the 90s, and I use IDEs (Emacs and Zed), but I still sometimes reach a mental threshold where I look at my screen and see way too many names to have to hold in my mental buffer, then decide to make them more explicit.

jcranmer 11mo ago

Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years). There's other languages that are considered acceptable, even desirable, languages to write applications in (e.g., Java, PHP, Go), but Rust is really the first language to compete sufficiently close to C's competence for people to contemplate adding it to the base-system-languages list. I'd say only Go has ever come close to approaching that threshold, but I've never seen it contemplated for something like systemd. Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious.

embedding-shape 11mo ago
> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community. So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.
- julian-klode 11mo ago
  If anyone sees that horrible mess of hacks around pre-STL C++'s lacks of namespace in combination with latest C++ features as part of the C++ community I'd be very surprised :D If APT were a hardcore C++ project surely we'd have like adopted namespaces everywhere by now.
- jenadine 11mo ago

mattbee 11mo ago

The Fil-C project ( https://fil-c.org/ https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.

tialaramex 11mo ago
If you're single platform (Fil-C is x86-64 only), if the program is finished (Fil-C doesn't magically make maintaining a C project any easier to handle) and if performance isn't relevant (Fil-C is and despite its originator's confidence always will be bigger and slower than what you have today) then I agree.
loeg 11mo ago
Making core package infrastructure 10x slower doesn't seem especially pragmatic.
- mattbee 11mo ago
  The author's benchmarks suggest 10× would be a pathological case! But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.
  - loeg 11mo ago
    We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)
    - ChocolateGod 11mo ago
      Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days. > We have an alternative that isn't 10x slower, and comes with many other benefits Anyone involved with development around a fruity company would say Swift ;)

coderjames 11mo ago

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and .ar file formats are both from the 70s; what new benefits will users or developers gain from that thoroughly battle-tested code being thrown out and rewritten in a new language with a whole new set of compatibility issues and bugs?

ok123456 11mo ago
There are none. This is a canonical employee trying to force Ubuntu's decisions (rust coretools) on the wider Debian community. Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.
blub 11mo ago
Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…
- julian-klode 11mo ago
  Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.
  - RustSupremacist 11mo ago
    You have never been skilled at being considerate: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

a-dub 11mo ago

rust is kinda ugly. i think i like zig better.

drnick1 11mo ago
Actually I agree. I wish Rust kept the basic C syntax for function etc. I really hate def, fn, and other such keywords.

jbv027 11mo ago

It is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.

Greed 11mo ago
Wow, I've never considered this aspect of it but you're right. If you want widespread access to incoming developers that can contribute to your project, that really does mean Rust by default at this point if you want a low level language regardless of what you prefer.
RustSupremacist 11mo ago
Inviting rank amateurs to established projects while expecting them to operate as free labor in the hopes of future relevance for employment has a distinctly different feel. Missives like the OP feel like preying on a desperate and young generation when paired with the commentary. If all the entry-level jobs are C or C++, do you think companies would have a hard time filling them? Would the unemployed new graduates really shun gainful employment if Rust wasn't part of the equation? Meanwhile, hiring managers left and right are reporting that within hours of a job being posted, they are flooded with hundreds of applications. And you can't find a single person because of the programming language of your stack? And to remedy this, you're going to rewrite your stack in an unproven language? Have you considered that if you can't find anyone that it might not be a programming language or tech stack problem?
zahlman 11mo ago
A pity the banks didn't do that with COBOL....
- pjmlp 11mo ago
  They did, Java and .NET.
physicsguy 11mo ago

einpoklum 11mo ago

> Critical infrastructure still written in C ... is technical debt that is only going to get worse over time. No. Rust is not magic, it just forces a discipline in which certain safety checks can be made automatically (or are obviated entirely). In other languages like C, the programmer needs to perform those checks; and it's technical debt if the C code is not coded carefully and reviewed for such issues. If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid. > Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. That's not true. First, it's not a well-defined statement, since "what we know now" about language design is, as it has always been, a matter of debate and a variety of opinions. But even regardless of that - C was a language with certain design choices and aesthetics. Rust does not at _all_ share those choices - even if you tack on "and it must be safe". For example: Rust is much richer language - in syntax, primitive types, and standard library - than C was intended to be.

Avamander 11mo ago
> If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid. How many decades have we tried this? How many more to see that it just hasn't panned out like you describe?
alfiedotwtf 11mo ago
> If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. History shows again and again that this statement is impossible.. Name a large C application that’s widely used, and I’ll show you at least one CVE that’s caused by a memory leak from the project

samdoesnothing 11mo ago

Oh please, in a decade Rust will also be technical debt and people will be wanting to write it in Brust or whatever is the trendy new language.

steveklabnik 11mo ago
It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.
- samdoesnothing 11mo ago
  That makes no sense. It was much longer than 10 years before people considered C to be tech debt for example. Idk if it will be 10 years exactly, but we are seeing better languages emerging (Swift 6, Mojo, probably others) that provide the same safety guarantees and performance/use case profiles as Rust, but are vastly more ergonomic and lovely to use. I fear Linux was hasty integrating Rust because it will likely prevent them from integrating something better in the near future.
  - steveklabnik 11mo ago
    You’re the one that said ten years.
    - samdoesnothing 11mo ago
      I said ten years from now...
    - kasabali 11mo ago
      You're the one who said "ten years since Rust 1.0"
      - Klonoar 11mo ago
        The person who they replied to stated a decade. This whole thing is pretty clear cut and dry.

themafia 11mo ago

> It's not as if Rust is that much more difficult to write than C According to what? > Rust is explicitly designed There is no standard. It's accidentally designed. > knowing what we know now about language design and code safety. You've solved one class of bugs outside of "unsafe {}". The rest are still present.

spacechild1 11mo ago
> There is no standard. It's accidentally designed. Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment... > You've solved one class of bugs outside of "unsafe {}". It's "only" the single most important class of bugs for system safety. This kind of deflection and denialism isn't helping. And I'm saying this as someone who really likes C++.
- themafia 11mo ago
  > that you can't design a language without an official standard? No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed. > The phrase "design by committee" isn't typically used as a compliment... While the phrase "emergent incompatibilities" is only known as a detriment. > It's "only" the single most important class of bugs for system safety. Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. Is it actually true? It seems to me this great experiment is actually proving it probably isn't. > This kind of deflection and denialism isn't helping. Once again, I asked for proof that the claim was true, you've brought nothing, and instead have projected your shortcomings onto my argument. > And I'm saying this as someone who really likes C++. Have you ever pushed for C++ to replace C programs because you assume they would be "better" according to some ill defined and never measured metrics?
  - spacechild1 11mo ago

emmelaich 11mo ago

They need to do this carefully and with adversarial testing. There are safety measures in e.g. gnu tar that really should be replicated. But they are not to do with parsing, but the semantics. IOW, what's your specification?

bigstrat2003 11mo ago

I agree that new software should be written in Rust or another, safer language. But I don't agree that it's wise to start retrofitting old software in this way. New code is almost always worse in quality than old code, and I do not believe that the safety gains from Rust are so advantageous that they will offset that factor.

deleted 11mo ago

[deleted]

throw10920 11mo ago

This is a false dichotomy. There are memory-safe languages that are already proven and accepted in core Debian code that don't come with the downsides of Rust.