5 ms·

> I would assume trivial means the default approach works for most cases. Perhaps mutable global variables are not a common use case. Unsafe might make it easie

by nu11ptr 10mo ago

> I would assume trivial means the default approach works for most cases. Perhaps mutable global variables are not a common use case. Unsafe might make it easier, but it’s not obvious and probably undesired. I'm a Rust fan, and I would generally agree with this. It isn't difficult, but trivial isn't quite right either. And no, global vars aren't terribly common in Rust, and when used, are typically done via LazyLock to prevent data races on intialization. > I don’t know Rust, but I’ve heard pockets of unsafe code in a code base can make it hard to trust in Rust’s guarantees. The compromise feels like the language didn’t actually solve anything. Not true at all. First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it. Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. The typical Rust paradigm is to let low level crates (libraries) do the unsafe stuff for you, test it thoroughly (Miri, fuzzing, etc.), and then the community builds on these crates with their safe programs. In contrast, C/C++ programs have every statement in an "unsafe block". In Rust, you know where UB can or cannot happen.

irishcoffee 10mo ago
> Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. By the time suspicious behavior happens, isn’t it kind of a critical inflection point? For example, the news about react and next that came out. Once the code is deployed, re-deploying (especially with a systems language that quite possibly lives on an air-gapped system with a lot of rigor about updates) means you might as well have used C, the dollar cost is the same.
- stouset 10mo ago
  Are you with a straight face saying that occasionally having a safety bug in limited unsafe areas of Rust is functionally the same as having written the entire program in an unsafe language like C? One, the dollar cost is not the same. The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs.
  - irishcoffee 10mo ago
    > The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Hmm, according to whom, exactly? > Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs. And yet somehow the internet went down because of a program written in rust that didn’t validate input.
    - kibwen 10mo ago
      > And yet somehow the internet went down because of a program written in rust that didn’t validate input. What? The Cloudflare bug was from a broken system configuration that eventually cascaded into (among other things) a Rust program with hardcoded limits that crashed loudly. In no way did that Rust program bring down the internet; it was the canary, not the gas leak. Anybody trying to blame Rust for that event has no idea what they're talking about.
    - nu11ptr 10mo ago
      > And yet somehow the internet went down because of a program written in rust that didn’t validate input. Tell me which magic language creates programs free of errors? It would have been better had it crashed and compromised memory integrity instead of an orderly panic due to an invariant the coder didn't anticipate? Type systems and memory safety are nice and highly valuable, but we all know as computer scientists we have yet to solve for logic errors.
    - bigstrat2003 10mo ago
      > Hmm, according to whom, exactly? Well, Google for one. https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... > And yet somehow the internet went down because of a program written in rust that didn’t validate input. You're ignoring other factors (it wasn't just Cloudflare's rust code that led to the issue), but even setting that aside your framing is not accurate. The rust program went down because the programmer made a choice that, given invalid input, it should crash. This could happen in every language ever made. It has nothing to do with rust.
- mh2266 10mo ago
  This just skips the: > First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it. from the original comment. Meanwhile all C code is implicitly “unsafe”. Rust at least makes it explicit! But even if you ignore memory safety issues bypassed by unsafe, Rust forces you to handle errors, it doesn’t let you blow up on null pointers with no compiler protection, it allows you to represent your data exhaustively with sum types, etc etc etc
  - irishcoffee 10mo ago
    Isn’t rust proffered up as a systems language? One that begged to be accepted into the Linux kernel? Don’t device drivers live in the Linux kernel tree? So, unsafe code is generally approved in device driver code? Why not just use C at that point?
    - stouset 10mo ago
      I am quite certain that someone who has been on HN as long as you have is capable of understanding the difference between 0% compiler-enforced memory safety in a language with very weak type safety guarantees and 95%+ of code regions even in the worst case of low-level driver code that performs DMA with strong type safety guarantees.
      - disappoint 10mo ago
        Please explain the differences in typical aliasing rules between C and Rust. And please explain posts like https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41947921 https://news.ycombinator.com/item?id=41947921 https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
        stouset 10mo ago
        Is three random people saying unsafe Rust is hard supposed to make us forget about C’s legendary problems with UB, nil pointers, memory management bugs, and staggering number of CVEs? You have zero sense of perspective. Even if we accept the premise that unsafe Rust is harder than C (which frankly is ludicrous on the face of it) we’re talking about a tiny fraction of the overall code of Rust programs in the wild. You have to pay careful attention to C’s issues virtually every single line of code. With all due respect this may be the singular dumbest argument I’ve ever had the displeasure of participating in on Hacker News.
- nu11ptr 10mo ago
  > might as well have used C, the dollar cost is the same. When your unsafe area is small, you put a LOT of thought/testing into those small blocks. You write SAFETY comments explaining WHY it is safe (as you start with the assumption there will be dragons there). You get lots of eyeballs on them, you use automated tools like miri to test them. So no, not even in the same stratosphere as "might as well have used C". Your probability of success vastly higher. A good Rust programmer uses unsafe judiciously, where as a C programmer barely blinks as they need ensure every single snippet of their code is safe, which in a large program, is an impossible task. As an aside, having written a lot of C, the ecosystem and modern constructs available in Rust make writing large scale programs much easier, and that isn't even considering the memory safety aspect I discuss above.
  - disappoint 10mo ago
    SAFETY comments do not magically make unsafe Rust correct nor safe. And Miri cannot catch everything, and is magnitudes slower than regular program running. https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259 https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740... https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
    - aw1621107 10mo ago
      I think you might be misreading GP's comment. They are not claiming that SAFETY comments and MIRI guarantee correctness/safety; those are just being used as examples of the extra effort that can be and are expended on the relatively few unsafe blocks in your codebase, resulting in "your probability of success [being] vastly higher" compared to "might as well have used C".
      - disappoint 10mo ago
        [flagged]

