8 ms·

Systems Programming with Zig

166 points by signa11 1y ago

gabrielgio 1y ago
As a developer interested in zig it is nice to see books being release, but I'd be a bit resitant to buy anything before zig reaches 1.0 or at least when they settle on a stable api. Both the builder and the std keep changing. Just 0.15 is a huge breakage. Does anyone knows how those changes would affect this book?
- turtleyacht 1y ago
  Author links to 0.15.1 Zig docs in several places, at least for now. Outstanding issue on Zig side for 1.0 release: https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
- zwnow 1y ago
  With how its going I feel Zig 1.0 wont be a thing until my retirement in 37 years
  - testdelacc1 1y ago
    I’m willing to bet $5 it happens in 4 years or fewer.
    - ebri 1y ago
      That’s a pretty low confidence if we measure confidence in dollars willing to risk
      - testdelacc1 1y ago
        It’s 100% of my annual betting budget though!
    - tialaramex 1y ago
      Do you have a history we can look at to see how good you are at predicting this for programming languages? Like say, some 2020 predictions you had for languages which would or would not ship 1.0 by 2025 ?
      - testdelacc1 1y ago
        I made a set of predictions for Rust in 2022, nearly all of which turned out to be correct. And I was publicly confident Go and Rust would be massive when they reached 1.0. I was right on both counts. But I will also admit I don’t follow developments in zig as closely as Rust. I’ve never written any Zig. And in any case, past performance isn’t indicative of future performance. I could be wrong about this prediction, but I don’t think I will be. From what I’ve seen Andy Kelley is a perfectionist who could work on point releases forever. But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. They’ll nudge him towards 1.0. They can wait a few years, but not forever. That’s why I guessed 4 years.
        jorangreef 1y ago
        > But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. TB is only 5 years old but already migrating some of the largest brokerages, exchanges and wealth managements in their respective jurisdictions. Zig’s quality for us here holds up under some pretty extreme fuzzing (a fleet of 1000 dedicated CPU cores), Deterministic Simulation Testing and Jepsen auditing (TB did 4x the typical audit engagement duration), and is orthogonal to 1.0 backwards compatibility. Zig version upgrades for our team are no big deal, compared to the difficulty of the consensus and local storage engine challenges we work on, and we vendor most of our std lib usage in stdx. > They’ll nudge him towards 1.0. On the contrary, we want Andrew to take his time and get it right on the big decisions, because the half life of these projects can be decades. We’re in no rush. For example, TigerBeetle is designed to power the next 30 years of transaction processing and Zig’s trajectory here is what’s important. That said, Zig and Zig’s toolchain today, is already better, at least for our purposes, than anything else we considered using.
    - noshitsherlock 1y ago
      Wouldn’t you think AI advances in 4 years would make this a safe bet?
      - therein 1y ago
        No, unless you're riding the hype train so hard that you are excited to go to colonize Mars thanks to AI advances.
  - bnolsen 1y ago
    The language itself won't change much. The standard library is what is still in flux.
- Rochus 1y ago
  Is this really the first Zig book since the development startet in 2016? Maybe the language and library is just too volatile for a book.
  - wslh 1y ago
    Or it evolves smoothly at another pace.
