13 ms·

Why is Zig so cool?

• drnick1 1y ago
  All these new languages like Zig, Rust, etc are ass with their "fn" keywords and all that. Long live C!
• cat-whisperer 1y ago
  I just discovered that you can add build-time arguments that get baked in. It's soo awesome!
• ForHackernews 1y ago
  > I can’t think of any other language in my 45 years long career that surprised more than Zig. I can easily say that Zig is not only a new programming language, but it’s a totally new way to write programs, in my opinion. To say it’s merely a language to replace C or C++, it’s a huge understatement. I don't understand how the things presented in this article are surprising. Zig has several nice features shared by many modern programming languages?
  • raincole 1y ago
    > One may wonder how the compiler discovers the variable type. The type in this case is *inferred* by the initialization. That the author feels the need to emphasize this means either that they haven't paid attention to modern languages for a very long time, or this article is for people who haven't paid attention to modern languages for a very long time. Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature. > One is Zig’s robustness. In the case of the shift operation no wrong behavior is allowed and the situation is caught at execution time, as has been shown. Panicking at runtime is better than just silently overflowing, but I don't know if it's the best example to show the 'robustness' of a language...
    • creata 1y ago
      > Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature. I'm not even sure I'd call this type inference (other people definitely do call it type inference) given that it's only working in one direction. Even Java (var) and C23 (auto), the two languages the author calls out, have that. It's much less convenient than something like Hindley-Milner.
    • sarchertech 1y ago
      > Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature. It’s not common in lower level languages without garbage collectors or languages focused on compilation speed.
      • foobar1726 1y ago
        C++ added auto 14 years ago. Swift had it since day 1 back in 2014 if I remember right. What else is there?
        • sarchertech 1y ago
          C, Ada, Fortran, Pascal.
      • jolux 1y ago
        Compilation speed — OCaml, Go, D, C#, Java “Low-level” languages — Rust, C++, D
        • sarchertech 1y ago
          I meant for focused on compilation speed to apply only to lower level languages. And when I say lower level I don’t really include D because it has a garbage collector (I know it’s optional but much of the standard library uses it I believe).
  • fuzzy_biscuit 1y ago
    Of which, perhaps, the author isn't aware? Perhaps the author has very narrow experience in programming languages. Or it's hyperbolic.
    • moralestapia 1y ago
      >Perhaps the author has very narrow experience in programming languages. I got that impression as well. Xi's impressed about types being optional because they can be inferred. That's ... hardly a novelty ...
      • forgotpwd16 1y ago
        >Only the first and third part are compulsory in Zig, which is kind of puzzling, coming from Java or C. Funny they mention Java that has got type inference few years now. Even C got a weaker version of C++'s auto in C23.
        • tialaramex 1y ago
          One of the many things I don't like about C++ is that auto isn't type inference but instead C++ has type "deduction" which is a little different, in some cases a type will be "deduced" even though what you wrote was ambiguous and you may have wanted a different type.
  • blahgeek 1y ago
    This. Is Zig an interesting language? Yes sure. But “a totally new way to write programs”? No, I don’t see a single feature that is not found in any other programming languages.
  • chrisco255 1y ago
    I feel like the article didn't really hit on the big ones: comptime functions, no hidden control flow, elegant defaults, safe buffers, etc. What Zig really does is make systems programming more accessible. Rust is great, but its guarantees of memory safety come with a learning curve that demands mastering lifetimes and generics and macros and a complex trait system. Zig is in that class of programming languages like C, C++, and Rust, and unlike Golang, C#, Java, Python, JS, etc that have built-in garbage collection. The explicit control flow allows you as a developer to avoid some optimizations done in Rust (or common in 3rd party libraries) that can bloat binary sizes. This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether. The built-in C/C++ compiler and language features for interacting with C code easily also ensures that devs have access to a mature ecosystem despite the language being young. My experience with Zig so far has been pleasurable. The main downside to the language has been the churn between minor versions (language is still pre-1.0 so makes perfect sense, but still). That being said, I like Zig's new approach to explicit async I/O that parallels how the language treats Allocators. It feels like the correct way to do it and allows developers again the flexibility to control how async and concurrency is handled (can choose single-threaded event loop or multi-threaded pool quite easily).
    • fleventynine 1y ago
      > This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether. I don't think there's is any significant different here between zig, C and Rust for bare-metal code size. I can get the compiler to generate the same tiny machine code in any of these languages.
      • chrisco255 1y ago
        That's not been my experience with Rust. On average produces binaries at least 4x bigger than the Zig I've compiled (and yes, I've set all the build optimization flags for binary size). I know it's probably theoretically possible to achieve similar results with Rust, it's just you have to be much more careful about things like monomorphization of generics, inlining, macro expansion, implicit memory allocation, etc that happen under the hood. Even Rust's standard library is quite hefty. C, yes, you can compile C quite small very easily. Zig is like a simpler C, in my mind.
  • bsder 1y ago
    Winning at chess is more "avoid gigantic blunders" than "make brilliant moves". Zig feels like one of the few programming languages that mostly just avoids gigantic blunders. I have some beefs with some decisions, but none of them that are an immutable failure mode that couldn't be fixed in a straightforward manner.
• hamandcheese 1y ago
  Zig being able to (cross)compile C and C++ feels very similar to how UV functions as a drop in replacement for pip/pip-tools. Seems like a fantastic way to gain traction in already established projects.
  • fastball 1y ago
    Strangler fig
    • FragenAntworten 1y ago
      This is referring to the Strangler Fig design pattern, which is relevant: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig https://learn.microsoft.com/en-us/azure/architecture/pattern...
  • archargelod 1y ago
    I love Zig. Never tried to write it though =). I just use a it as cross-compiler for my Nim[0] programs. [0] - https://nim-lang.org https://nim-lang.org
• pphysch 1y ago
  That inline test syntax is pretty cool; where does it come from?
• _gmkt 1y ago
  I would like to see the output of the: ldd your-zig-executable :)
  • alexrp 1y ago
    Zig defaults to statically linking musl when targeting Linux, so the output will not be very interesting unless you target dynamic musl, or glibc, or FreeBSD/NetBSD.
