6 ms·
I still have yet to understand if Zig actually provides memory safety in the same manner Rust does or not, it seems like its another C like language without mem
by bfrog 3y ago
I still have yet to understand if Zig actually provides memory safety in the same manner Rust does or not, it seems like its another C like language without memory safety? Or did I happen to miss that bit?
- xigoi 3y ago> I still have yet to understand if Zig actually provides memory safety in the same manner Rust does or not It doesn't.
- bfrog 3y agoSo its C with nicer macros and maybe some more sensible ways of dealing with arrays and such? For me that's not enough to move the needle.
- cmrdporcupine 3y agoIt's more than that in that it has a sane syntax and module and build system. I'm a Rust person by both day job and hobby, but I can see the niche Zig is in as being quite useful in particular for embedded work. One thing it definitely has over Rust is way better support for explicit per-structure allocator/allocation management. The allocator_api stuff in Rust has just been sitting unstable for years at this point, while Zig shipped with support for this immediately. Which is key for work in all sorts of systems level contexts. Probably the language I want is somewhere between the two.
- deleted 3y ago[deleted]
- bfrog 3y agoI mean I really have a hard time going backwards on the whole idea of lifetimes and send/sync type traits which force escape hatches if you want to do something idiotic. The key piece here is, any project of significant size and usage, someone will try to do something stupid. Rust makes the stupid so obvious with unsafe blocks and annotations, that reviewing code from some random person on the internet is made easier. The tooling made the task of reviewing code mostly limited to the code being changed rather than the whole project. In C/C++ land you need to consider not only the code being changed but also the entire code base and how that code is used. It's not enough to look at the diff. You need to understand the context. Not to say that isn't also true with Rust to some degree, but the degree is usually in terms of logic and less "is some pointer/reference going to cause a race/segfault/buffer xflow?" The langauge itself doesn't define allocation, Box is in the stdlib and this allows for nostd libraries to deal with things as I guess most of us might expect I'd think. It would be cool to allow for a global allocator though to enable std on more platforms with better semantics, no disagreement there.
- emmanueloga_ 3y agoIt doesn't, but it puts a RED BANNER in every place where memory is allocated, and you need to explicitly pass an allocator of your choosing whenever memory is allocated. It also contains no hidden allocations or function calls. So it forces you to think about your memory allocation patterns, and also includes some tools to catch memory leaks [1]. 1: https://ziglang.org/learn/samples/#memory-leak-detection https://ziglang.org/learn/samples/#memory-leak-detection
- saagarjha 3y agoThat doesn't really help.
- emmanueloga_ 3y agoJust as your comment :-p
- saagarjha 3y agoIf you didn't find "thinking about memory allocations doesn't help much with memory safety" useful I don't really have much more to share.
- maxmcd 3y agoI found this article to be clarifying: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
- bfrog 3y agoIn effect this answers my question pretty well, the answer seems to be a resounding "No there's no memory safety" at least in the practical or realistic sense that results in few to no memory lifetime errors.
- dgb23 3y agoZig provides tools to avoid memory related bugs, but it doesn't enforce it via compile time checked RAII/burrow checking etc. Nullability (and error handling) is compile time checked though.
- bfrog 3y agoTo me the biggest win in Rust is just that, the memory related bugs are nearly non-existent. Throw in a group of people working on something and this makes the project move just so much faster in both review time and time hunting bugs.
- cmrdporcupine 3y agoIMHO the real big win w/ Rust is not so just memory safety from (some) leaks or segfaults but the fact that the borrow checker rules apply also to concurrency related scenarios and so race conditions and deadlocks become much more difficult to accidentally produce. Developers can generally be taught to handle memory ownership issues fairly well, esp when helped out with RAII smart pointers, etc. But in my experience when you throw concurrency in, even very high quality engineers tend to stumble and accidentally introduce race conditions. In this respect Rust has something over the garbage collected languages, too. Because Java, Go, JS, C#, etc will effectively shield you from "use after free" but they will absolutely not stop you from passing an unlocked, etc. reference to another thread and screwing yourself up royally; and Rust will.
- throwawaymaths 3y agoZig gives buffer overflow safety and null pointer safety but not use after free, double free, or stack pointer escape safety. Zig also gives you memory exhaustion safety which rust does not.
- oconnor663 3y agoIs there a memory exhaustion scenario where Rust does something other than panic?
- kibwen 3y agoRust-the-language doesn't do any dynamic allocation, so it doesn't exhaust memory at all. The Rust stdlib currently guarantees an abort on OOM, but in the future this will be changed to a panic (which you can always configure to be an abort if you want). Both of these behaviors are memory-safe (it's unclear what "memory exhaustion safety" is referring to).
- throwawaymaths 3y agoAlso to clarify: there are platforms (like linux) which de facto have nonfailable allocation, if you run out of memory the system will oom kill your process, and neither zig nor rust will save you from that. I believe In practice the most common place where failable OOM is a big deal is in embedded systems programming
- 10000truths 3y agoNo language can save you from OOMs, but because Zig pervasively uses explicit memory allocation, it makes it easy to greatly mitigate OOM risks by front-loading all the fallibility: 1. Calculate and allocate all your required memory immediately upon process startup (including memory from OS resources like sockets) 2. Call mlockall to prevent the pages from being swapped out 3. Write "-1000" to /proc/self/oom_score_adj to avoid the OOM killer 4. Use your preallocated memory as a pool for all further allocations With the above approach, the application has full control over how to handle application-level OOMs (e.g. applying backpressure to connecting clients, or shrinking non-critical caches) once it is past the start-up stage.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]