3 ms·

Not even memory safe. It has many "unsafe" and "transmut", and this is without the bazillion external dependencies it also depends on.

frankjr 3y ago
I mean they currently have 12 unsafes and 4 transmutes (who knows how many in dependencies). I wouldn't say it's many when the code base is clocking at around 53k of Rust. Compared to languages such as C/C++/Zig, which provide no safety at all, it's still an improvement to at least know where to look when address sanitizer is screaming at you (see the bug I linked to in the sibling comment).
- exxos 3y ago
  [dead]
- wredue 3y ago
  Both zig and modern C++ have safety that is generally good and catches swathes of issues. I’ve been writing zig for a couple months now and have only once accidentally leaked in a test, and haven’t once accidentally messed up a buffer. Not saying you can’t, because zig definitely has escape hatches, but idiomatic zig has proven quite easy to stay safe without even thinking about it. No. Neither is as pedantic as rust, but zig has been a joy to work in compared to either C++ or Rust in my opinion.
  - frankjr 3y ago
    I agree that there's a lot to like about Zig (the module system and error management are the two I mainly consider superior to Rust's approach for example) but I wouldn't say it's easy to stay safe without thinking about it. Quite the contrary actually. Rust sometimes forces you to add annotations which certainly can get unwieldy at times (I think this in particular trips a lot people because sometimes they know what they want to tell the compiler but don't know how to express it in Rust speak and thus anger ensues). Zig, on the other hand, doesn't require any of that and makes code look simple and arguably more pleasant in comparison, but it doesn't mean the "contract" between objects goes away. It's just not expressed in code and checked by the compiler but rather by the person writing the code. Take [0] for example. The compiler (at least in the current stage, it's at 0.11 after all) is perfectly happy with code which returns a pointer to a stack allocated memory from a function. The fix is to remember that you need to pass the argument via pointer and not let the compiler decide for you. But what if the programmer forgets or somebody else is working on the code? [0] https://github.com/ziglang/zig/pull/17419 https://github.com/ziglang/zig/pull/17419

frankjr 3y ago

I mean they currently have 12 unsafes and 4 transmutes (who knows how many in dependencies). I wouldn't say it's many when the code base is clocking at around 53k of Rust. Compared to languages such as C/C++/Zig, which provide no safety at all, it's still an improvement to at least know where to look when address sanitizer is screaming at you (see the bug I linked to in the sibling comment).

exxos 3y ago
[dead]
wredue 3y ago
Both zig and modern C++ have safety that is generally good and catches swathes of issues. I’ve been writing zig for a couple months now and have only once accidentally leaked in a test, and haven’t once accidentally messed up a buffer. Not saying you can’t, because zig definitely has escape hatches, but idiomatic zig has proven quite easy to stay safe without even thinking about it. No. Neither is as pedantic as rust, but zig has been a joy to work in compared to either C++ or Rust in my opinion.
- frankjr 3y ago
  I agree that there's a lot to like about Zig (the module system and error management are the two I mainly consider superior to Rust's approach for example) but I wouldn't say it's easy to stay safe without thinking about it. Quite the contrary actually. Rust sometimes forces you to add annotations which certainly can get unwieldy at times (I think this in particular trips a lot people because sometimes they know what they want to tell the compiler but don't know how to express it in Rust speak and thus anger ensues). Zig, on the other hand, doesn't require any of that and makes code look simple and arguably more pleasant in comparison, but it doesn't mean the "contract" between objects goes away. It's just not expressed in code and checked by the compiler but rather by the person writing the code. Take [0] for example. The compiler (at least in the current stage, it's at 0.11 after all) is perfectly happy with code which returns a pointer to a stack allocated memory from a function. The fix is to remember that you need to pass the argument via pointer and not let the compiler decide for you. But what if the programmer forgets or somebody else is working on the code? [0] https://github.com/ziglang/zig/pull/17419 https://github.com/ziglang/zig/pull/17419