6 ms·

Zig isn’t memory safe though right?

pixelpoet 1y ago
It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.
- vlovich123 1y ago
  > Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) With significant performance and memory overhead. That just isn't the same ballpark that Rust is playing in although hugely important if you want to bring forward performance insensitive C code into a more secure execution environment.
  - mike_hearn 1y ago
    Fil-C has advanced a lot since I last looked at it: > Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. with room for optimization still. Compatibility has improved massively too, due to big changes to how it works. The early versions were kind of toys, but if Filip's claims about the current version hold up then this is starting to look like a very useful bit of kit. And he has the kind of background that means we should take this seriously. There's a LOT of use cases for taking stuff written in C and eliminating memory safety issues for only a 50% slowdown.
- jorvi 1y ago
  > especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. Your first claim is unverifiable and the second one is just so, so wrong. Even big projects with very talented, well-paid C or C++ devs eventually end up with CVEs, ~80% of them memory-related. Humans are just not capable of 0% error rate in their code. If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you.
  - dgb23 1y ago
    > If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you. Zig does a lot of things to prevent or detect memory safety related bugs. I personally haven't encountered a single one so far, while learning the language. > ~80% of them memory-related. I assume you're referencing the 70% that MS has published? I think they categorized null pointer exceptions as memory safety bugs as well among other things. Zig is strict about those, has error unions, and is strict and explicit around casting. It can also detect memory leaks and use after free among other things. It's a language that's very explicit about a lot of things, such as control flow, allocation strategies etc. And there's comptime, which is a very potent tool to guarantee all sorts of things that go well beyond memory safety. I almost want to say that your comment presents a false dichotomy in terms of the safety concern, but I'm not an expert in either Rust or Zig. I think however it's a bit broad and unfair.
ummonk 1y ago
Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe.
- Ar-Curunir 1y ago
  What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
  - ummonk 1y ago
    Safe Rust is demonstrably not memory-safe: https://github.com/Speykious/cve-rs/tree/main https://github.com/Speykious/cve-rs/tree/main
    - steveklabnik 1y ago
      This is a compiler bug. This has no bearing on the language itself. Bugs happen, and they will be fixed, even this one.
      - ummonk 1y ago
        It's a 10 year old bug which will eventually be fixed but may require changes to how Rust handles type variance. Until you guys write an actual formal specification, the compiler is the language.
        steveklabnik 1y ago
        It’s a ten year old bug because it has never been found in the wild, ever, in those ten years. Low impact, high implementation effort bugs take less priority than bugs that affect real users. The project is adopting Ferrocene for the spec.
        ummonk 1y ago
kristoff_it 1y ago
How confident are you that memory safety (or lack thereof) is a significant variable in how fast a compiler is?

It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.

vlovich123 1y ago
> Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) With significant performance and memory overhead. That just isn't the same ballpark that Rust is playing in although hugely important if you want to bring forward performance insensitive C code into a more secure execution environment.
- mike_hearn 1y ago
  Fil-C has advanced a lot since I last looked at it: > Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. with room for optimization still. Compatibility has improved massively too, due to big changes to how it works. The early versions were kind of toys, but if Filip's claims about the current version hold up then this is starting to look like a very useful bit of kit. And he has the kind of background that means we should take this seriously. There's a LOT of use cases for taking stuff written in C and eliminating memory safety issues for only a 50% slowdown.
jorvi 1y ago
> especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. Your first claim is unverifiable and the second one is just so, so wrong. Even big projects with very talented, well-paid C or C++ devs eventually end up with CVEs, ~80% of them memory-related. Humans are just not capable of 0% error rate in their code. If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you.
- dgb23 1y ago
  > If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you. Zig does a lot of things to prevent or detect memory safety related bugs. I personally haven't encountered a single one so far, while learning the language. > ~80% of them memory-related. I assume you're referencing the 70% that MS has published? I think they categorized null pointer exceptions as memory safety bugs as well among other things. Zig is strict about those, has error unions, and is strict and explicit around casting. It can also detect memory leaks and use after free among other things. It's a language that's very explicit about a lot of things, such as control flow, allocation strategies etc. And there's comptime, which is a very potent tool to guarantee all sorts of things that go well beyond memory safety. I almost want to say that your comment presents a false dichotomy in terms of the safety concern, but I'm not an expert in either Rust or Zig. I think however it's a bit broad and unfair.

ummonk 1y ago

Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe.

Ar-Curunir 1y ago
What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
- ummonk 1y ago
  Safe Rust is demonstrably not memory-safe: https://github.com/Speykious/cve-rs/tree/main https://github.com/Speykious/cve-rs/tree/main
  - steveklabnik 1y ago
    This is a compiler bug. This has no bearing on the language itself. Bugs happen, and they will be fixed, even this one.
    - ummonk 1y ago
      It's a 10 year old bug which will eventually be fixed but may require changes to how Rust handles type variance. Until you guys write an actual formal specification, the compiler is the language.
      - steveklabnik 1y ago
        It’s a ten year old bug because it has never been found in the wild, ever, in those ten years. Low impact, high implementation effort bugs take less priority than bugs that affect real users. The project is adopting Ferrocene for the spec.
        ummonk 1y ago

kristoff_it 1y ago

How confident are you that memory safety (or lack thereof) is a significant variable in how fast a compiler is?