5 ms·

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 rus

• slopinthebag 7d ago
  yeah to me zig exists as a counter-reaction to rust. which means avoiding both the good and bad things rust does. and rust does a lot of things right, so...
  • IncreasePosts 7d ago
    Rust is for devs who think "if only c++ had a few more features, it would be perfect". Zig is for devs who think "if only C had fewer features, it would be perfect"
    • slopinthebag 7d ago
      ironically rust has fewer features than c++ and zig has more than c
      • IncreasePosts 7d ago
        Give it a chance! Rust hasn't even had its bar mitzvah yet and C++ is already buying a Porsche during its midlife crisis. Yes, on paper zig has more features than C, but what zig has is explicitness. C has a big murky space of implicitness. For example, there might be 5 different zig features which can be used at various times you might use a void* in C, buy the conceptual space of void* fully contains(and then some) the spaces of those zig features.
        • deleted 6d ago
          [deleted]
      • a96 5d ago
        Everything has less features than c++. There's probably no spec that's more bloated with all the (unimplemented) junk that has been piled onto it.
• pjmlp 7d ago
  Basically you pick the type safety that Modula-2 or Mesa already offered in the late 1970's, repackage it with comptime and more C like syntax, and have a whole legion of new devs jumping into it. Note that AT&T, where UNIX and C were born, the language they were researching as C replacement was Cyclone, not something that is not much different.
  • mi_lk 6d ago
    It’s not a Zig post if pjmlp doesn’t claim the language is Modula-2 rip-off. Seriously impressive that you’re going to repeat that until the end of time
    • pjmlp 6d ago
      Not everyone reads the same posts, and post 2000 younger generations need to be educated in what came first, what is actually new, and what is language adoption marketing. Because it is a rip off, pretending nothing else has done it before, in fact it could even be called a PL/I ripoff for that matter, which predated C for about a decade, had already had all the bounds checking, proper strings and arrays, was actually used to deliver several IBM OSes, and is used to this day on z/OS. Certainly much larger production deployments than Zig. Yes I will, as long as I am part of this realm, can be in HN, or whatever is the social media of the day, I started with BBS, USENET, Slashdot and plenty others.
• bunderbunder 7d ago
  Zig is aiming to be lower level than Rust. As the project homepage prominently advertises, it has no hidden memory allocation or control flow. It also gives more control over how memory is allocated, which is potentially useful in applications with particularly tight performance requirements. Kelley first created Zig when hr was working on a digital audio workstation and found most existing languages to be awkward for working with particularly hard real time requirements, but still wanted something more modern than C. Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it. Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing.
  • packetlost 7d ago
    > it has no hidden memory allocation or control flow Rust had like 3 allocating types total. If you aren't working with extremely deeply nested 3rd party types it's trivial to identify when allocations happen. Hell you could throw a lint rule together in like 5 minutes to warn on it if you're really worried. Besides Drop (excluding async) is there even any hidden control flow? > Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it. Rust has almost exactly the same semantics for controlling allocations and deallocations, it just prevents you from screwing it up and not freeing something or using the allocation after freeing it. You still have to pass around your reference in your call stack until you no longer need it. > Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing. It's really not substantially different. You allocate ahead of time or don't allocate at all. The only real difference is you might want to use an Option instead of an uninitialized pointer because it's semantically more correct and harder to screw up.
    • 7d ago
• deleted 7d ago
  [deleted]
• hinkley 7d ago
  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.
• kllrnohj 7d ago
  Zig is exciting to people that still actually like C. Is that a rationale choice? Not very often. Is it a wrong choice? Also again not very often. At least, not for anything in scope of a solo dev. The industry where it seems strongest positioned is embedded. Will it actually break into that domain? No idea.
  • epolanski 6d ago
    People that like C, won't move from C and don't have many reasons to do so. It's the lingua franca of software development. Zig is appealing to the "I'd like to work in a C-like system programming language but I'm not a C veteran" crowd. Not a small crowd by any means, but will always be a niche.
    • a96 5d ago
      As a C veteran, Zig is interesting to me because of the compiler that still happily eats C. It has potential as a (cross!) development tool that can do a bit more than C tools alone. Which also describes Rust to some extent, but I think Rust would be more a full replacement. Which in turn is exciting because there hasn't been anything before that might replace C in my (embedded or -ish) environment. I haven't actually tried to find out if that Zig promise is real, though. Just some trivial little things. No day job excuse and no personal projects where it would fit.
