3 ms·

> just another memory unsafe language Also, treating all languages that don't ensure full memory safety as if they're equally problematic is silly. The reason

by pron 1y ago

> just another memory unsafe language Also, treating all languages that don't ensure full memory safety as if they're equally problematic is silly. The reason not ensuring memory safety is bad is because memory unsafety as at the root of some bugs that are both common, dangerous, and hard to catch. Only not all kinds of memory unsafety are equally problematic, Zig does ensure the lack of the the most dangerous kind of unsafety (out-of-bounds access) while making the other kind (use-after-free) easier to find. That the distinction between "fully memory safe" and "not fully memory safe" is binary is also silly not just because of the above, but because no lanugage, not even Java, is truly "fully memory safe", as programs continue to employ components not written in memory safe languages. Furthermore, Zig has (or intends to have) novel features (among low-level languages) that help reduce bugs beyond those caused by memory unsafety.

IshKebab 1y ago
Right but I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards. Even if it is much much better than C (clearly), it's hard to get excited about a language that "unsolves" a longstanding problem. > not even Java, is truly "fully memory safe", as programs continue to employ components not written in memory safe languages. This is a silly point.
- pron 1y ago
  > I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards Memory safety (like soundly ensuring any non-trivial property) must come at a cost (that's just complexity theory). You can pay for it with added footprint (Java) or with added effort (Rust). Some people are disappointed that Zig offer more safety than C++ but less than Rust in exchange for other important benefits, while others are disappointed that the price you have to pay for even more safety in Rust is not a price they're happy to pay. BTW, many Rust programs do use GC (that's what Rc/Arc are), it's just one that optimises for footprint rather than speed (which is definitely okay when you don't use the GC as much as in Java, but it's not really "without GC", either, when many programs do rely on GC to some extent). > This is a silly point. Why? It shows that even those who wish to make the distinction seem binary themselves accept that it isn't, and really believe that it matters just how much risk you take and how much you pay to reduce it. (You could even point out that memory corruption can occur at the hardware level, so not only is the promise of zero memory corruption not necessarily worth any price, but it is also unattainable, even in principle, and if that were truly the binary line, then all of software is on the same side of it.)
  - IshKebab 1y ago
    > You can pay for it with added footprint (Java) or with added effort (Rust) ... or runtime errors (C, Zig presumably). Ok Zig is clearly better than C in that regard but I think it remains to be seen if it is better enough. > many Rust programs do use GC (that's what Rc/Arc are) This is not what most people mean when they say GC. > Why? Because when we're talking about the memory safety of a language we're talking about the code you write in that language (and excluding explicit opt-in to memory unsafe behaviour, e.g. `unsafe` or Python's `ctypes`). Saying "Java isn't memory safe because you can call C" is like saying "bicycles can fly because you can put them on a plane".
hitekker 1y ago
If you one day write a blog, I would want to subscribe. Your writing feels accessible. I find it makes complex topics approachable. Or at least, it gives me a feel of concepts that I would otherwise have no grasp on. Other online writing tends to be permeated by a thick lattice of ideology or hyper-technical arcanery that inhibits understanding.
- pron 1y ago
  Thank you! I did have one once (https://pron.github.io https://pron.github.io) but I don't know how accessible it is :) (two post series are book-length)
- Ygg2 1y ago
  > Your writing feels accessible. I find it makes complex topics approachable Yeah. By omitting a large swath of nuance. It reeks of "you can approximate cow with a sphere the size of Jupiter". It's baffling ludicrous. Any rhetorical device that equates Java/C# (any memory safe Turing language ) safety with C is most likely a fallacy.
  - hudon 1y ago
    I interpreted his post as saying it's not binary safe/unsafe, but rather a spectrum, with Java safer than C because of particular features that have pros and cons, not because of a magic free safe/unsafe switch. He's advocating for more nuance, not less.
    - Ygg2 1y ago
      Yeah, it's not binary; it's just a step function. /s No, it's as close to binary as you can get. Is your only source of Undefined Behavior FFI specially marked functions and/or packages? Have you checked data races for violating thread safety invariants? If yes - You're safe. Allow a bit of unsafety into the system, like Go, and the unsafety can creep into your ecosystem. See https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html Is Go in mostly safer than C++? Maybe. But you can never prove that about either of them. So while you may pretend one is safer than the other, it's a bit like picking which boat is taking on more water. Can you prove Rust code is safe? Well there is the simple way - no unsafe. But what about unsafe blocks? Yes, you can prove it for them as well. If the unsafe code block is it will note safety invariants and why are they preserved by unsafe block. Can this be practically done? Depends on the crate, but with enough effort, yes.

by pron 1y ago

IshKebab 1y ago

Right but I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards. Even if it is much much better than C (clearly), it's hard to get excited about a language that "unsolves" a longstanding problem. > not even Java, is truly "fully memory safe", as programs continue to employ components not written in memory safe languages. This is a silly point.

pron 1y ago
> I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards Memory safety (like soundly ensuring any non-trivial property) must come at a cost (that's just complexity theory). You can pay for it with added footprint (Java) or with added effort (Rust). Some people are disappointed that Zig offer more safety than C++ but less than Rust in exchange for other important benefits, while others are disappointed that the price you have to pay for even more safety in Rust is not a price they're happy to pay. BTW, many Rust programs do use GC (that's what Rc/Arc are), it's just one that optimises for footprint rather than speed (which is definitely okay when you don't use the GC as much as in Java, but it's not really "without GC", either, when many programs do rely on GC to some extent). > This is a silly point. Why? It shows that even those who wish to make the distinction seem binary themselves accept that it isn't, and really believe that it matters just how much risk you take and how much you pay to reduce it. (You could even point out that memory corruption can occur at the hardware level, so not only is the promise of zero memory corruption not necessarily worth any price, but it is also unattainable, even in principle, and if that were truly the binary line, then all of software is on the same side of it.)
- IshKebab 1y ago
  > You can pay for it with added footprint (Java) or with added effort (Rust) ... or runtime errors (C, Zig presumably). Ok Zig is clearly better than C in that regard but I think it remains to be seen if it is better enough. > many Rust programs do use GC (that's what Rc/Arc are) This is not what most people mean when they say GC. > Why? Because when we're talking about the memory safety of a language we're talking about the code you write in that language (and excluding explicit opt-in to memory unsafe behaviour, e.g. `unsafe` or Python's `ctypes`). Saying "Java isn't memory safe because you can call C" is like saying "bicycles can fly because you can put them on a plane".

hitekker 1y ago

If you one day write a blog, I would want to subscribe. Your writing feels accessible. I find it makes complex topics approachable. Or at least, it gives me a feel of concepts that I would otherwise have no grasp on. Other online writing tends to be permeated by a thick lattice of ideology or hyper-technical arcanery that inhibits understanding.

pron 1y ago
Thank you! I did have one once (https://pron.github.io https://pron.github.io) but I don't know how accessible it is :) (two post series are book-length)
Ygg2 1y ago
> Your writing feels accessible. I find it makes complex topics approachable Yeah. By omitting a large swath of nuance. It reeks of "you can approximate cow with a sphere the size of Jupiter". It's baffling ludicrous. Any rhetorical device that equates Java/C# (any memory safe Turing language ) safety with C is most likely a fallacy.
- hudon 1y ago
  I interpreted his post as saying it's not binary safe/unsafe, but rather a spectrum, with Java safer than C because of particular features that have pros and cons, not because of a magic free safe/unsafe switch. He's advocating for more nuance, not less.
  - Ygg2 1y ago
    Yeah, it's not binary; it's just a step function. /s No, it's as close to binary as you can get. Is your only source of Undefined Behavior FFI specially marked functions and/or packages? Have you checked data races for violating thread safety invariants? If yes - You're safe. Allow a bit of unsafety into the system, like Go, and the unsafety can creep into your ecosystem. See https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html Is Go in mostly safer than C++? Maybe. But you can never prove that about either of them. So while you may pretend one is safer than the other, it's a bit like picking which boat is taking on more water. Can you prove Rust code is safe? Well there is the simple way - no unsafe. But what about unsafe blocks? Yes, you can prove it for them as well. If the unsafe code block is it will note safety invariants and why are they preserved by unsafe block. Can this be practically done? Depends on the crate, but with enough effort, yes.