• pron 1y ago
  > I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros are "referentially opaque" and therefore more powerful than a referentially transparent partial evaluation - e.g. partial evaluation has no access to an argument's name), it turns out that it's powerful enough to replace not only most "reasonable" uses of macros, but also generics and interfaces. What gives Zig's partial evaluation (comptime) this power is its access to reflection. Even when combined with reflection, partial evaluation is more pleasurable to work with than macros. In fact, to understand the program's semantics, partial evaluation can be ignored altogether (as it doesn't affect the meaning of computations). I.e. the semantics of a Zig program are the same as if it were interpreted by some language Zig' that is able to run all of Zig's partial-evaluation code (comptime) at runtime rather than at compile time. Since it also removes the need for other specialised features (generics, interfaces) - even at the cost of an aesthetic that may not appeal to fans of those specialised features - it ends up creating a very expressive, yet surprisingly simple and easy-to-understand language (Lisps are also simple and expressive, but the use of macros makes understanding a Lisp program less easy). Being simple and easy to understand makes code reviews easier, which may have a positive impact on correctness. The simplicity can also reduce compilation time, which may also have a positive impact on correctness. Zig's insistence on explicitness - no overloading, no hidden control flow - which also assists reviews, may not be appropriate for a high-level language, but it's a great fit for an unabashedly low-level language, where being able to see every operation as explicit code "on the page" is important. While its designer may or may not admit this, I think Zig abandons C++'s belief that programs of all sizes and kinds will be written in the same language (hence its "zero-cost abstractions", made to give the illusion of a high-level language without its actual high-level abstraction). Developers writing low-level code lose the explicitness they need for review, while those writing high-level programs don't actually gain the level of abstraction required for a smooth program evolution that they need. That belief may have been reasonable in the eighties, but I think it has since been convincingly disproved. Some Zig decisions surprised me in a way that made me go more "huh" than "wow", such as it having little encapsulation to speak of. In a high-level language I wouldn't have that (after years of experience with Java's wide ecosystem of libraries, we learned that we need even more and stronger encapsulation than we originally had to keep compatibility while evolving code). But perhaps this is the right choice for a low-level language where programs are expected to be smaller and with fewer dependencies (certainly shallower dependency graphs). I'm curious to see how this pans out. Zig's terrific support for arenas also makes one of the most powerful low-level memory management techniques (that, like a tracing garbage collector, gives the developer a knob to trade off RAM usage for CPU) very accessible. I have no idea or prediction on whether Zig will become popular, but it's certainly fascinating. And, being so remarkably easy to learn (especially if you're familiar with low-level programming), it costs little effort to give it a try.
• simonw 1y ago
  A neat little thing I like about Zig is one of the options for installing it is via PyPI like this: https://pypi.org/project/ziglang/ https://pypi.org/project/ziglang/ pip install ziglang Which means you don't even have to install it separately to try it out via uvx. If you have uv installed already try this: cd /tmp echo '#include <stdio.h> int main() { printf("Hello, World!"); return 0; }' > hello.c uvx --from ziglang python-zig cc /tmp/hello.c ./a.out
  • giancarlostoro 1y ago
    That's really cool actually. Now that AI is a little more commonly available for developer tooling I feel like its easier than ever to learn any programming language since you can braindrain the model.
    • yoyohello13 1y ago
      The standard models are pretty bad a zig right now since the language is so new and changes so fast. The entire language spec is available in one html file though so you can have a little better success feeding that for context.
      • hdjrudni 1y ago
        > The entire language spec is available in one html file though so you can have a little better success feeding that for context. This is what I've started doing for every library I use. I go to their Github, download their docs, and drop the whole thing into my project. Then whenever the AI gets confused, I say "consult docs/somelib/"
        • RamtinJ95 1y ago
          Just use gh_grep mcp and the model will fetch what it needs if you tell it to, no need to download from GitHub manually like this
        • Keyframe 1y ago
• deleted 1y ago
  [deleted]
• pyrolistical 1y ago
  I totally vibe with the intro but then the rest of the article goes on to be a showcase bits of zig. I feel what is missing is how each feature is so cool compared to other languages. As a language nerd zig syntax is just so cool. It doesn’t feel the need to adhere to any conventions and seems to solve the problems in the most direct and simple way. An example of this declaring a label and referring to a label. By moving the colon to either end it makes labels instantly understood which form it is. And then there is the runtime promises such as no hidden control flow. There are no magical @decorators or destructors. Instead we have explicit control flow like defer. Finally there is comptime. No need to learn another macro syntax. It’s just more zig during compilation
  • deleted 1y ago
    [deleted]
  • rvrb 1y ago
    matklad did it justice in his post here, in my opinion https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
    • srcreigh 1y ago
      Thread: https://news.ycombinator.com/item?id=44855881 https://news.ycombinator.com/item?id=44855881
  • badtuple 1y ago
    I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt like using a tool I'd used for years, and that's special. Zig's big feature imo is just the relative absence of warts in the core language. I really don't know how to communicate that in an article. You kind of just have to build something in it.
• rvrb 1y ago
  I've tried writing a similar post, but I think it's a bit difficult to sound convincing when talking about why Zig is so pleasant. it's really not any one thing. it's a culmination of a lot of well made, pragmatic decisions that don't sound significant on their own. they just culminate in a development experience that feels pleasantly unique. a few of those decisions seem radical, and I often disagreed with them.. but quite reliably, as I learned more about the decision making, and got deeper into the language, I found myself agreeing with them afterall. I had many moments of enlightenment as I dug deeper. so anyways, if you're curious, give it an honest chance. I think it's a language and community that rewards curiosity. if you find it fits for you, awesome! luckily, if it doesn't, there's plenty of options these days (I still would like to spend some quality time with Odin)
  • deleted 1y ago
    [deleted]
  • andai 1y ago
    +1 for Odin. I wrote a little game in it last year and found it delightful.
    • brabel 1y ago
      I prefer Odin to Zig after trying both... but it seems Odin's performance is a bit lower than Zig, C and Rust?! Have you noticed any performance issues or it's not something to worry about?
      • 59nadir 1y ago
        No, I write Odin for production and there is no performance difference to speak of coming from the way the compiler or language works. If you have one it's likely because of an older/different LLVM version being used, but AFAIK Odin stays as up-to-date as you can without tearing your hair out (and that's good because GingerBill has none of that to spare). There might be a few pathological code paths in the core libraries or whatever for certain things that aren't what they should be, but in terms of the raw language you're in the land of C as much as with any of these languages; Odin really doesn't do much on top of C, and what it's doing is identifiable and can be opted out of; if you find that a function in a hot loop is marginally slower than it ought to be, you can make it contextless, for example, and see whether that makes a difference. We haven't found (in a product where performance is explicitly a feature, also containing a custom 3D engine on top of that) that the context being passed automatically in Odin is of much concern performance-wise. Out of the languages mentioned Rust is the one I've seen in benchmarks be routinely marginally slower, but it's not by a meaningful amount.
• didip 1y ago
  Is it cool? It seems to be in nether land between Rust and Go. Not sure what is the unique use case for Zig.
  • jorangreef 1y ago
    We could not have written TigerBeetle, at least not the way it is, without Zig: https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbeetle-pledge-512k-to-the-zig-software-foundation/ https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...
    • sgt 1y ago
      TigerBeetle has a clear purpose and needed those brilliant optimizations. Do you think Zig is suitable as, say, a Go replacement for prod network services and such? Aside from the fact that Zig is still a bit immature in its std library and ecosystem, I mean. Is it a suitable systems language going forward?
      • jorangreef 1y ago
        Thanks! Zig is actually perfect for production network services (that’s all TB is essentially, or how I see it, and what I was looking for in Zig—how to create something with explicit limits that can handle overload—it’s hard to build anything production-grade if it’s not doing NASA’s Power of Ten and getting allocation right—GC is not a good idea for a network service). I wouldn’t say Zig’s std lib is immature. Or if anything, it has higher quality than most std libs. For example, the unmanaged hashmap interface is :chefskiss. In comparison, many std libs are yet to get non-global allocators or static allocation or I/O right.
        • sgt 1y ago
          That's great feedback. Many of us are looking at the next 5-10 years of building network services. Go has its share of issues that simply won't go away. Rust is overly complex ("concept fatigue"). Python will remain slow. So here comes Zig with massive potential and the ecosystem and community is really engaging.
• meisel 1y ago
  For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?
  • rvrb 1y ago
    the answer I've seen when it has been brought up before is that (for allocators) there is not a practical impact on performance -- allocating takes way more time than the virtual dispatch does, so it ends up being negligible. for code bloat, I'm not sure what you mean exactly; the allocator interface is implemented via a VTable, and the impact on binary size is pretty minimal. you're also not really creating more than a couple of allocators in an application (typically a general purpose allocator, and maybe an arena allocator that wraps it in specific scenarios). for IO, which is new and I have not actually used yet, here are some relevant paragraphs: The new Io interface is non-generic and uses a vtable for dispatching function calls to a concrete implementation. This has the upside of reducing code bloat, but virtual calls do have a performance penalty at runtime. In release builds the optimizer can de-virtualize function calls but it’s not guaranteed. ... A side effect of proposal #23367, which is needed for determining upper bound stack size, is guaranteed de-virtualization when there is only one Io implementation being used (also in debug builds!). https://kristoff.it/blog/zig-new-async-io/ https://kristoff.it/blog/zig-new-async-io/ https://github.com/ziglang/zig/issues/23367 https://github.com/ziglang/zig/issues/23367
    • jibal 1y ago
      He's talking about passing the pointers to the allocators and Io objects as parameters throughout the program, not how allocator vtables for calling the allocator's virtual functions are implemented. But context pointers are a requirement in any program. Consider that a context pointer (`this`) is passed to every single method call ... it's no more "code bloat" than having to save and restore registers on every call.
  • garbagepatch 1y ago
    Regarding runtime overhead, I'd assume you would still need an io implementation, it is just showing it to you explicitly instead of it being hidden behind the std lib. For simple projects where you don't want to pass it around in function parameters, you can create a global object with one implementation and use it from everywhere.
• KerrAvon 1y ago
  Nothing against (or for) Zig, but the article author seems unfamiliar with other modern languages in common use... imagine if they saw Swift or Rust. Their mind would be utterly, utterly blown.
• kae3g 1y ago
  [dead]
• robotresearcher 1y ago
  > Probably the most incredible virtue of Zig compiler is its ability to compile C code. This associated with the ability to cross-compile code to be run in another architecture, different than the machine where it is was originally compiled, is already something quite different and unique. Isn't cross compilation very, very ordinary? Inline C is cool, like C has inline ASM (for the target arch). But cross-compiling? If you built a phone app on your computer you did that as a matter of course, and there are many other common use cases.
  • crest 1y ago
    > Isn't cross compilation very, very ordinary? Working cross compilation out of the box any-to-any still isn't.
    • BoorishBears 1y ago
      Yes, very rare and there is a strong cartel of companies ensuring it doesn't happen in more mainstream langs through multiple avenues to protect their interests! From helicoptering folks onto steering committee and indoctrination of young CS majors.
      • rmunn 1y ago
        If I had the ability to downvote a comment yet, I'd downvote you. If you're going to spout conspiracy-theory-sounding stuff, at least provide some evidence for your claims!
        • BoorishBears 1y ago
          It doesn't sound like a conspiracy theory, you just have an incredibly poorly calibrated sense of judgement as to the tone of a statment. Not uncommon in this space though, especially as you get closer to the metal (close as cross-compilation is relative to something like React frontends, at least)
      • TylerE 1y ago
• tetrisgm 1y ago
  Move Zig. For great justice!
  • skellystudios 1y ago
    Take off every Zig!
    • tetrisgm 1y ago
      What you say
• dxxvi 1y ago
  There's at least 1 thing that Zig is better than Rust is that Zig compiler for Windows can be downloaded, unzipped then used without admin right. Rust needs msvc, which cannot be installed without admin right. It is said that Rust on Windows can use cygwin but I cannot make it work even with AI help.
  • tremololo 1y ago
    You should check out cargo-zigbuild which makes use of zig for cross compiling rust projects. https://github.com/rust-cross/cargo-zigbuild https://github.com/rust-cross/cargo-zigbuild
  • newpavlov 1y ago
    Have you tried the GNU toolchain? IIRC rustup provides the option to use it instead of the MSVC toolchain during the initial installation.
  • dgrunwald 1y ago
    cygwin is a POSIX-emulating library intended for porting POSIX-only programs to Windows. That is: when compiling for cygwin, you'd use the cygwin POSIX APIs instead of the Windows APIs. So anything compiled with cygwin won't be a normal Windows program. There's no reason to use cygwin with Rust, since Rust has native Windows support. The only reason to use x86_64-pc-cygwin is if you would need your program to use a C library that is not available for Windows, but is available for cygwin. If you don't want to/can't use the MSVC linker, the usual alternative is Rust's `x86_64-pc-windows-gnu` toolchain.
• evgpbfhnr 1y ago
  To author -- code sample as images is great for syntax highlight but I wanted to play with the examples and.. got stuck trying to copy the content. (also expected tesseract to do a bit better than this: $ wl-paste -t image/png | tesseract -l eng - - Estimating resolution as 199 const std = @import("std"); const expect = std.testing.expect; const Point = struct {x: i32, y: i32}; test "anonymous struct literal" { const pt: Point = .{ x = 13, -y = 67, 33 try expect (pt.x try expect(pt.y 13); 67); )
  • porridgeraisin 1y ago
    tesseract does well for me... const std = @import("std"); const expect = std.testing.expect; const Point = struct {x: i32, y: i32}; test "anonymous struct literal" { const pt: Point = .{ .x = 13, .y = 67, }; try expect(pt.x == 13); try expect(pt.y == 67); The trick is to preprocess the image a little bit like so: ocr () { magick - -monochrome -negate - | tesseract stdin stdout 2> /dev/null }
    • evgpbfhnr 1y ago
      Thank you! Unfortunately I get the same kind of garbage around closing curly braces / closing parenthesis / dots with this magick filter... It seems to do slightly better with an extra `-resize 400%`, but still very far from as good as what you're getting (to be fair the monochrome filter is not pretty (bleeding) when inspecting the result). I wonder what's different? ( ImageMagick-7.1.1.47-1.fc42.x86_64 and tesseract-5.5.0-5.fc42.x86_64 here, no config, langpack(s) also from the distro)
  • NewsaHackO 1y ago
    Yeah, he definitely should have used a code block for the examples. To the author, if you are trying to preserve code formatting and syntax highlighting, there are JS packages that will take care of all of that and produce clean, copyable, well-rendered, accessible code formatting for you.
• haiji1992 1y ago
  What is Zig?
  • signa11 1y ago
    what comes before Zag ?
• d3Xt3r 1y ago
  Is there a decent native GUI library for Zig yet? I don't want to use bloated toolkits like GTK and Qt. I like the simplicity and speed of Rust's eGUI. Something similar for Zig would be amazing.
  • NoteyComplexity 1y ago
    Is dvui something you want to see? Although the use of backends are still c based, the core part of the gui seems written fully in zig rather than a binding from a c library. https://github.com/david-vanderson/dvui https://github.com/david-vanderson/dvui
  • hommelix 1y ago
    There is capy https://capy-ui.org/ https://capy-ui.org/
    • d3Xt3r 1y ago
      Unfortunately capy uses Gtk+ on Linux, so it's a no-go for me. :(
      • Zen1th 1y ago
        What do you consider to be native GUI on Linux if not something like GTK or Qt ?
        • d3Xt3r 1y ago
          When I said native, I meant native to the language, something written purely in Zig, without depending on external UI toolkits. Basically like how Rust's egui works.
• deleted 1y ago
  [deleted]
• qouteall 1y ago
  In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "something is wrong, don't know which exactly". See: https://github.com/ziglang/zig/issues/2647#issuecomment-1444790576 https://github.com/ziglang/zig/issues/2647#issuecomment-1444... > I just spent way longer than I should have to debugging an issue of my project's build not working on Windows given that all I had to work with from the zig compiler was an error: AccessDenied and the build command that failed. When I finally gave up and switched to rewriting and then debugging things through Node the error that it returned was EBUSY and the specific path in question that Windows considered to be busy, which made the problem actually tractable ... I think the fact that even the compiler can't consistently implement this pattern points to it perhaps being too manual/tedious/unergonomic/difficult to expect the Zig ecosystem at large to do the same
  • qouteall 1y ago
    I know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that. https://github.com/ziglang/zig/issues/2647#issuecomment-2670609338 https://github.com/ziglang/zig/issues/2647#issuecomment-2670...
    • metaltyphoon 1y ago
      > I know that Zig doesn't allow attaching data to error for good reasons. If error data contains interior pointer then it causes memory safety problem IMO this is not a good reason at all.
      • qouteall 1y ago
        Changed to "valid reasons"
• jayd16 1y ago
  Is the inline testing good in practice? I do like the clear proximity and scope of the code being tested but I can also imagine trying to cram in all the unit tests and mocking and logging and such. Does the feature end up feeling unused, dominating app code with test code, or do people end up finding a happy medium?
• RexFactorem 1y ago
  I like D better. And had some of the "cool" features of Zig from quite some time, such as scope(exit) which is clearer. I don't find Zig nearly as readable as my D code, but alas, I don't do systems programming.
• RagnarD 1y ago
  "This associated with the ability to cross-compile code to be run in another architecture, different than the machine where it is was originally compiled, is already something quite different and unique." Perhaps I'm missing something but this is utterly routine. It even has the name used here: Cross-compiling.
  • jibal 1y ago
    If you install Zig, you can now generate executables for virtually any target with just a CLI argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires compiling the compiler to target a different architecture.
    • mrgaro 1y ago
      Doesn't Golang support this as well, out of the box?
      • jibal 1y ago
        Apparently; I wasn't aware. But unlike Zig this doesn't work with FFI ... everything has to be Go code ... cross compilation works by compiling the library code for the target and caching it ... but if you need anything outside of that you're out of luck ... or maybe not ... I ran across this tidbit: "When a Go project utilizes CGo to interact with C code, standard Go cross-compilation might require additional steps. This is because Go can cross-compile Go code but not C code directly, necessitating the availability of target system libraries on the development machine. Tools like Zig can be used as a C compiler (zcc) to facilitate cross-compilation for CGo-dependent projects by providing the necessary cross-compilation capabilities for the C code."
  • andsoitis 1y ago
    > this is utterly routine. It even has the name used here: Cross-compiling. Zig makes cross-compilation trivial and part of the language philosophy. Other languages either rely on external toolchains (C/C++, Rust with C deps) or are limited in target flexibility (Go). For projects targeting multiple OS/architectures, Zig is currently the most straightforward option.
• mobeigi 1y ago
  I've heard good things about Zig. I want to pick it up and experiment with it but at ~2% market share I find it hard to justify spending the time to learn and master it right now. It's usually much easier to find the time to learn a new language if there is a project (work or open source) that is also using it. https://survey.stackoverflow.co/2025/technology https://survey.stackoverflow.co/2025/technology
  • dtj1123 1y ago
    Check out Ghostty. It's a relatively new and ambitious open source project but is rapidly gaining popularity.
  • 59nadir 1y ago
    It can be useful sometimes to learn things irrespective of what the rest of the world thinks of them. My personal experience was (back in 2019) that Zig was basically a language you could learn in a weekend and end up being reasonably productive after a week. With that in mind, you might find that you can try it out and either find something that you really like in it and continue, or simply drop it (I ended up picking Odin over Zig, for example, and have found it delightful even 1+ years into production). The truth is that if you only ever learn what is already popular you'll end up being the professional equivalent of a gray mass with zero definition and unique value proposition.
• krosaen 1y ago
  I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).
  • jibal 1y ago
    Adopted from go, first appeared in D, invented by one of its major developers, Andrei Alexandrescu.
    • jibal 1y ago
      P.S. In D it's `scope(exit)` = defer, `scope(failure)` = Zig's errdefer, and `scope(success)` -- which no one else has and which I have made good use of. e.g., I have a mixin that traces entry and exit from a function, the latter with scope(success). If I use scope(exit) instead then when an exception is thrown all the leave messages are printed and then the stack trace, rather than seeing the stack trace at the point of failure (this baffled me when it first happened).
    • fuzztester 1y ago
      I vaguely remember reading somewhere recently that Andrei left the D community / foundation. Do you know if that is true?
      • jibal 1y ago
        He's moved on: https://research.nvidia.com/person/andrei-alexandrescu https://research.nvidia.com/person/andrei-alexandrescu
  • tcfhgj 1y ago
    But you can forget it, unlike C++ destructors
  • lenkite 1y ago
    I would like a language to support both defer and C++ style destructors / Rust Drop. There are good use-cases for having both. For things like a mutex or straight-forward resource cleanup - having a bunch of brain-dead defer statements adds little value and only bloats unnecessary line count. Let the resource type handle its own release/cleanup at scope close. Code is made sweet, succinct and safe.
• unscaled 1y ago
  I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style languages), labeled breaks, functions that are not globally public by default... It seems like this is written from the perspective of C/C++ and Java and perhaps a couple of traditional (dynamically typed) languages. On the other hand, the concept that makes Zig really unique (comptime) is not touched upon at all. I would argue compile-time evaluation is not entirely new (you can look at Lisp macros back in the 60s), but the way Zig implements this feature and how it is used instead of generics is interesting enough to make Zig unique. I still feel like the claim is a bit hyperbolic, but there is a story that you can sell about Zig being unique. I wanted to read this story, but I feel like this is not it.
  • deleted 1y ago
    [deleted]
  • neuvarius 1y ago
    [flagged]
    • debo_ 1y ago
      Are you ok?
    • JSR_FDED 1y ago
      I use Lua in 2025, it’s brilliant. By the way, so does everyone using neovim.
      • zimpenfish 1y ago
        > By the way, so does everyone using neovim. See also Roblox (and there used to be a whole bunch of game engines that had Lua scripting but I -think- most of them have switched to "NIH!" scripting engines?)
• hardwaresofton 1y ago
  It’s incredibly silly but I dislike zigs identifier policy. Mixing snake case and camel case for functions is cursed. That said, amazing effort, progress and results from the ecosystem. Bursting on the scene with amazing compilation dx, good allocator (and now io) hygiene/explicitness, and a great build system (though somewhat difficult to ramp on). I’m pretty committed to Rust but I am basically permanently zig curious at this point. [EDIT] “hate” > “dislike”. Hate is a strong word and surely I just need to spend some time writing zig and I’d get used to it.
  • ivanjermakov 1y ago
    Me too, so I don't follow a convention for private functions. Good thing is you barely interact with ones defined in dependencies. Prefix anf different naming conventions of C-imported libraries is not less annoying.
• eviks 1y ago
  The article doesn't answer the question, it's all just about "the basics of zig" (there is nothing cool manually editing environment variables on Windows with 8 labeled steps (and 5 preliminary steps missing)) and the actual cool stuff is missing: > with its concept of compile time execution, unfortunately not stressed enough in this article. indeed
• jandrewrogers 1y ago
  One of the things I like about Zig is that it pretty explicitly recognizes all the weird edge cases that exist in low-level systems code. A rather large cross-section of languages kind of pretend these cases don’t exist because addressing it would violate the aesthetic they are trying to achieve with the language. Nonetheless, these are real cases because low-level hardware and system behavior doesn’t care about aesthetics as might be expressed in a programming language. Even C++ didn’t fully repent from this sin until around C++17. I appreciate the non-begrudging acceptance of this reality in Zig.
  • sho_hn 1y ago
    Interesting, but really in need of some examples.
    • jandrewrogers 1y ago
      I would highlight `std::launder` as an example. It was added in C++17. Famously, most people have no idea what it is used for or why it exists. For low-level systems it was a godsend because there wasn’t an official way to express the intent, though compilers left backdoors open because some things require it. It generates no code, it is a compiler barrier related to constant folding and lifetime analysis that is particularly useful when operating on objects in DMA memory. As far as a compiler is concerned DMA doesn’t exist, it is a Deus Ex Machina. This is an annotation to the compiler that everything it thinks it understands about the contents and lifetime of a bit of memory is now voided and it has to start over. This case is endemic in high-end database engines. It should be noted that `std::launder` only works for different instances of the same type. If you want to dynamically re-type memory there is a different set of APIs for informing the compiler that DMA dropped a completely different type in the same memory address. All of this is compiled down to nothing. It annotates for the compiler things it can’t understand just by inspecting the code.
      • sho_hn 1y ago
        This is a good example because I'm familiar with it (I'm a C++ programmer; I haven't had occasion to use `launder`, but I read about it back then). But what's the Zig equivalent?
• jibal 1y ago
  I don't think Zig--which certainly is innovative in a number of ways--benefits from this sort of thing. Up front is a claim that it's "totally new way to write programs", but zero support is offered, and almost nothing else "meta" said about the language, other than a couple of sentences in the conclusion that are likewise inaccurate hype. I've programmed in many languages including Zig and it definitely is not a new way of programming. It imposes disciplines that are different from those of other languages, but the same is true of other languages. The final paragraph says "This is all quite surprising" -- why so? "and let one think that many advantages previously found only in interpreted languages are gradually migrating to compiled languages in order to offer more performance" -- sure, but Zig is hardly the first ... D and Nim both have interpreters built into the compiler that allow extensive comptime computation--both of those languages have far more metalanguage facilities than Zig, in addition to many other language features that Zig lacks--which is not necessarily a fault, as it aims for a certain kind of simplicity and close-to-the-metal performance ... although both D and Nim are highly performant (both have optional garbage collection, though Nim is more advanced in making GC-free programming approachable). One thing you can say about Zig though--it compiles like a bat out of hell. P.S. Another thing about Zig worth mentioning that came up in some comments is cross compilation. I don't think people understand how Zig is different and what an engineering feat it is (Andrew has a writeup somewhere of how it's done--it's shocking): If you install Zig, you can now generate executables for virtually any target with just a command line argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires recompiling the compiler and library to target a different architecture. Zig comes with precompiled libraries for a huge number of targets. I noticed a comment where someone said they love Zig but they've never programmed in it--they use it to cross-compile their Nim programs. (The Nim compiler has a C code backend, and Zig has a C compiler built in, so Nim inherits instant arbitrary cross-compilation to any target via Zig).
• Panzerschrek 1y ago
  Zig is not cool. It's a mediocre new language, missing key features needed for industrial development, like destructors or overall memory safety. But for some reason it's overhyped.
  • otabdeveloper4 1y ago
    It's ""simple"", so low-information, high-blogspam software developers have something to talk about instead of programming.
  • 59nadir 1y ago
    If you think destructors/`Drop` traits or the like are good then Zig was never for you. It has nothing to do with "industrial development", neither does memory safety. The irony is that memory safety as a concept definitely is overhyped.
    • Panzerschrek 1y ago
      Destructors aren't just good. They are one of the most important innovations in programming, since they reduce boilerplate and prevent many bugs. Developing a language without them means introducing more bugs which could be avoided.
      • pyrolistical 1y ago
        It violates one of zigs principle of no hidden control flow
        • kibwen 1y ago
          If exceptions count as hidden control flow because suddenly a function call can jump to a `catch` block, then defer absolutely counts as hidden control flow because suddenly the end of your function jumps to a `defer` block defined at an arbitrary point higher up. If Zig wanted to be consistent with its own philosophy, it would require some sort of keyword at the end of every scope to indicate that a defer was happening (and require multiple uses of the keyword to indicate multiple defers).
• nikitalita 1y ago
  This article made me want to beat up Zig.
• mk89 1y ago
  Some days ago I decided to look at Zig a bit more in detail. So I skipped the usual marketing and I checked why it could be an alternative to C or Rust. Could it be? It seems that (debug) allocators are a nice idea, however, it seems that they exist "somehow" already for C, so I wonder: why would you pick this language for your next low level program? They provide runtime checks, so you need thorough testing before you can spot use-after-free or so. It's very similar to the existing situation with c/c++ and the sanitizers, although they work a bit differently. So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators like hardened_malloc[0] instead of starting a new programming language? It would probably be less expensive in terms of time and would help fix existing software. [0]: https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc
  • astrobe_ 1y ago
    > So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators A partial answer is that part of low-level programmers avoid memory allocation and threads like plague. In some cases they are not even an option (small embedded programming, it's nearly as low-level as you can get before going hardcore for real with assembly programming), but when they can the keywords are efficiency, reliability, predictability, and simplicity : statically allocating in advance is a thing you can do because the product is typically with max specs written on the box (e.g. max number of entries in a phone book, to take a generic dumb example), and you have to meet these requirements even if the customer uses all of the capabilities to the max; no memory overbooking allowed, which is basically what dynamic allocation is, in a sense. > instead of starting a new programming language If I were to start a new low-low level programming language, I would basically just fix C's weak typing problem, fix the UB problems that only come from issues with long-gone processors (like C++11 finally did with sign encoding), "backport" some C++ features (templates? constexpr?), add a pinch of syntactic sugar and fix union types to have proper sum types. But probably I've just described D and apparently a significant chunk of C23.
    • uecker 1y ago
      Indeed, and if someone wants to help work on C, this is very much possible both on the compiler side or on the standards side.
• oezi 1y ago
  Unfortunately the article glosses too quickly over aspects which seem unique. For instance, I don't get what labeled breaks have to do with comp-time or why a labeled break was used in this situation over a normal function call: >>> Labeled breaks Zig can do many things in compilation time. Let’s initialize an array, for example. Here, a labelled break is used. The block is labelled with an : after its name init and then a value is returned from the block with break. >>> The article hasn't even talked about how the language decides what an open curly brace is causing.
• hamasho 1y ago
  > Zig for ( 0..9 ) |i| { } > C for (i = 0; i < 9; i++) { } I know an open interval [0..9) makes sense in many cases, but it's counterintuitive and I often forget whether it includes the last value or not. It's the same for python's range(0, 9).
  • jamiejquinn 1y ago
    I completely agree. One of Zig's big competitors, Odin, has a more explicit syntax for this where `0..<5` is an open interval and `0...5` is closed.
    • brabel 1y ago
      I think that comes from Ruby, right? I know Groovy is inspired by Ruby and has exactly the same syntax. EDIT: oh just noticed it's 3 dots in the close case... in Groovy it's just 2.
    • psnehanshu 1y ago
      I even forget which word means what, "open", "close"
    • thegeekpirate 1y ago
      Odin's even better than that—you can only use `0..<5` and `0..=5`, so there's never any ambiguity whatsoever.
  • reorder9695 1y ago
    Rust's solution to this is quite good, that's 0..9 and if you want to include 9 it's 0..=9, it looks a bit funny but knowing one with an = sign in it exists removes any doubt
    • mirsadm 1y ago
      Adding additional syntax to a language for this case seems bonkers to me. People can just write 0..10.
• jamiejquinn 1y ago
  The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare). While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refining them, and removing unnecessary ones seems in sharp contrast to the development of any other langauge I'm aware of. I'm no language historian though, happy to be challenged.
  • brabel 1y ago
    It seems pretty common to me?! Java is developed that way. So is Rust. And many others. What exactly do you see as different in Zig?
    • koeng 1y ago
      I don’t think Java and Rust were so ok with completely removing features. For example, in Zig 0.15 they completely overhauled the io, meaning all libraries now have to rewrite up usage. Just to make sure they did it right
      • otabdeveloper4 1y ago
        > Just to make sure they did it right Let me guess: they didn't, and now there is a third-party "right" way to do it. (We've been here before, many times.)
      • reichstein 1y ago
        Semantic major/minor version 0.15 means it's still in development. It's not supposed to be stable. Going from 0.14 to 0.15 allows breaking changes. Try making a similar change between version 5.0 and 6.0, with hundreds of thousands of existing users, programs, packages and frameworks that all have to be updated. (Yes, also the users who have to learn the new thing.)
      • kibwen 1y ago
• DeathArrow 1y ago
  >totally new way to write programs To me it seems like a better C but not at all unique since most concepts in Zig are already present in other languages. Zig is cool but not unique. And that is cool, too. Originality for the sake of originality doesn't add value in programming.
• deleted 1y ago
  [deleted]
• cyber1 1y ago
  The biggest advantages of Zig for me are that everything is explicit (no hidden features like overloads or implicit conversions) and that its metaprogramming is powerful, easy to use, and easy to understand.
• bjourne 1y ago
  Do you need pointer arithmetic? I think that's the one feature a modern C replacement should do away with. The other being support for arithmetic with unsigned types.
• m00dy 1y ago
  Why would I write in Zig instead of Rust ? Only meaningful comments here
• pjmlp 1y ago
  Author is apparently unaware of alternatives like Ada, Object Pascal and Modula-2, where most of those "innovations" were already available. It is kind of interesting that packaging the same ideas with a C like syntax suddenly makes them "cool", 40 years later.
  • materielle 1y ago
    I’m actually not a huge Zig person. But yes, avoiding arcaneness for the sake of arcaneness will earn you more users. A big success of Rust has nothing to do with systems programming or the borrow checker. But just that it brings ML ideas to the masses without having to learn a completely new syntax and fight with idiosyncratic toolchains and design decisions.
    • pjmlp 1y ago
      Or it is another example of younger generations unaware of our computing history, celebrating something that they think is totally new.
• arbitrandomuser 1y ago
  Zig structs are "modules" in themselves, apart from c like struct fields , they can have local variables, structs and functions declared and used inside of them . in fact files in zig are just structs !
• Raphael_Amiard 1y ago
  I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new. Also highly subjective but the syntax hurts my eyes. So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?
  • uecker 1y ago
    As someone who still thinks one should write C (so as a completely uncool person), what I like about Zig is that it is no-nonsense language that just makes everything work as it is supposed to be without unnecessary complications, D is similar, except that it fell into the trap of adding to many features. So, no, I do not really see anything fundamentally new either. But to me this is the appealing part. Syntax is ok (at least compared to Rust or C++). Having said this, I am still skeptical about comptime for various reasons.
  • pjmlp 1y ago
    It gets hyped by a few SV influencers.
  • audunw 1y ago
    It’s hard to do something that is truly novel these days. Though I’d argue that Zigs upcoming approach to Async IO is indeed novel on its own. I haven’t seen anything like it in an imperative language. What’s important is the integration of various ideas, and the nuances of their implementation. Walter Bright brings up D comptime in every Zig post. I’ve used D. Yet I find Zigs comptime to be more useful and innovative in its implementation details. It’s conceptually simpler yet - to me - better. You mention Ada. I’ve only dabbled with it, so correct me if I’m wrong, but it doesn’t have anything as powerful as Zigs comptime? I think people get excited about not just the ideas themselves, but the combination and integration of the ideas. In the end I think it’s also subjective. A lot of people like the syntax and combination of features that Zig provides. I can’t point to one singular thing that makes me excited about Zig
    • 1y ago
• blueredmodern 1y ago
  [dead]
• gethly 1y ago
  Why are people so obsessed with Zig when Odin has been stable, though not yet with official spec, for such a long time and used in real production for years? Is it just syntax preference or does Zig provide something amazing that I am missing? Not that I use any of them, I am not interested in manual memory management and i stick to Go. But I'm curious.
  • 59nadir 1y ago
    Zig has a lot of manpower behind it in comparison to Odin and this is one of the most important things for people, they see a proverbial crowd and that builds a lot more interest. With that said, here are a couple of things you have in Zig that you don't get in Odin: - Cross-compilation & cross-linking (more or less works): Odin doesn't do cross-linking. - Comptime; you can actually use it to effectively get Functors from ML, which means passing in interfaces to modules and getting compile-time generated modules back (structs in this case) - Error set inference; Zig can figure out the complete set of errors a code path can return and make sure you handle them, or bubble that exact set (plus your own errors) up. This comes with the caveat that Zig has no capability to attach actual data to the errors, so you have to side-channel that info if you have it. Odin doesn't do error inference apart from the type checking side of it, but does allow using tagged unions as errors, which is great. They still interact exactly as they ought to with the zero-value-as-no-error machinery. I didn't use comptime much when I used Zig, and I like tagged unions as errors much more than I value being able to cross-link, so I decided that Odin was better for me. Defaulting to zero-values and the zero-value being blessed in terms of language features didn't feel right to me before I started using it but now I can't really imagine going back to not assuming the zero-value being there.
    • gethly 1y ago
      Thanks for the info. I'm curious to see what people will do when Jai will finally be released next year. So far, Rust has been gaining a lot of traction, although wit ha lot of controversies attached to it. Zig seems to be doing well but the lack of progress towards v1.0 after all those years is quite concerning, making it looks more and more like a toy project rather than something serious. Odin seems to be flying under the radar of most people a bit too much. Jai will have John's name behind it and I am hearing a lot of praise from insiders(people in the beta program). As I said, I have no use for such languages but if i'll do in the future, I'd like to have a clear choice rather than myriad of languages in various stages of development, all trying to do the same thing.
• swiftcoder 1y ago
  Man who has only ever written C++ discovers other programming languages exist, news at 11
• BiteCode_dev 1y ago
  Top comment: this article sucks. Then HN proceed to keep the article at the head of the front page for the day.
• kopollo 1y ago
  Why a new lang every day?
  • gabrielgio 1y ago
    Because people like to have fun.
• nyfresh 1y ago
  I am surprised Native SIMD support is not mentioned in an article with this title. Not sure if it could be applied to the sudoku example he used.
• beginnings 1y ago
  zig is not cool at all, its ugly as sin, and has zero use case other than mingling with legacy c code, and who in their right mind wants to be doing that its a hipster language, absolute insanity to use it when rust exists unless you have that very specific c related slave work to do
  • estebank 1y ago
    > its ugly as sin Uncalled for and subjective. Certainly plenty of people call Rust's syntax ugly. Discussing syntax and not semantics is a waste of time. > has zero use case other than mingling with legacy c code So it has a use case? > who in their right mind wants to be doing that Some people have to. > absolute insanity to use it when rust exists unless you have that very specific c related slave work to do Some people do. What's the need for such emotionally charged language in your comment? I have my own reasons not to use Zig at this moment. I want enforced memory safety and am waiting on 1.0 to see what the language finally looks like. Until stabilization I certainly won't be using it in production. But that doesn't mean the project is meritless, that experimenting with language features before then is wrong, that making a language suitable for specific niches is a bad idea. I don't see Zig as a replacement for tools that would have been written in Go, Java or C#, and I would rather we had less memory unsafe software out there, but it is a clear step function ahead of C. Just like I and many others spend a lot of time trying to make Rust the best it can be, their team is doing the same.
• jsiepkes 1y ago
  While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/ https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://www.cisa.gov/case-memory-safe-roadmaps https://www.cisa.gov/case-memory-safe-roadmaps
  • 1718627440 1y ago
    This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.
    • xiffle 1y ago
      Tanenbaum was right, the future of the Linux kernel is dire, and it's been a huge setback to operating systems research in practical terms. Fortunately, vendors are gradually moving away from Linux, having been hamstrung by its failures. Google is planning to move to a capability-based microkernel in the coming years for Android and ChromeOS, and Huawei has already done so with HarmonyOS. In a hundred years, Linux will be a footnote in computing history.
      • 1718627440 1y ago
        Irregardless of whether this is true, it has not prevented adoption of Linux.
        • xiffle 1y ago
          And McDonalds is one of the most popular restaurants worldwide despite the questionable food quality.
    • 1y ago
• deleted 1y ago
  [deleted]
• awesan 1y ago
  A lot of comments here kind of miss the point, but that's to be expected because you can only really get it when you have the experience. Like hearing a description of a painting will not give you the same emotion as looking at it yourself. Zig has completely changed the way I program (even outside of it). A lot of the goals and heuristics I used to have while writing code have completely changed. It's like seeing programming itself in a new way.
  • fuzztester 1y ago
    Examples?
• portly 1y ago
  A super cool feature are labeled switches: https://codeberg.org/ziglings/exercises/src/branch/main/exercises/108_labeled_switch.zig https://codeberg.org/ziglings/exercises/src/branch/main/exer... They allow for super ergonomical coding of state machines, which is a lot of fun.
• coolThingsFirst 1y ago
  How on earth is it unique to compile code for different architectures? This is a solved problem since the 80s. It basically looks like C with different syntax, im also not convinced the 0…9 implicit range is better for iteration - i prefer it explicitly for lower level languages.
• SonnyTark 1y ago
  This is a very confusing blog post. I found myself looking for ChatGPT markers because it doesn't make sense to say: omg zig is so much cooler than C here's why, then start listing the absolute basics of the language that are identical in most modern languages without any actual reflection why writing the same thing in a different syntax somehow makes zig superior?
  • aib 1y ago
    You're absolutely correct! </s> The "how to modify an environment variable" bit and the bin-dec-hex table made me feel the same way. Then I saw the part explaining how to check for duplicates in a row... I'm struggling to understand the point of the article. Testing a text generator?
    • joaogui1 1y ago
      Also bizarre that it got to the front page of HN while being so low quality :/
      • dustymcp 1y ago
        Well i think that is why it got there people really love hating :)
  • raldu 1y ago
    Titles get the headlines.
    • antegamisou 1y ago
      Honestly this (the fact it is being massively upvoted) looks a lot more like paid promotion. Not the first time and not the only example of submission btw.
    • muragekibicho 1y ago
      I've learnt this the hard way. The most important thing is to get you to click. Sometimes I'll first iterate over the title before even writing on substack.
• tamnd 1y ago
  Zig is so cool, but C is cooler. I like how Zig feels clear and simple to start with. I like that it gives one toolchain and makes cross compilation easy. I like that it helps people see how systems programming can feel approachable again. I also like that C has done these things for many years. I can use different tools, link libraries, and trust that it will still work. I can depend on standards that keep improving while staying familiar. I think Zig is exciting for what it adds today. I think C is cooler because it has proved itself everywhere and still runs the world.
  • grayhatter 1y ago
    I've used for well oven a year now, and I identify with this comment... well no, but I used to. In between Zig, and another language I enjoy was Python, and it was breath of fresh air to come back to the C style that I know and love within Zig. I would have said exactly this, when I first started writing Zig. Today, Zig is so much better than C. I used to refer to Zig as an improved version of C. But I don't anymore. C may have come first, but chronological roles reversed. If Zig is a programming language, than C is a toy trying to copy Zig's functionality and usability. Calling C easier to use in a cross platform context is absolutely insane. If I was only concerned about $HOST I would consider using C. Today, when I might want to copy a binary to literally any other system, I wouldn't even consider C. Zig wants code to work. C wants code to compile. There's a stark and critically important difference between the two. > I think Zig is exciting for what it adds today. I think C is cooler because it has proved itself everywhere and still runs the world. I couldn't have put it better myself, the only thing C has over Zig is inertia. But I wouldn't consider that a selling point....
    • tamnd 1y ago
      Have you tried C23, especially its new Unicode support? It really surprised me after returning to C more than ten years later. You can now write wide and UTF-8 string literals directly: char8_t* s = u8"こんにちは"; char16_t* t = u"Привет"; char32_t* ustr = U"你好"; It just works across compilers, no special libraries or hacks needed. C still feels like C, but cleaner, safer, and more consistent.
• api 1y ago
  Zig doesn't seem like a bad language, but I also don't see anything to make it hands down better than Rust for systems programming. So it kind of fails my "why yet another language?" test. I don't think another language can be justified by marginal improvements. Rust passes that test because it's categorically better than C and C++ in several ways: much better type system, safety, better modules and code reuse, etc. It's complex, but as far as I can tell most of its complexity is required to offer its level of safety guarantees in a pure systems language without a garbage collector or any kind of true dynamic typing. To make a safe systems language you need to have a very rich type system that can prove safety across a wide array of situations. Either that or you'd have to go to the other far end of the simplicity-complexity spectrum and have a language with virtually no features, which would result in very verbose code and probably a lot of boilerplate. Zig's coolest feature to me seems like "comptime" and the lack of a weird macro side-language, which is one of Rust's anti-features that feels bolted on. Don't make me learn yet another language. Of course sophisticated macros in Rust are usually instead written in Rust itself via procedural macros, but that is more unwieldy than "comptime." Still not enough to justify a whole new language and ecosystem though. Again: don't make me learn yet another language unless there's a big payoff.
• philippta 1y ago
  > The @breakpoint built-in Inserting the literal one byte instruction (on x86) - INT 3 - is the least a compiler should be able to do.
• novabridge 1y ago
  Why is this article even on hacker news?
• quincepie 1y ago
  I think what sets Zig apart from other low level languages is how easy it is to navigate a Zig source code. I was discouraged at the time (things probably changed now) when the best source for documentation was "read the Zig's source code". But I was impressed by how easy it was to find what I needed. while this is due to Zig maintainers' code quality, I think a large contributing factor is the choice of syntax. As an exercise, try navigating a C, C++ and any other language source code without an IDE or LSP. things like: - "Where did that function come from?" - "What and where is this type?" what do you have to do to find that out? due to the flexible ways you can declare things in C, it may take you a lot of steps to find these information. even in search, a variable and a function can share the same prefix due to the return type placement. hence why some people prefer function return types in a separate line. Even with languages like Rust for example, finding if a type in a function parameters is an enum or struct and finding its definition can require multiple steps like search "enum Foo" or "struct Foo", in Zig i can search "const Foo" and i will immediately know what it is. while i do hope that C gets defer and constexpr functions in the next standard or maybe better generics or enums, Zig syntax is much better to work with in my opinion.
  • cyber1 1y ago
    I also hope that WG14 eventually adopts successful features from Zig, such as comptime, and reduces the use of ugly macros and _Generic.
• throwawaypath 1y ago
  Never heard of Zig, but I'm an avid user of Ghostty. I had no clue it's Zig under the hood! That is so cool!
• hoppp 1y ago
  Yeah, big fan of zig here Btw it's so much easier to add an environment variable in linux, I haven't used windows since 2007 so it was interesting for me to see how you do it there. Clicking on edit buttons to find that menu ? Nah, I don't do that here :)