• pron 7d ago
  > I don't understand the hype about Zig? As a long-time low-level programmer, and as someone working on a popular mainstream language, I find Zig fascinating, and I also think it addresses a long-standing problem in low-level programming. I'll get to the problem later, but the fascinating part is its use of partial evaluation (comptime) as a single coherent mechanism that replaces a myriad of other partial-evaluation mechanisms (macros, templates/generics, constexprs). That one mechanism is the core of the language, like macros are in lisps, and that design - whether you like it or not - is revolutionary. It's never been done before (other languages have partial evaluation mechanisms that are almost as general, but they're offered in addition to, not as a replacement of, other features). > rust mostly-solved the memory management problem at compile time and without a GC "Mostly" does a lot of work here because 1., if you look at the implementation of very efficient, possibly specialised data structures - the very thing you reach for a low-level language for - they typically require unsafe, and 2., it still suffers from the problem C++ has had for decades, which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower (huge runtimes like TCMalloc help, but not enough, because they can't move pointers). This problem, of programs that start out fast, but after five or ten years of evolution need to spend a lot of effort to remain fast, is one of the things moving collectors were designed to solve, but they require moving pointers, which doesn't work in low-level languages that are not meant to have an FFI layer between them and the hardware. To compete with the performance of moving GCs, which allocate through bumping a pointer, like on the stack, and free memory in bulk, low-level languages need to rely on arenas (which work based on a similar principle), and Zig is the first language that makes arenas almost user-friendly and hopefully sufficiently composable to withstand program evolution. Of course, time will tell how well this works in practice.
  • treyd 7d ago
    > the very thing you reach for a low-level language for - they typically require unsafe There's a formal proof asserting that if you keep up the safety invariants within an unsafe region then that will not infect other code, even in the presence of arbitrary other correctly-written unsafe blocks. This means you can build abstractions on top of these low-level primitives to keep it contained, so consumer code never has to even think about or know there's unsafe blocks in it. The type system lets you build very powerful abstractions so these go a long way. There's a lot of woo-woo scare quoting around how much you actually have to use unsafe code in Rust. It's fairly uncommon to actually have to reach for them in practice. Most of my usage ends up being things like converting a &[u8] to a &str when I know it's already valid UTF-8 so I want to skip the linear-time validity check. Very rarely do I have to build data structures with complicated pointer juggling, because there's often a library that already does what I need! > which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower What are you talking about? I've never encountered this and I've been using Rust for 10 years.
• logicchains 7d ago
  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).
  • kibwen 7d ago
    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
• qudat 7d ago
  As someone who primarily writes in TS, Go, Python, I agree with your assessment: it looks like those languages. The reason I like Go is the reason I like Zig: the language is relatively simple and feels like C. The C interop is a huge win as someone who wants to do more posix/wayland projects.
• applfanboysbgon 7d ago
  > So a nicer-written C that inherits all the issues from C? And inherits all of the benefits of C. C is the foundation of the computing world. "C, but not built 50 years ago" is, by itself, a tremendous value add to a programming ecosystem that has largely abandoned attempts to write a truly performant language in favor of handicapping programmers with fully automated safety. Rust is a low-level language for people who don't write low-level code. Zig is for those who do.
• deleted 7d ago
  [deleted]
• deleted 7d ago
  [deleted]
• lukaslalinsky 6d ago
  The main advantage of Zig for me and many other programmers, is the simple mental model you need to keep while reading the code. All control flow is expressed by keywords, never symbols. That along makes code much more readable. There is nothing like Rust macros, things can't do "magic. Zig comptime are regular functions, so you can clearly see and follow the trail. There are no exceptions, no recoverable panics, all code will run linearly as you see it written. Error handling in Zig is close to perfect, in my view. Obviously, Zig is not a language to use for high-level jobs. It makes no sense to write CRUD web app in Zig, you will be fighting the resource management for no good reason. For me personally, I feel that I'm too stupid to use Rust effectively. I started moving away from C++ purely because I don't want to deal with exceptions. And Rust is just a more complex C++ with memory safety.
• tomjen3 6d ago
  One of the things I liked about Zig is that it made choosing which memory strategy (malloc, stack allocated, Arena, Bounded allocation, combo) you needed for a particular code second straightforwarded and well supported. Microbenchmarks are cool, but better algorithms are where you get faster code.
• landdate 6d ago
  C++ solved the memory issue at compile time too. I don't understand why even use Rust when modern C++ can do everything you can do in Rust but better and more ergonomic. New languages to solve old problems.
• epolanski 6d ago
  > So a nicer-written C that inherits all the issues from C? It's actually a nicer-C that fixes most of the issues from C. That's the point. Rust is philosophically different and goes well beyond the "just be a better C".