8 ms·

Could someone explain to me why Zig is getting hyped so much on HN? From a quick glance it looks like Zig is memory-unsafe like C/C++. I thought the macro trend

• detaro 4y ago
  Not everyone thinks that macro trend is the most important thing ever and Zig is an interesting spin on a low-level language/a better C.
• nektro 4y ago
  it's perfectly possible to make memory safe programs in Zig. there are many an innovation that Zig brings to the table
  • AaronFriel 4y ago
    That isn't really an interesting statement, it's perfectly possible to make memory safe programs in C or assembly. The question is, how easy is it it to ensure a program is memory safe in Zig? The trend toward memory safety is marked by languages and tools making it harder to inadvertently write exploitable code, and easier to verify that the program is not exploitable. My understanding of Zig is that while it does some of the same things as so-called memory safe languages, it is not a "memory safe language" in the same sense as they use the term.
• adamgordonbell 4y ago
  This article here deserves attention because its interesting and counter-intuitive even if you don't use Zig. It's a story of problem solving.
• kristoff_it 4y ago
  > I thought the macro trend was moving onto memory-safe languages I guess some people like to Zig when others zag :^)
  • deleted 4y ago
    [deleted]
• bachmeier 4y ago
  Apologies, but I can't resist reposting a comment I made on a different story earlier today. (https://news.ycombinator.com/item?id=33910750 https://news.ycombinator.com/item?id=33910750) > > Your personal experiences make up maybe 0.00000001% of what’s happened in the world but maybe 80% of how you think the world works. > This explains every online discussion about programming that has comments invoking "toy problems" and "in production".
• flumpcakes 4y ago
  What do you mean by memory safe? This line is trotted out all the time but no one defines what they actually mean. Is Go memory safe? Rust is not a "memory safe" panacea. You can write memory unsafe code in Rust. Zig also has a much better developer experience around "memory safety" compared to C/C++. It really is an interesting alternative to writing something in C. You can compile it in debug mode and get out of bounds checks, for example.
  • KerrAvon 4y ago
    Rust is, in fact, a "memory safe" panacea if you're willing to put up with the syntax and complexity. Memory unsafe code in Rust is clearly marked as such, and you have to go out of your way to write it. Swift is similarly memory safe out of the box. By contrast, it seems to be trivial to write unsafe code in Zig. https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/ The window has closed for languages that don't take memory safety seriously. The Zig team can work on it now, or they can work on it later, but they will have to do it to get the language past a certain level of adoption in the modern world. People are starting to write real, useful Linux kernel modules in Rust.
    • BaculumMeumEst 4y ago
      > The Zig team can work on it now, or they can work on it later, but they will have to do it to get the language past a certain level of adoption in the modern world. The objective of every language does not have to be world domination.
  • pcwalton 4y ago
    UBSan has offered bounds checking support for C/C++ for a long time.
  • pjmlp 4y ago
    Zig doesn't offer much more than what Modula-2 was already doing in 1978, and memory debuggers exist for C and C++ for about 25 years now. One my first ones was Purify. https://en.wikipedia.org/wiki/PurifyPlus https://en.wikipedia.org/wiki/PurifyPlus
• stephc_int13 4y ago
  Aside from many sane and clever design choices, a key feature of Zig is that it's not Rust. Why does it matter? Because (some of) the Rust community is turning out to be toxic and repulsive. Zig is different player in the same space (C/C++ replacement) with a much less toxic community.
  • recuter 4y ago
    What makes the Rust community toxic and repulsive and what is to stop the Zig community from becoming such in the future?
    • stephc_int13 4y ago
      On almost any C/C++ or Zig related discussion happening on HN or Twitter you'll find some random Rust evangelist asking why people are still using a "memory unsafe" language to build things. Implying, basically, that any non-Rust system programming language is obsolete. (and should maybe even be considered harmful) I find that deeply annoying. I don't have predictions about the future; the Zig community is not toxic for now.
      • deleted 4y ago
        [deleted]
      • Ygg2 4y ago
        > why people are still using a "memory unsafe" That's a fair question imo. You're tossing the baby with bath water. Because that other person recommended Rust. Rather than Ada/C#. In 2022 any fault that can be used will be misused, so why use a language that might accidentally allow a CVE?
        • geocar 4y ago
          > That's a fair question imo. Are you willing to be convinced that you're wrong? Like completely, totally wrong about the value and goodness of "memory safety". Premise. Conclusion. Everything. If you're not, then no, it's not a fair question at all. It's just bait.