- osigurdson 1y ago
  People are doing real companies with Zig (e.g. Tiger Beetle) and important projects (e.g. Ghostty) without the 1.0 backward compatibility guarantee. Zig must be doing something right. Maybe this also keeps opinionated 9-5er, enterprise type devs out of it as well which might be a good thing :).
  - Rochus 1y ago
    Are there other notable commercial companies/projects than Tiger Beetle relying on Zig? According to public information, Tiger Beetle are about eight employees with a single customer, isn't it?
    - jakogut 1y ago
      Bun.sh uses zig for large portions of native code.
      - Rochus 1y ago
        Thanks for the hint. According to public sources, Bun's runtime infrastructure and bindings are written in Zig, but it uses Apple's JavaScriptCore engine written in C++ (i.e. Zig is essentially used in a thin wrapper layer around a large C++ engine). Bun itself apparently struggles with stability and production readiness. Oven (Bun's company) has around 2-10 employees according to LinkedIn.
        epolanski 1y ago
        Been using bun from years, it's as stable as alternatives from a long time.
    - throwawaymaths 1y ago
      lightpanda and bun
      - Rochus 1y ago
        Lightpanda looks interesting, thanks for the hint. According to public sources, behind the development is a company of 2-10 employees (like Bun). The engine uses parts of the Netsurf browser (written in C) and the V8 engine (written in C++), and - as far a I can tell - is in an early development stage.
- justinhj 1y ago
  As a Zig adopter I was rooting for this because even though there is the official documentation and some great community content, it's nice to just kick back and read a well written book. I'm also very happy with other Manning titles; they have built a high level of trust with me. To answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support. What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today. Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.
Ygg2 1y ago
What is the point of this book this early? Zig is in too much flux. Language is 0.x for a reason. Just to gauge interest?
- adamors 1y ago
  Well the MEAP just started, 3 chapters are complete and the rest will follow probably next year. IMO it’s a bet: Zig stays stable enough and this will be _the_ Zig book for a while. Should the bet not pay off it still cements the author as an authority on the language and gets them a foot in the door.
  - mi_lk 1y ago
    Looks like a win-win for the author? Why would the publisher take the bet
    - bombcar 1y ago
      Manning does this all the time, I presume the cost-to-print is so low it doesn't hurt.
      - dom96 1y ago
        When I wrote Nim in Action[1] for Manning, it was prior to 1.0 as well. It was definitely a bit akward, but breaking changes to the stuff covered in the book was relatively minor. 1 - https://book.picheta.me/ https://book.picheta.me/
    - mtlynch 1y ago
      Manning doesn't pay that much to first time authors, and it looks like it's the first book for the author, Garrison Hinson-Hasty. My guess is it's about $2k upfront and the author owes it back if they don't deliver. Teiva Harsanyi did a good writeup recently about working with Manning as a first-time author. He got $2k upfront and $2k after delivering the first 1/3rd.[0] [0] https://www.thecoder.cafe/p/100-go-mistakes https://www.thecoder.cafe/p/100-go-mistakes
bjackman 1y ago
Not a comment on the book but I hope a slightly off topic thread is OK... As a systems programmer, what is the selling point of Zig? For me, memory safety is the number 1, 2, 3, 4 and 5 problem with C. A new language that doesn't solve those problems seems very strange to me. And as a counterpoint, I will tolerate massive number of issues with Rust because it gives us memory safety. I work in security so that may give me a bias. But maybe instead of "bias" it's more like awareness. If you don't deal with it day in, day out, it seems impossible to really internalise how completely fucking broken something like the Linux kernel is. Continuing to write e.g. driver code in an unsafe language is just not acceptable for our civilisation. But, also maybe you don't need full complete memory safety, if a language has well designed abstractions maybe it can just be "safe enough in practice". I've worked on C++ code that feels that way. Is this the deal with Zig?
- hansvm 1y ago
  You touched on the idea in your last paragraph. Comparing Zig to C using memory safety as a binary threshold instead of a continuous scale is apples to oranges. For one, Rust isn't even at the far right of the memory safety scale, so any argument against Zig due to some epsilon of safety has to reckon with the epsilon Rust is missing as well. That scale exists, and in choosing a language we're choosing (among other things) where on that scale we want to be. Maybe Rust is "good enough", and maybe not. For two, there's a lot more to software design than memory safety _even when your goals revolve around the safety and stability of the end product_. So long as you get the basics right (like how Zig uses slices by default and has defer/errdefer statements), you won't have an RCE from a memory safety bug, or at least not one that you wouldn't likely see in Rust anyway (e.g., suppose you're writing a new data structure in both languages; suppose that it involves back-references or something else where the common pattern in Rust would involve creating backing memory and passing indices around, combined with an unsafe block on the actual cell access to satisfy the borrow checker; the fact that you had to do something in an unsafe block opens you up to safety issues like index wraparound causing OOB reads). If memory safety is "good enough" from an RCE perspective, what are we buying with the rest of Rust's memory safety? Why is it so important? For everything else, you're just preventing normal application bugs -- leaking user data, incorrect computations, random crashes, etc. The importance of normal application bugs varies from project to project, but in the context of systems programming of any kind I'll argue that these are absolutely as critical as RCEs and the other "big" things you're trying to prevent via memory safety. The whole reason you try to prevent an RCE is to ensure that you have access to your files/data/tools and that an attacker doesn't, but if logic bugs corrupt data, crash your tools, and leak PII then you're still fucked. Memory safety didn't save you. That shift in perspective is important. If our goal is preventing ordinary application bugs on top of memory-safety bugs it becomes blatantly obvious that you'd be willing to trade a little safety for some bug prevention. Does Zig actually help reduce bugs though? IME, yes. The big thing it has going for it is that it's a small, cohesive language that gives you the power you need to do the things you're trying to do. Being small makes it possible to create features that compose well and are correct by default, and having the power to do what you're trying to do means you don't have to create convoluted (expensive, bug-prone) workarounds. Some examples: 1. `let` rebindings in Rust are a great feature, and I like them a lot. Better than 90% of the time I use them correctly. The other 10% I'm instead trying to create a new variable and accidentally shadowing an existing one. That's often not the end of the world, but if there exists any code after my `let` rebinding expecting the old value then it's totally incorrect (assuming compatible types so that you don't have a compilation failure). Zig yells loudly about the error. 2. The error-handling system in Zig is easy to get right because of largely compatible return types. By contrast, I see an awful lot of `unwrap` in Rust code in places that really shouldn't have it, and in codebases that try to use `?` or other more-likely-to-be-correct strategies the largely incompatible return types force most people into slapping `anyhow` around everything and calling it a day. 3. Going back to error-handling, Rust allows intentional discards of return values, but if you start by discarding the return value of a non-error function and the signature is later updated to potentially return errors Rust still lets you discard the value. Zig forces you to do something explicitly acknowledging that there was an error. 100% of the time the compiler has yelled at me for a potential logic bug it was correct to do so. It really is just a bunch of little things, but those little things add up and make for a pleasant language with shockingly few bugs. Maybe my team is just even more exceptional than I already think or something and I'm over-indexing on the language, but in the last couple years I haven't seen a single memory safety issue, or much in the way of other bugs in the Zig part of the company.
