← Back to context

Comment by nyrikki

6 days 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/

16 comments

nyrikki

Reply
IshKebab  6 days ago

Fwiw 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_  6 days ago

    [flagged]

    • IshKebab  6 days ago

      It'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.

    • dralley  6 days ago

      Not 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  6 days ago

    Show code

    • program_whiz  5 days ago

      I think he meant "show me a true linked list / node graph in rust that isn't unsafe". The reason being its not possible using c-style pointer following (or without just putting everything auto-pointers). What you've shown is exactly the tradeoff they were referring to. In rust, the answer is: make sure lifetime of all memory is explicitly managed, then use integers for the 'links' between nodes.

      His point was that for his programming, he wants to be able to make real pointers and real linked lists with memory unsafe, which Rust makes difficult or opaque. For example with linked list, you could simulate (to avoid unsafe), by either boxing everything (so all refs are actually smart pointers), or you can use a container with scoped memory lifetime, and have integers in an array that are the "next" pointer. In addition to extra complexity, the "integers as edges" doesn't actually solve the complexity, it just means you can't get a bad memory error (you can still have 'pointers' that point to the wrong index if you're rolling your own).

      Same with your graph code. Using a COO representation for a graph does in theory make it "memory safe" (albeit more clumsy to use if you are doing pointer-following logic), and it also introduces other subtle bugs if your logic is wrong (e.g. you have edge 100 but actually those nodes were removed, so now you're pointing at the wrong node).

      I think the point (which I agree with for things like linked list, graph, compiler) is that depending on your usecase, the "safety" guarantees of rust are just making it harder to write the simplest most understandable code. Now instead of: `Node* next` I have lifetimes, integer references, two collections (nodes and edges) to keep in sync, smart pointers, etc. Previously my complexity was to make sure `next != null`, now its a ton of boilerplate and abstractions, performance hits, or more subtle bugs (like 'next' indices getting out of sync with the array of 'nodes').

      If there was a way to explicitly track the lifetime of an arbitrary graph/tree of pointers at compile time, we wouldn't need garbage collection -- its not solvable at compile time, and the complexity has to live somewhere.

      1 reply →