by nu11ptr 10mo ago

irishcoffee 10mo ago

> Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. By the time suspicious behavior happens, isn’t it kind of a critical inflection point? For example, the news about react and next that came out. Once the code is deployed, re-deploying (especially with a systems language that quite possibly lives on an air-gapped system with a lot of rigor about updates) means you might as well have used C, the dollar cost is the same.

stouset 10mo ago
Are you with a straight face saying that occasionally having a safety bug in limited unsafe areas of Rust is functionally the same as having written the entire program in an unsafe language like C? One, the dollar cost is not the same. The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs.
- irishcoffee 10mo ago
  > The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Hmm, according to whom, exactly? > Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs. And yet somehow the internet went down because of a program written in rust that didn’t validate input.
  - kibwen 10mo ago
    > And yet somehow the internet went down because of a program written in rust that didn’t validate input. What? The Cloudflare bug was from a broken system configuration that eventually cascaded into (among other things) a Rust program with hardcoded limits that crashed loudly. In no way did that Rust program bring down the internet; it was the canary, not the gas leak. Anybody trying to blame Rust for that event has no idea what they're talking about.
  - nu11ptr 10mo ago
    > And yet somehow the internet went down because of a program written in rust that didn’t validate input. Tell me which magic language creates programs free of errors? It would have been better had it crashed and compromised memory integrity instead of an orderly panic due to an invariant the coder didn't anticipate? Type systems and memory safety are nice and highly valuable, but we all know as computer scientists we have yet to solve for logic errors.
  - bigstrat2003 10mo ago
    > Hmm, according to whom, exactly? Well, Google for one. https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... > And yet somehow the internet went down because of a program written in rust that didn’t validate input. You're ignoring other factors (it wasn't just Cloudflare's rust code that led to the issue), but even setting that aside your framing is not accurate. The rust program went down because the programmer made a choice that, given invalid input, it should crash. This could happen in every language ever made. It has nothing to do with rust.
mh2266 10mo ago
This just skips the: > First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it. from the original comment. Meanwhile all C code is implicitly “unsafe”. Rust at least makes it explicit! But even if you ignore memory safety issues bypassed by unsafe, Rust forces you to handle errors, it doesn’t let you blow up on null pointers with no compiler protection, it allows you to represent your data exhaustively with sum types, etc etc etc
- irishcoffee 10mo ago
  Isn’t rust proffered up as a systems language? One that begged to be accepted into the Linux kernel? Don’t device drivers live in the Linux kernel tree? So, unsafe code is generally approved in device driver code? Why not just use C at that point?
  - stouset 10mo ago
    I am quite certain that someone who has been on HN as long as you have is capable of understanding the difference between 0% compiler-enforced memory safety in a language with very weak type safety guarantees and 95%+ of code regions even in the worst case of low-level driver code that performs DMA with strong type safety guarantees.
    - disappoint 10mo ago
      Please explain the differences in typical aliasing rules between C and Rust. And please explain posts like https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41947921 https://news.ycombinator.com/item?id=41947921 https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
      - stouset 10mo ago
        Is three random people saying unsafe Rust is hard supposed to make us forget about C’s legendary problems with UB, nil pointers, memory management bugs, and staggering number of CVEs? You have zero sense of perspective. Even if we accept the premise that unsafe Rust is harder than C (which frankly is ludicrous on the face of it) we’re talking about a tiny fraction of the overall code of Rust programs in the wild. You have to pay careful attention to C’s issues virtually every single line of code. With all due respect this may be the singular dumbest argument I’ve ever had the displeasure of participating in on Hacker News.
nu11ptr 10mo ago
> might as well have used C, the dollar cost is the same. When your unsafe area is small, you put a LOT of thought/testing into those small blocks. You write SAFETY comments explaining WHY it is safe (as you start with the assumption there will be dragons there). You get lots of eyeballs on them, you use automated tools like miri to test them. So no, not even in the same stratosphere as "might as well have used C". Your probability of success vastly higher. A good Rust programmer uses unsafe judiciously, where as a C programmer barely blinks as they need ensure every single snippet of their code is safe, which in a large program, is an impossible task. As an aside, having written a lot of C, the ecosystem and modern constructs available in Rust make writing large scale programs much easier, and that isn't even considering the memory safety aspect I discuss above.
- disappoint 10mo ago
  SAFETY comments do not magically make unsafe Rust correct nor safe. And Miri cannot catch everything, and is magnitudes slower than regular program running. https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259 https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740... https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
  - aw1621107 10mo ago
    I think you might be misreading GP's comment. They are not claiming that SAFETY comments and MIRI guarantee correctness/safety; those are just being used as examples of the extra effort that can be and are expended on the relatively few unsafe blocks in your codebase, resulting in "your probability of success [being] vastly higher" compared to "might as well have used C".
    - disappoint 10mo ago
      [flagged]