3 ms·
Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers. I am
by nyrikki 5mo ago
Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers.
I am of the opinion that it is horses for courses and not a universal better proposition.
Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc…
While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case.
1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior.
2) defer[0] allows you to collocate the the freeing of resources with code.
That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case.
I was working on some eBPF code in C and did really miss zig.
For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth.
[0] https://zig.guide/language-basics/defer/ https://zig.guide/language-basics/defer/
- IshKebab 5mo agoFwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time. I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.
- fao_ 5mo ago[flagged]
- IshKebab 5mo agoIt's not as simple as that. All software is abstraction and with any software if you go deep enough you'll find unsafe code. E.g. look at a Python list. Is it safe? In Python sure, but that's abstracting a C implementation which definitely isn't safe. If you look at Rust's std::Vec you'll find a very similar story - safe interface over an unsafe implementation. It isn't as binary as you think.
- paulddraper 5mo agoIf you don’t see any difference between those two, I’m really not sure what to say.
- dralley 5mo agoNot really though. That's like saying that no language is "safe" because the compiler could have a bug. It's true that safe wrappers around unsafe code sometimes have bugs in them, but it's orders of magnitude easier to get the abstraction right once than to use unsafe correctly in many places sprawled across a large codebase.
- awesome_dude 5mo agoShow code
- IshKebab 5mo agoErr https://github.com/petgraph/petgraph https://github.com/petgraph/petgraph What are you asking for exactly?
- awesome_dude 5mo agoI don't think it's unreasonable, even though I am getting marked down for daring to ask, for people who are making assertions, even if they are well understood *within their own community* (that is, not necessarily universally known) to show examples of what they are talking about. You're correcting someone, so it's clear that your understanding isn't universal, and example code is the absolute minimum.
- rascul 5mo agoIt doesn't seem clear what code you're asking for.
- deleted 5mo ago[deleted]
- deleted 5mo ago[deleted]
- zipy124 5mo agoForgive me if I've mis-understood this thread, but there are unsafe declerations in that crate. Is there really any difference between using unsafe in your own code, versus wrapping it inside some crate? I guess you are making the point that the user does not have to concern themselves with the unsafe declarations?
- simonkagedal 5mo agoI would say yes, there’s a difference, in general. I would much rather leave the unsafe code to crates used and tested by many other applications, than have them in the application code itself.