• civopsec 4y ago
  The compile-time features and the fact that you have to use allocators explicitly are interesting things. Other than that there’s nothing else there, for me. But it’s turned out to be more interesting than when I first saw the first blog post about intending to start on this language.
• WalterBright 4y ago
  D has steadily moved towards full memory safety. The one remaining thing is dealing with manual storage allocation, and D has a prototype borrow checker to address that.
  • modernerd 4y ago
    For others like me who didn't know D was adding a borrow checker, the first occurrence I can find of it in the changelog with detailed notes is here: https://dlang.org/changelog/2.092.0.html#ob https://dlang.org/changelog/2.092.0.html#ob
• modernerd 4y ago
  Language-level guarantees of memory safety are not critical to all low-level programmers, and sometimes this is fine! Developers of games, compilers, digital audio workstations, video editors, and live performance software (such as openFrameworks) likely don't rank memory safety as their top concern. Zig is already an attractive choice for those domains because it offers: - Great compile times compared to C++/Rust, and future plans to implement hot reloading as a core part of the tooling: https://www.jakubkonka.com/2022/03/16/hcs-zig.html https://www.jakubkonka.com/2022/03/16/hcs-zig.html - The ability to reason about where data exists in memory: https://ziglang.org/documentation/master/#Where-are-the-bytes https://ziglang.org/documentation/master/#Where-are-the-byte... - Good readability and learnability, especially if you have a C/C++ background. - Comptime that enables clean generics, compile-time reflection and general metaprogramming as a happy side-effect: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/ - Better tooling than C/C++. The ability to cross-compile Zig and C/C++ from one machine lets you set up much more stable and reproducible build environments already. You can clone zig-gamedev and have the demos working with just three commands on Windows/macOS/Linux, for example, and two of those three are cloning the repo and changing to the directory: https://github.com/michal-z/zig-gamedev https://github.com/michal-z/zig-gamedev (to build the examples you will need the latest copy of Zig from the 'master' section for your platform at https://ziglang.org/download/ https://ziglang.org/download/ ) We should all be careful about insinuating that memory unsafe languages should not exist. I see “friends don't let friends use memory-unsafe languages” on social media and feel sick. It's much healthier to embrace the melting pot of Zig, Odin, D, Beef, Vale, Hare, V, Lobster, Jai, C3, Val, Roc and all the rest and see what new ideas and trade-offs they bring. Also worth noting that new languages tend to take time to develop their own philosophies to memory safety (Vale's approach is only just now emerging, for example: https://verdagon.dev/blog/making-regions-part-1-human-factor https://verdagon.dev/blog/making-regions-part-1-human-factor ). Others take years to gradually improve and develop techniques for better memory safety (like D). Zig's story might not be as good as Rust's ( https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/ ), but then it's not Zig's priority at the moment, and Zig's full story is not yet written. Even if Zig's safety features don't improve further between now and 1.0, it already has great value as a language.
  • 4y ago