picafrost 1y ago
Excellent way to stay busy producing revised editions over the next few years. I really enjoy writing Zig and I think it's going to be an important language in the future. I do not enjoy porting my code between versions of the language. But early adopters are important for exploring the problem space, and I would have loved to find a canonical source (aside from the docs, which are mostly nice) for learning the language when I did. A text that evolves with the language has a better chance of becoming that canonical onboarding source.
techjuice 1y ago
I think this is great, gives those wanting a good formal foundation a guide to getting organized and making something happen. With time this is also going to be great for the author with new iterations of the book, but getting in early like this can set the author and the language up for success long term.
materiallie 1y ago
Zig certainly has a lot of interesting features and good ideas, but I honestly don't see the point of starting a major project with it. With alternatives like Rust and Swift, memory safety is simply table stakes these days. Yes, I know Zig does a lot of things to help the programmer avoid mistakes. But the last time I looked, it was still possible to make mistakes. The only time I would pick something like C, C++, or Rust is if I am planning to build a multi-million line, performance sensitive project. In which case, I want total memory safety. For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all. That leaves me a little bit confused about the value proposition of Zig. I suppose it's a "better C". But like I said, for serious industry projects starting in 2025, memory safety is just tablestakes these days. This isn't meant to be a criticism of Zig or all of the hard work put into the language. I'm all for interesting projects. And certainly there are a lot of interesting ideas in Zig. I'm just not going to use them until they're present in a memory safe language. I am actually a bit surprised by the popularity of Zig on this website, given the strong dislike towards Go. From my perspective, both languages are very similar, from the perspective that they decided to "unsolve already solved problems". Meaning, we know how to guarantee memory safety. Multiple programming languages have implemented this in a variety of ways. Why would I use a new language that takes a problem a language like Rust, Java, or Swift already solved for me, and takes away features (memory safety) that I already have?
- winrid 1y ago
  Zig has a pretty great type system, and sometimes languages like Rust and C++ are not great with preventing accidental heap allocations. Zig and C make this very explicit, and it's great to be able to handle allocation failures in robust software.
  - pjmlp 1y ago
    That is the usual fallacy, because it assumes everyone has full access to whole source code and is tracking down all the places where heap is being used. It also assumes that the OS doesn't lie to the application when allocations fail.
HippoBaro 1y ago
I’m very excited for Zig personally, but calling it “ultra reliable” feels very premature. The language isn’t even stable, which is pretty much the opposite of something you can rely on. We’ll know in many years if it was something worth relying on.

