‹ BackHN Continuity

Thread

What Zig felt like, coming from Rust

282 points · 351 comments · ksec

  1. plqbfbv · · 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. hinkley · · focus · HN ↗
      Rust could not work in a world where compilation was a single threaded affair. I think it exists now instead of in the 90’s and 00’s in good part because of this.

      I don’t think it’s an accident that it has succeeded as multicore took over. We are now well past a point that a task that can be split with 70% efficiency into multiple parallel tasks is 5-10x faster than the optimal sequential solution. Expensive multicore machines existed when Rust was a baby but it didn’t really catch on until 4 core was common in consumer hardware. And now I have an ancient laptop with 16 cores.

      But Rust is also good for producing correct code to run on those systems. So it benefits twice.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.