4 ms·

Java and Rust have actually very similar memory safety profiles. Rust let's you within the language escape the memory safety requirements whereas Java does not

Java and Rust have actually very similar memory safety profiles. Rust let's you within the language escape the memory safety requirements whereas Java does not but both are considered memory safe languages. Rust also enforces thread safety as well which Java does not, but the slower JVM memory model doesn't let race conditions become memory safety issues whereas Rust is lower-level like Zig/C/C++ and thus thread safety could be a memory safety issue. Zig has an identical memory safety profile to C. It has facilities to make it easier to stay memory safe, but those facilities are basically equivalent to what you have in C++ and that's equivalent memory safety profile as C. > So among these four languages we already have four levels of memory safety, none of them is 100% No, you've pretended like there's four when really it's Java / Rust which are safe by default and Zig/C/C++ which are unsafe by default. One effective metric to evaluate is memory safety per LoC. Rust is ~0.2 vulnerabilities per MLoC. Java is effectively 0. C and C++ both seem to be about 1,000 vulnerabilities per MLoC. Zig is too new and hasn't had any analysis done on it, but generously it's likely at least 10-100. So the table stakes could be defined as 1 memory safety vulnerability per MLoC.

applfanboysbgon 3mo ago
> Rust is ~0.2 vulnerabilities per MLoC. Java is effectively 0. C and C++ both seem to be about 1,000 vulnerabilities per MLoC. Zig is too new and hasn't had any analysis done on it, but generously it's likely at least 10-100. You have just described six orders of magnitude in your attempt to rebut pron pointing out the four languages have four levels of memory safety.
- joshuamorton 3mo ago
  "two things are within an order of magnitude, and two other things are within an order of magnitude, and those two groups are three orders of magnitude apart" does sound like two groups to me.
  - applfanboysbgon 3mo ago
    > those two groups are three orders of magnitude apart They aren't necessarily, though. Supposing that Zig were "10 issues per MLoC" (with just as much handwaving as the original poster), it would be equidistant from Rust and C. Java may also be more than one order of magnitude away from Rust; we say ~0 but is it 0.01, 0.001, 0.0001...? And why is "1 issue per MLoC" the acceptable metric that delineates what constitutes table-stakes memory-safe language? Because it's a nice, round-sounding number? I think 0 is a nicer, rounder number than 1, so let's call only Java table stakes and condemn all other languages to the garbage bin, tradeoffs be damned. Or would you say your arbitrary delineation point is worth more than mine?
    - joshuamorton 3mo ago
      > Or would you say your arbitrary delineation point is worth more than mine? Yes for the reasons I already gave. I think that at the point that you're having to stretch the numbers from their post to the breaking point to remove the pretty clear order of magnitude differences it's not really a constructive way to engage. I think you have two groups with one at ~.1 and one on ~100. You seen to either disagree with that, or think it doesn't matter, I'm not sure which. But taking that assumption as true it is self evident that the 3-order-of magnitude demarcation is not arbitrary.
      - applfanboysbgon 3mo ago
        I think it is absolutely arbitrary. First because I believe every order of magnitude is significant. You handwave away that one order of magnitude difference is fine but three is bad. I think this is hypocritcal, and that if you want to be a memory safety purist who ignores all tradeoffs and declares a language fundamentally unusable on safety grounds, even a single order of magnitude of additional issues should clearly be unacceptable. And simultaneously you group them arbitrarily -- what is your actual basis for suggesting that Zig code is more likely to be 100 than 10, or that 10 somehow bares grouping at 100 rather than grouping .1 and 10 together at 1? You also fail to address that there may be more than one order of magnitude between Rust and Java. It is entirely plausible that Rust is closer to Zig than to Java. --- Rate-limit edit replying to below response: > a variety of statements I haven't said We are in a conversation thread specifically about statements of this nature, which I was contesting. The original poster of this thread called their arbitrary definition of memory safety "table stakes" and explicitly said that they rule out Zig as a language completely on this basis alone. If you don't agree with them, I'm not sure what we're discussing. > you take issue with the assumptions I'm making ... but you could just state that instead of saying that I'm being hypocritical The only assumption I disagreed with is assigning Zig to exactly 100 when a poster I was replying to originally asserted a range of "10 or 100"; and regardless of whether we agree on assigning a concrete lower/upper bound to that assumption, everything else is not an assumption but a value judgment given the condition "assuming the premise holds". Yet your position is taking those value judgments - which orders of magnitudes to accept, which to group together as being the same degree of memory safety - and asserting them as objectively correct boundaries with minimal rationalisation beyond "because I feel it is so".
pron 3mo ago
> Java and Rust have actually very similar memory safety profiles They really don't. Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. > Zig has an identical memory safety profile to C It really doesn't. Zig gives you the same spatial memory safety as Rust and very much not like C (and violations of spatial memory safety are a bigger cause of vulnerabilities than violations of temporal memory safety).
- kibwen 3mo ago
  > Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structures out of the standard library and into the compiler itself, thereby reducing the amount of occurrences of the string "unsafe" in the source, code, but this would do nothing to reduce the size of the trusted computing base that Rust presents. In fact, it would decrease our confidence in that code, because Rust libraries have a robust ecosystem of tools for validating their correctness, unlike whatever bespoke IR the Rust compiler itself is emitting. Java's own data structures are implemented with the support of an extensive runtime written in C++, which forms their own trusted computing base that every user of Java relies upon, and demands just as much careful auditing as any data structure in the Rust standard library.
  - bluecalm 3mo ago
    The point is not that those specific implementations use unsafe Rust but to illustrate that to write even basic data structures you need unsafe Rust.
    - afdbcreid 3mo ago
      That's just false. You can use `Arc` or even one of the safe GC crates available, and get semantics like Java with no `unsafe`.
      - 3mo ago