166 points by signa11 1y ago

As a developer interested in zig it is nice to see books being release, but I'd be a bit resitant to buy anything before zig reaches 1.0 or at least when they settle on a stable api. Both the builder and the std keep changing. Just 0.15 is a huge breakage. Does anyone knows how those changes would affect this book?

turtleyacht 1y ago
Author links to 0.15.1 Zig docs in several places, at least for now. Outstanding issue on Zig side for 1.0 release: https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
zwnow 1y ago
With how its going I feel Zig 1.0 wont be a thing until my retirement in 37 years
- testdelacc1 1y ago
  I’m willing to bet $5 it happens in 4 years or fewer.
  - ebri 1y ago
    That’s a pretty low confidence if we measure confidence in dollars willing to risk
    - testdelacc1 1y ago
      It’s 100% of my annual betting budget though!
  - tialaramex 1y ago
    Do you have a history we can look at to see how good you are at predicting this for programming languages? Like say, some 2020 predictions you had for languages which would or would not ship 1.0 by 2025 ?
    - testdelacc1 1y ago
      I made a set of predictions for Rust in 2022, nearly all of which turned out to be correct. And I was publicly confident Go and Rust would be massive when they reached 1.0. I was right on both counts. But I will also admit I don’t follow developments in zig as closely as Rust. I’ve never written any Zig. And in any case, past performance isn’t indicative of future performance. I could be wrong about this prediction, but I don’t think I will be. From what I’ve seen Andy Kelley is a perfectionist who could work on point releases forever. But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. They’ll nudge him towards 1.0. They can wait a few years, but not forever. That’s why I guessed 4 years.
      - jorangreef 1y ago
        > But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. TB is only 5 years old but already migrating some of the largest brokerages, exchanges and wealth managements in their respective jurisdictions. Zig’s quality for us here holds up under some pretty extreme fuzzing (a fleet of 1000 dedicated CPU cores), Deterministic Simulation Testing and Jepsen auditing (TB did 4x the typical audit engagement duration), and is orthogonal to 1.0 backwards compatibility. Zig version upgrades for our team are no big deal, compared to the difficulty of the consensus and local storage engine challenges we work on, and we vendor most of our std lib usage in stdx. > They’ll nudge him towards 1.0. On the contrary, we want Andrew to take his time and get it right on the big decisions, because the half life of these projects can be decades. We’re in no rush. For example, TigerBeetle is designed to power the next 30 years of transaction processing and Zig’s trajectory here is what’s important. That said, Zig and Zig’s toolchain today, is already better, at least for our purposes, than anything else we considered using.
  - noshitsherlock 1y ago
    Wouldn’t you think AI advances in 4 years would make this a safe bet?
    - therein 1y ago
      No, unless you're riding the hype train so hard that you are excited to go to colonize Mars thanks to AI advances.
- bnolsen 1y ago
  The language itself won't change much. The standard library is what is still in flux.
Rochus 1y ago
Is this really the first Zig book since the development startet in 2016? Maybe the language and library is just too volatile for a book.
- wslh 1y ago
  Or it evolves smoothly at another pace.
