Thread

1. plqbfbv · 1789832911 · focus · HN ↗

   Maybe I'm not that deep into programming, but I don't understand the hype about Zig?

   I programmed in rust a bit and can't say I'm an expert, but in my view rust mostly-solved the memory management problem at compile time and without a GC, and it works very well. The biggest con and cost I've always seen repeated so far is that "it's slow to compile", and I get that, if you're past 250 crates the final --release link tends to become noticeable, but there were improvements to incremental compilation.

   On the other hand - looking at the syntax from this post - Zig feels a blend of javascript, python and golang syntax that still requires memory management. So a nicer-written C that inherits all the issues from C? From the post: no functional programming, data mutation, memory leak, double-free, memory corruption.

   Personally I'd rather trade a couple minutes of final link every time when this is the other option.

   1. logicchains · 1789838424 · focus · HN ↗

      If you're writing ultra low latency code you basically want everything allocated from an arena, with different arenas for different kinds of objects. Zig comes with this built in, while Rust makes it extremely unergonomic to do safely (due to the lifetime system).

      1. kibwen · 1789841714 · focus · HN ↗

         Arenas in Rust work very well with lifetimes. In fact arenas benefit greatly from lifetimes, because lifetimes allow them to uphold the usual Rust safety guarantees about preventing use-after-free. For example, here's the bumpalo crate in action:

             let mut arena = Bump::new(); // create arena
             
             let foo = arena.alloc(Foo { x: 42 }); // allocate item in arena
             
             bump.reset(); // clear arena
             
             foo.x += 1; // compiler error preventing use-after-free

Unofficial Hacker News client; not affiliated with Y Combinator.