xedrac 3mo ago
Java may be memory safe, but no memory is safe from the JVM. :)

applfanboysbgon 3mo ago

> Rust is ~0.2 vulnerabilities per MLoC. Java is effectively 0. C and C++ both seem to be about 1,000 vulnerabilities per MLoC. Zig is too new and hasn't had any analysis done on it, but generously it's likely at least 10-100. You have just described six orders of magnitude in your attempt to rebut pron pointing out the four languages have four levels of memory safety.

joshuamorton 3mo ago
"two things are within an order of magnitude, and two other things are within an order of magnitude, and those two groups are three orders of magnitude apart" does sound like two groups to me.
- applfanboysbgon 3mo ago
  > those two groups are three orders of magnitude apart They aren't necessarily, though. Supposing that Zig were "10 issues per MLoC" (with just as much handwaving as the original poster), it would be equidistant from Rust and C. Java may also be more than one order of magnitude away from Rust; we say ~0 but is it 0.01, 0.001, 0.0001...? And why is "1 issue per MLoC" the acceptable metric that delineates what constitutes table-stakes memory-safe language? Because it's a nice, round-sounding number? I think 0 is a nicer, rounder number than 1, so let's call only Java table stakes and condemn all other languages to the garbage bin, tradeoffs be damned. Or would you say your arbitrary delineation point is worth more than mine?
  - joshuamorton 3mo ago
    > Or would you say your arbitrary delineation point is worth more than mine? Yes for the reasons I already gave. I think that at the point that you're having to stretch the numbers from their post to the breaking point to remove the pretty clear order of magnitude differences it's not really a constructive way to engage. I think you have two groups with one at ~.1 and one on ~100. You seen to either disagree with that, or think it doesn't matter, I'm not sure which. But taking that assumption as true it is self evident that the 3-order-of magnitude demarcation is not arbitrary.
    - applfanboysbgon 3mo ago
      I think it is absolutely arbitrary. First because I believe every order of magnitude is significant. You handwave away that one order of magnitude difference is fine but three is bad. I think this is hypocritcal, and that if you want to be a memory safety purist who ignores all tradeoffs and declares a language fundamentally unusable on safety grounds, even a single order of magnitude of additional issues should clearly be unacceptable. And simultaneously you group them arbitrarily -- what is your actual basis for suggesting that Zig code is more likely to be 100 than 10, or that 10 somehow bares grouping at 100 rather than grouping .1 and 10 together at 1? You also fail to address that there may be more than one order of magnitude between Rust and Java. It is entirely plausible that Rust is closer to Zig than to Java. --- Rate-limit edit replying to below response: > a variety of statements I haven't said We are in a conversation thread specifically about statements of this nature, which I was contesting. The original poster of this thread called their arbitrary definition of memory safety "table stakes" and explicitly said that they rule out Zig as a language completely on this basis alone. If you don't agree with them, I'm not sure what we're discussing. > you take issue with the assumptions I'm making ... but you could just state that instead of saying that I'm being hypocritical The only assumption I disagreed with is assigning Zig to exactly 100 when a poster I was replying to originally asserted a range of "10 or 100"; and regardless of whether we agree on assigning a concrete lower/upper bound to that assumption, everything else is not an assumption but a value judgment given the condition "assuming the premise holds". Yet your position is taking those value judgments - which orders of magnitudes to accept, which to group together as being the same degree of memory safety - and asserting them as objectively correct boundaries with minimal rationalisation beyond "because I feel it is so".

pron 3mo ago

> Java and Rust have actually very similar memory safety profiles They really don't. Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. > Zig has an identical memory safety profile to C It really doesn't. Zig gives you the same spatial memory safety as Rust and very much not like C (and violations of spatial memory safety are a bigger cause of vulnerabilities than violations of temporal memory safety).

kibwen 3mo ago
> Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structures out of the standard library and into the compiler itself, thereby reducing the amount of occurrences of the string "unsafe" in the source, code, but this would do nothing to reduce the size of the trusted computing base that Rust presents. In fact, it would decrease our confidence in that code, because Rust libraries have a robust ecosystem of tools for validating their correctness, unlike whatever bespoke IR the Rust compiler itself is emitting. Java's own data structures are implemented with the support of an extensive runtime written in C++, which forms their own trusted computing base that every user of Java relies upon, and demands just as much careful auditing as any data structure in the Rust standard library.
- bluecalm 3mo ago
  The point is not that those specific implementations use unsafe Rust but to illustrate that to write even basic data structures you need unsafe Rust.
  - afdbcreid 3mo ago
    That's just false. You can use `Arc` or even one of the safe GC crates available, and get semantics like Java with no `unsafe`.
    - 3mo ago

xedrac 3mo ago

Java may be memory safe, but no memory is safe from the JVM. :)