osigurdson 1y ago
People are doing real companies with Zig (e.g. Tiger Beetle) and important projects (e.g. Ghostty) without the 1.0 backward compatibility guarantee. Zig must be doing something right. Maybe this also keeps opinionated 9-5er, enterprise type devs out of it as well which might be a good thing :).
- Rochus 1y ago
  Are there other notable commercial companies/projects than Tiger Beetle relying on Zig? According to public information, Tiger Beetle are about eight employees with a single customer, isn't it?
  - jakogut 1y ago
    Bun.sh uses zig for large portions of native code.
    - Rochus 1y ago
      Thanks for the hint. According to public sources, Bun's runtime infrastructure and bindings are written in Zig, but it uses Apple's JavaScriptCore engine written in C++ (i.e. Zig is essentially used in a thin wrapper layer around a large C++ engine). Bun itself apparently struggles with stability and production readiness. Oven (Bun's company) has around 2-10 employees according to LinkedIn.
      - epolanski 1y ago
        Been using bun from years, it's as stable as alternatives from a long time.
  - throwawaymaths 1y ago
    lightpanda and bun
    - Rochus 1y ago
      Lightpanda looks interesting, thanks for the hint. According to public sources, behind the development is a company of 2-10 employees (like Bun). The engine uses parts of the Netsurf browser (written in C) and the V8 engine (written in C++), and - as far a I can tell - is in an early development stage.
justinhj 1y ago
As a Zig adopter I was rooting for this because even though there is the official documentation and some great community content, it's nice to just kick back and read a well written book. I'm also very happy with other Manning titles; they have built a high level of trust with me. To answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support. What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today. Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.

Ygg2 1y ago

What is the point of this book this early? Zig is in too much flux. Language is 0.x for a reason. Just to gauge interest?

adamors 1y ago
Well the MEAP just started, 3 chapters are complete and the rest will follow probably next year. IMO it’s a bet: Zig stays stable enough and this will be _the_ Zig book for a while. Should the bet not pay off it still cements the author as an authority on the language and gets them a foot in the door.
- mi_lk 1y ago
  Looks like a win-win for the author? Why would the publisher take the bet
  - bombcar 1y ago
    Manning does this all the time, I presume the cost-to-print is so low it doesn't hurt.
    - dom96 1y ago
      When I wrote Nim in Action[1] for Manning, it was prior to 1.0 as well. It was definitely a bit akward, but breaking changes to the stuff covered in the book was relatively minor. 1 - https://book.picheta.me/ https://book.picheta.me/
  - mtlynch 1y ago
    Manning doesn't pay that much to first time authors, and it looks like it's the first book for the author, Garrison Hinson-Hasty. My guess is it's about $2k upfront and the author owes it back if they don't deliver. Teiva Harsanyi did a good writeup recently about working with Manning as a first-time author. He got $2k upfront and $2k after delivering the first 1/3rd.[0] [0] https://www.thecoder.cafe/p/100-go-mistakes https://www.thecoder.cafe/p/100-go-mistakes

bjackman 1y ago

Not a comment on the book but I hope a slightly off topic thread is OK... As a systems programmer, what is the selling point of Zig? For me, memory safety is the number 1, 2, 3, 4 and 5 problem with C. A new language that doesn't solve those problems seems very strange to me. And as a counterpoint, I will tolerate massive number of issues with Rust because it gives us memory safety. I work in security so that may give me a bias. But maybe instead of "bias" it's more like awareness. If you don't deal with it day in, day out, it seems impossible to really internalise how completely fucking broken something like the Linux kernel is. Continuing to write e.g. driver code in an unsafe language is just not acceptable for our civilisation. But, also maybe you don't need full complete memory safety, if a language has well designed abstractions maybe it can just be "safe enough in practice". I've worked on C++ code that feels that way. Is this the deal with Zig?

hansvm 1y ago
You touched on the idea in your last paragraph. Comparing Zig to C using memory safety as a binary threshold instead of a continuous scale is apples to oranges. For one, Rust isn't even at the far right of the memory safety scale, so any argument against Zig due to some epsilon of safety has to reckon with the epsilon Rust is missing as well. That scale exists, and in choosing a language we're choosing (among other things) where on that scale we want to be. Maybe Rust is "good enough", and maybe not. For two, there's a lot more to software design than memory safety _even when your goals revolve around the safety and stability of the end product_. So long as you get the basics right (like how Zig uses slices by default and has defer/errdefer statements), you won't have an RCE from a memory safety bug, or at least not one that you wouldn't likely see in Rust anyway (e.g., suppose you're writing a new data structure in both languages; suppose that it involves back-references or something else where the common pattern in Rust would involve creating backing memory and passing indices around, combined with an unsafe block on the actual cell access to satisfy the borrow checker; the fact that you had to do something in an unsafe block opens you up to safety issues like index wraparound causing OOB reads). If memory safety is "good enough" from an RCE perspective, what are we buying with the rest of Rust's memory safety? Why is it so important? For everything else, you're just preventing normal application bugs -- leaking user data, incorrect computations, random crashes, etc. The importance of normal application bugs varies from project to project, but in the context of systems programming of any kind I'll argue that these are absolutely as critical as RCEs and the other "big" things you're trying to prevent via memory safety. The whole reason you try to prevent an RCE is to ensure that you have access to your files/data/tools and that an attacker doesn't, but if logic bugs corrupt data, crash your tools, and leak PII then you're still fucked. Memory safety didn't save you. That shift in perspective is important. If our goal is preventing ordinary application bugs on top of memory-safety bugs it becomes blatantly obvious that you'd be willing to trade a little safety for some bug prevention. Does Zig actually help reduce bugs though? IME, yes. The big thing it has going for it is that it's a small, cohesive language that gives you the power you need to do the things you're trying to do. Being small makes it possible to create features that compose well and are correct by default, and having the power to do what you're trying to do means you don't have to create convoluted (expensive, bug-prone) workarounds. Some examples: 1. `let` rebindings in Rust are a great feature, and I like them a lot. Better than 90% of the time I use them correctly. The other 10% I'm instead trying to create a new variable and accidentally shadowing an existing one. That's often not the end of the world, but if there exists any code after my `let` rebinding expecting the old value then it's totally incorrect (assuming compatible types so that you don't have a compilation failure). Zig yells loudly about the error. 2. The error-handling system in Zig is easy to get right because of largely compatible return types. By contrast, I see an awful lot of `unwrap` in Rust code in places that really shouldn't have it, and in codebases that try to use `?` or other more-likely-to-be-correct strategies the largely incompatible return types force most people into slapping `anyhow` around everything and calling it a day. 3. Going back to error-handling, Rust allows intentional discards of return values, but if you start by discarding the return value of a non-error function and the signature is later updated to potentially return errors Rust still lets you discard the value. Zig forces you to do something explicitly acknowledging that there was an error. 100% of the time the compiler has yelled at me for a potential logic bug it was correct to do so. It really is just a bunch of little things, but those little things add up and make for a pleasant language with shockingly few bugs. Maybe my team is just even more exceptional than I already think or something and I'm over-indexing on the language, but in the last couple years I haven't seen a single memory safety issue, or much in the way of other bugs in the Zig part of the company.