• brundolf 4y ago
  Rust is the only mainstream language I know of that's memory-safe without the overhead of GC or reference-counting. Doing that is really hard, and compromises the dev experience, so I'm not sure I'd call it "the macro trend", outside of the uptake of Rust itself. It has tradeoffs Zig and some other languages like Nim have taken a different approach: "If we don't try to fully solve memory safety, what are all the other ways we can improve on the status quo to make a decidedly modern systems language?" Modern tooling, colocating arrays with lengths, strings as first-class citizens, error types, nullable types that the compiler can reason about, better static types and inference in general, etc. There's a whole lot of room for improvement over C even if you're not going all the way to borrow-checking More on Zig's level of safety: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
  • Arnavion 4y ago
    Also, much of what Zig improved over prior art and much of what Rust improved are orthogonal and can coexist. The ideal language for me would be one that takes the syntax unification, the arbitrary-width integer types, the meta-programming, and the explicit allocators from Zig, and the traits, borrow checker, scope-based destructors, and move-by-default from Rust.
  • pjmlp 4y ago
    Ada also fits the bill, but it isn't cool.
• abnercoimbre 4y ago
  We published a podcast at Handmade Seattle called Memory Strategies - The Merits of (Un)safe with respected guests across the safety spectrum. Take a listen! The safety story is not as black-and-white as you'd wish it were. [Video] https://guide.handmade-seattle.com/c/2022/memory-strategies-merits-unsafe/ https://guide.handmade-seattle.com/c/2022/memory-strategies-... [Audio-Only] https://handmade.network/podcast/ep/afc72ed0-f05f-4bee-a658-9ad02c0453da https://handmade.network/podcast/ep/afc72ed0-f05f-4bee-a658-...
• LAC-Tech 4y ago
  Zig is still a lot more memory safe than C or C++. While being a much smaller and elegant language. The stuff with alignment being part of the type system is brilliant (and pretty damn safe).
• littlestymaar 4y ago
  Unfortunately for Zig, most of the hype (I'd say around 70 to 80%) it gets from HN comes from the “anti-Rust” crowd: C programmers and people in general who have been put off by Rust (either by the “safety” discourse around Rust, or by its functional programming background, or both most of the time). Some people are so concerned about Rust that they need a language champion their resistance against it [1]. After Rust hit 1.0, Nim had a surge of popularity on HN for this exact reason, That's very unfortunate for Zig as a language. Because it distracts from the main points of the languages (which is IMHO a very cool/powerful C toolchain + an interesting experiment about “what if we got all-in to constant-time evaluation“), and because it artificially inflates the “community” with people who don't genuinely care about it, and will leave whenever another anti-Rust champion eventually becomes in a better position (it could be Carbon, or Jai, or anything). Personally, I don't think Zig has much chance becoming mainstream or overthrow Rust as “the future of system programming”, because it (IMHO) doesn't adds enough business value[2], but for a programming language perspective it is indeed very interesting. Maybe if it could take just enough Rust concepts to make it as memory-safe, then maybe, but it would also mean being more “compromise to achieve mass adoption” and less idealistic about its design, which would likely make it less interesting on a PL perspective. [1]: there's for instance a quite famous Java guy here who've been spending a significant time on HN explaining “why we cannot be sure that Rust doesn't ads more bugs than it removes” and other bullshit. And when Zig came out, he suddenly became a huge fan of it… [2]: C++ took the lion share against C because it solved the organizational problem of how you deal with big code-bases worked on by big teams. And now, for the “systems” world, Rust is slowly but steadily creeping in, because the stability+security it provide were unheard of in non-managed languages until.
  • TUSF 4y ago
    > because it (IMHO) doesn't adds enough business value I dunno about this. We're seeing Zig being used as the compiler toolchain in per-existing C and C++ codebases here and there, and is used by at least one big tech companies for this very reason[0] and once you're already using the build toolchain, there's less barrier to then using the language to extend your code. As far as I can tell, long-term, that's probably how Zig is going to work its way into the space, being the all-in-one toolchain for managing existing code, and then having a programming language that's as low-level as C, but without the complexity of C++/Rust, that just happens to come with said toolchain. From some of Andrew's comments, it also seems that the planned package manager will also be meant for C & C++ projects. These aren't all features that don't already exist in other tools individually, but as far as I know (which admittedly isn't a lot) there aren't any that bring it all in a single convenient package with sane defaults that works out of the box. [0]: https://jakstys.lt/2022/how-uber-uses-zig/ https://jakstys.lt/2022/how-uber-uses-zig/