picafrost 1y ago

Excellent way to stay busy producing revised editions over the next few years. I really enjoy writing Zig and I think it's going to be an important language in the future. I do not enjoy porting my code between versions of the language. But early adopters are important for exploring the problem space, and I would have loved to find a canonical source (aside from the docs, which are mostly nice) for learning the language when I did. A text that evolves with the language has a better chance of becoming that canonical onboarding source.

techjuice 1y ago

I think this is great, gives those wanting a good formal foundation a guide to getting organized and making something happen. With time this is also going to be great for the author with new iterations of the book, but getting in early like this can set the author and the language up for success long term.

materiallie 1y ago

Zig certainly has a lot of interesting features and good ideas, but I honestly don't see the point of starting a major project with it. With alternatives like Rust and Swift, memory safety is simply table stakes these days. Yes, I know Zig does a lot of things to help the programmer avoid mistakes. But the last time I looked, it was still possible to make mistakes. The only time I would pick something like C, C++, or Rust is if I am planning to build a multi-million line, performance sensitive project. In which case, I want total memory safety. For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all. That leaves me a little bit confused about the value proposition of Zig. I suppose it's a "better C". But like I said, for serious industry projects starting in 2025, memory safety is just tablestakes these days. This isn't meant to be a criticism of Zig or all of the hard work put into the language. I'm all for interesting projects. And certainly there are a lot of interesting ideas in Zig. I'm just not going to use them until they're present in a memory safe language. I am actually a bit surprised by the popularity of Zig on this website, given the strong dislike towards Go. From my perspective, both languages are very similar, from the perspective that they decided to "unsolve already solved problems". Meaning, we know how to guarantee memory safety. Multiple programming languages have implemented this in a variety of ways. Why would I use a new language that takes a problem a language like Rust, Java, or Swift already solved for me, and takes away features (memory safety) that I already have?

winrid 1y ago
Zig has a pretty great type system, and sometimes languages like Rust and C++ are not great with preventing accidental heap allocations. Zig and C make this very explicit, and it's great to be able to handle allocation failures in robust software.
- pjmlp 1y ago
  That is the usual fallacy, because it assumes everyone has full access to whole source code and is tracking down all the places where heap is being used. It also assumes that the OS doesn't lie to the application when allocations fail.

HippoBaro 1y ago

I’m very excited for Zig personally, but calling it “ultra reliable” feels very premature. The language isn’t even stable, which is pretty much the opposite of something you can rely on. We’ll know in many years if it was something worth relying on.