20 ms·

Zig is hard but worth it

401 points by signa11 3y ago

mgkimsal 3y ago
https://archive.is/cMm11 https://archive.is/cMm11
thadt 3y ago
> Crucially, there is basically no documentation for the standard library except for the source code itself. From the viewpoint of someone learning about a new language, I find the accessibility of the standard libraries goes a long way toward helping me understand how things fit together. It is a first stop to see how experts in the language use it. Browsing through the standard libraries of languages like Zig, Go, and Python - they're usually well-documented and readable enough to be a tutorial, even before you've dug into learning it. Others (Rust, C++) are a bit more, ah, technical for the novice.
- Vecr 3y ago
  Rust has the standard library documentation at https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/ or on your local computer, if there's really nothing like that for Zig I think that's a problem. Are you sure there's no `info zig` or something like that?
  - sciolistse 3y ago
    There is https://ziglang.org/documentation/master/std https://ziglang.org/documentation/master/std but it's not always been correct, and the descriptions are lacking. The new one should hopefully fix that. Personally I've never had an issue reading through the source for zig std, and if your editor supports it you can just 'go to implementation' on most things. Hopefully the code remains relatively readable since I find it preferable to see the actual code + some basic tests rather than trying to navigate those documentation sites.
- tialaramex 3y ago
  I certainly wouldn't recommend trying to figure out C++ by reading either of the three major C++ standard libraries.
- TwentyPosts 3y ago
  Afaik Zig has the issue that basically everything happens on the Discord server, where it can't be indexed via search engines, or found by anyone who wants to have a quick question answered. This would be "fine" if the standard library and language were much better documented, but it isn't, and it's still ripe with bugs. In other words, you're forced to use the Zig Discord server if you want to find answers to any simple questions, and this is (sadly) not obvious at all to newcomers to the language.
  - girvo 3y ago
    This is true for Nim as well, in that most of the discussion is on the Discord/Matrix server. I’m not a fan personally, at least IRC was easily archived and searchable in practice. I really dislike how Discord has become “forums in the 2020s”
    - Tiberium 3y ago
      This is not actually true for Nim - almost all Nim Discord channels are bridged to different IRC channels, see https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats
      - girvo 3y ago
        Oh that's nice, I thought the IRC bridge had been left to languish. Good to know I was wrong!
  - scns 3y ago
    The new Zulip version can make chats accessible from the outside. In the thread about it someone wrote OSS Projects should switch to it.
pron 3y ago
> there’s not a direct correlation between the slimness of a language’s syntax and ease of learning That's absolutely true, but (the standard library aside) the "syntax" -- or, rather the syntax and core semantics -- of a programming language are arbitrary axiomatic rules, while everything else is derivable from those axioms. So while it is true that a small language can lead to a not-necessarily-easy-to-learn overall programming experience, it is the only arbitrary part, and so the only part you need to memorise (or consult the documentation for when dealing with some subtlety you may have forgotten). So a smaller language reduces the need for "language lawyering" after you learn it. Some languages (e.g. lisps) are deceptively small by relying on macros that form a "second-order" language that interacts with the "first-order" language, but Zig doesn't have that. It has only one language level, which is small and easy to memorise. But yes, Zig is a bigger language than C, but a far smaller language than C++. What's amazing, though, is that C++ is strictly more expressive than C (i.e. there are programs that could grow exponentially faster in C than in C++, at least without the help of C macros), but Zig is as expressive as C++ (i.e. program sizes may differ by no more than a small constant factor) while being much closer to C in size, and it achieves that without the use of macros.
- the_duke 3y ago
  I'm not a Zig expert, but I have a different take here. Zig has comptime, which is essentially a compile time macro written in the main language and with type reflection capabilities. They can introduce complex behaviour and fail in very cryptic and unexpected ways, which results in an experience very similar to macros or C++ template literals.
  - pron 3y ago
    The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of symbols like templates or macros, and so are easier to diagnose (you get a regular stack trace for one). There is also another interesting difference, albeit a theoretical one. Zig's comptime is what's known in formal languages to be referentially transparent (it basically means that you cannot distinguish between two otherwise identical objects that differ only in their reference name) while macros are not. Because referential transparency is strictly less expressive than "opacity" (but it's also simpler!), it's surprising that so many practical use cases for macros can be addressed with the less powerful (but simpler and much easier to debug) comptime. That's quite a discovery in language design. While other languages also have comptime-like constructs, they also have other complex features that have made it hard to see just how powerful something like comptime alone can be.
cies 3y ago
From the article: > Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective. I'd argue both are subjective, or with a better word: relative. I'd say Zig is easier and simpler than C in almost all regards. The article does not specify what Zig is compared to in order to make these statements. Probably the author had C in mind, but that was not explicitly mentioned.
bakuninsbart 3y ago
Where do you guys see good use cases for Zig? I'm intrigued by the language but don't really have any good ideas on where to try it out. I thought about trying it out in as small data engineering project, but I'm not sure if language support is sufficient for the kind of tooling I would need eg. Database adapters.
- jgalt212 3y ago
  I've been thinking about using it for Python hot paths. I'm not smart enough to write rust (at least without limitless supplies of aspirin). And I'd like to avoid C for all the obvious reasons.
  - Dowwie 3y ago
    Try Elixir.
- chjj 3y ago
  Do you maintain any C projects? Personally, I tried using zig for its build system (which can also compile C and whose build files are written in zig). One of the benefits of this was easy cross-compilation to all major platforms. It might not be a _real_ use-case or anything, but writing a `build.zig` file for an existing C project might be a good way to at least dip your toe in the water.
- pjmlp 3y ago
  In what concerns userspace, I don't see any good case, if I want a better C, without much features, I rather stick to Go even if I dislike some of the design decisions. Or D, Nim, Swift, OCaml, Haskell, AOT C#, AOT Java,... If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust, not a language that still allows for use-after-free errors. Maybe it is a good language for those that would like to have Modula-2 with a C like syntax, and metaprogramming capabilities, and are ex-Objective-C developers.
  - distcs 3y ago
    > If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?
jsheard 3y ago
I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.
- bodge5000 3y ago
  I'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern
  - jsheard 3y ago
    Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.
    - felixgallo 3y ago
      as a long time game dev, I actively don't want operator overloading. That's some spooky action at a distance nonsense. I'm not sure I have seen a codebase that involved operator overloading, either, and I've worked in or near a good quantity of well-known titles.
      - jsheard 3y ago
        There's no accounting for taste, but the two major publicly available engines (Unreal and Unity) both use operator overloading in their standard math types.
      - Taywee 3y ago
        You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.
helen___keller 3y ago
My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages. Aside from lack of community I’d say the biggest nuisance is error handling in nearly everything including allocations. I get that allocation can fail but the vast majority of programs I write, I just want to panic on an allocation failure (granted these aren’t production programs…) Edit: in retrospect, allocator error handling verbosity is probably necessary due to the power the language gives you in choosing allocators. If I use the general purpose allocator then my edge case is PC out of memory; if I use a fixed buffer allocator, a failed allocation is a code bug or a common error case, so we might want to handle the failed allocation and recover
- kuroguro 3y ago
  I suppose you could write a few line wrapper that panics :) But yeah, most of the time I don't even want to think which allocator to use let alone handle it's errors.
  - eatonphil 3y ago
    This is basically what I've come to do in the Zig scripts I write at work. It took a bit of getting used to when I joined but we agreed as a team to have all meaningful scripts written in Zig not bash (for one, bash doesn't work on Windows without WSL and we need to support Windows builds/testing/etc.). It makes about as much sense as any other cross-platform scripting option once I got used to it! Some examples: Docs generation: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/docs_generate.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c... Integration testing sample code: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/integration.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c... Running a command wrapped in a TigerBeetle server run: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/run_with_tb.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
nickelcitymario 3y ago
> [...] easy things seem easy primarily because they are familiar. Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective. This should be printed out as a large poster in every office.
- erichocean 3y ago
  Rich Hickey has done more to popularize that idea in recent years than perhaps anyone else. [0] In a lot of ways, Zig is to the systems programming space what Clojure is to the information processing space. If you have 5+ years experience, you want simple, not easy. Both languages deliver real advances on that promise in their respective domains. ---- Back to the article, perhaps not coincidentally, the product my startup is developing is written primarily in Zig (language runtime), Clojure, and an in-house Forth/Factor/Joy derivative for user-level scripting. I guess I really do care about simplicity… [0] Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
ldelossa 3y ago
I'm surprised that the reason I'm mostly interested in Zig is not mentioned. This is C interop. I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome. Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.
- workethics 3y ago
  Not only that, but zig makes linking against old glibc versions easy. For example, to make an x86_64 linux build linked against glibc 2.9 when using zig build all you have to do is pass: -Dtarget=x86_64-linux-gnu.2.9
  - GordonS 3y ago
    Damn, that's a magnificent feature! Maybe I should have another look at Zig...
  - beefcafe 3y ago
    This is a killer feature for CTFs/OSCP/etc and why I started using it.
  - TDiblik 3y ago
    Hi, why is this feature interesting/important? (Coming from [uneducated] webdeveloper with interest for systems/embedded programming)
- ziml77 3y ago
  The thing that's espcially nice about that interop is that Zig includes its own C compiler. That eliminates the pain of having a build script locate an installed C compiler and figure out what options should be passed to it.
  - lost_tourist 3y ago
    Why would I use zig c compiler in place of gcc or clang? Mainly for zig interactivity or does it have some advantage other than that over the aforementioned compilers?
latch 3y ago
I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack of package manager, etc. For an insider living and breathing Zig, not only aren't these huge challenges, they aren't really "Zig" - they are just transient growing pains. For someone getting started though, the current state of Zig is Zig. I wish Zig had a polished package manager (there's one in the current development branch, but you don't as much use it as fight it). They could then move some of the less polished code into official experimental packages, helping to set expectations and maybe focus the development efforts.
- zoogeny 3y ago
  I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0
  - arp242 3y ago
    Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.
    - ReleaseCandidat 3y ago
      > I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.
frankjr 3y ago
I've been playing with it and so far but I'm more impressed with their build system rather than the language itself (it seems to be way more flexible and simpler than alternatives which is pretty rare). They did however get the module system right. You can just organize the file structure in any way you like. I hate Rust's "everything is a single module" system with passion.
- mike_hearn 3y ago
  How do you find it simpler? From taking a quick look it appears to just be an API for invoking build steps, and the build script is itself a Zig program. I ask if it's really simple, because the JVM space went in the same direction with Gradle (build script = program) and by the time it gets more sophisticated that can turn out to be pretty painful. In particular, IDEs struggle to get the information they need, scripts can become highly complex, and there are various other problems.
  - pjmlp 3y ago
    Gradle is Ant reinvented, by those that didn't learn why we moved into Maven.
jeroenhd 3y ago
I like Zig as a concept, but every time I've tried it, the toolchain lacked good IDE and debugger support. I've tried some plugins half a year ago but they either didn't work reliably or they missed important features. I'm personally sticking with Rust until the day comes that I can just add a VSCode/Clion plugin that'll give me an interactive debugger with full autocomplete support without fiddling around too much. There's a lot to like with Zig, despite its unconvential syntax and some language decisions I personally disagree with. The language is still in development but it's very promising and I'll definitely try to learn it before it reaches that magical 1.0 release.
- jcalabro 3y ago
  I've definitely had a good experience writing Zig in VS Code with the CodeLLDB extension on Linux [0] and the Microsoft C++ [1] one on Windows. It's also got the Zig extension which comes with the Zig language server [2]. [0] https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb https://marketplace.visualstudio.com/items?itemName=vadimcn.... [1] https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=ms-vscod... [2] https://marketplace.visualstudio.com/items?itemName=ziglang.vscode-zig https://marketplace.visualstudio.com/items?itemName=ziglang....
thih9 3y ago
> "I learned Zig in a weekend! … Six hours! … 6µs!" say the blissful lizards. I don’t get it; is this a reference? Could someone explain?
- tylerscott 3y ago
  IIRC the mascot is a lizard so here the comment is portraying a Zig enthusiast keen on promoting the ease of learning Zig as a lizard. That was my take.
rayiner 3y ago
Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a killer feature that justifies not just using C.
- helen___keller 3y ago
  If we’re comparing C to Zig I’m not sure what memory safety even needs to be mentioned for. For C to Zig there’s plenty of reasons one might prefer Zig. For memory safety obviously you might opt to choose neither.
  - rayiner 3y ago
    In a vacuum, one might prefer Zig. But given that everyone already knows C and the ecosystem is so highly developed, it takes a gamechanging feature like Rust's memory safety to make an alternative language attractive (beyond a "this is cool" project--which I totally support).
    - helen___keller 3y ago
      That is probably why Zig has such a focus on seamless C interop. There’s a good thread in these comments talking about this. Regardless, point taken. You’re more or less describing the internal fear I have (mentioned in another thread) that if I dedicate time to a nontrivial Zig project I will regret it if/when there’s no Zig community in N years
    - alwaysbeconsing 3y ago
      I haven't tried Zig, but "all the things you like about C plus better versions of most/all of the awkward bits" seems like a reasonable value proposition. Especially since the compiler can apparently let you use C painlessly alongside your Zig -- enabling incremental rewriting.
cynicalsecurity 3y ago
Wait, it's a real language? I thought it was a sarcastic article about an imaginary language called zig making fun of hipster languages desperately trying to replace C/C++.
TaupeRanger 3y ago
Maybe a few years ago it would've been "worth it". But with LLMs coming to swallow up all coding tasks and turning programmers into prompt engineers within a few years time, I can't see it being "worth it" any more.
- Taywee 3y ago
  You still need to understand the code you are generating, testing, and debugging. LLMs don't replace a need for more expressive programming languages.
- mr_00ff00 3y ago
  I don’t want to make assumptions, but have you tried systems programming with LLMs? A few years and everyone will be prompt engineers is laughable. I hope I can actually use it productively for more than unit tests in a few years.
sarchertech 3y ago
I tried Zig for a few weeks but ended up choosing Odin for a game dev side project I’m working on. Odin feels a lot more high level, but still gives you low level control when you need it.
- 59nadir 3y ago
  I've settled on Odin as well and I think it's currently way ahead for game development than Zig is. Even for other things I'm currently more likely to write it in Odin, despite writing Zig from 2019 to 2022. The reasons really come down to error handling being better in Odin overall with payloads being attachable to errors as well as the context system and zero values making it relatively painless to really only talk about the things that need talking about and letting the rest be unsaid. There are also several similarities: Custom allocators as part of the ecosystem and language, no RAII, easy ways to propagate and handle errors the right way, tagged unions with table stakes like exhaustiveness checking. I think Odin and Zig have some fundamental differences (and plenty of similarities) and when trying Odin out I was surprised to find that I preferred the Odin way overall. For gamedev stuff Odin wins due to a few things; swizzling on a code level is super nice, array programming built-in to the language, vendor libraries shipped with the language that allow you to just get going almost no matter what you're doing, and so on.
  - truckerbill 3y ago
    I want to invest in Odin but I see the velocity and growing mindshare that Zig has and I wonder if it's not better to settle for that. Also how do you find the compile times?
    - 59nadir 3y ago
      I think by the time I have a massive project where compile times could actually hurt the newest endeavor with compiling to an intermediate form, etc., will already be released so it's likely that I'll dodge that entirely. For what it's worth I haven't found any language constructs that seem to make the compile time grow considerably, so I think the risk of adding a library and suddenly being faced with massive compile times is fairly low in comparison to some languages. With that said, I'm only using the core lib and vendor libraries. JangaFX by way of GingerBill reports that their 200kloc EmberGen[0] project takes 5 seconds to compile: > On my old machine, it took 5 seconds, and now it takes 2.2 seconds on my new machine. Before some paths in the compiler had multithreading added to them that number was 15 seconds for the same project. As far as I know both of these numbers are for unoptimized builds, i.e. development builds.
stared 3y ago
What are the use-cases in which it might be worth switching from Rust to Zig?
- logicchains 3y ago
  When you need to be very careful about memory allocation and use various custom allocators for stuff, and you don't care too much about memory safety. Rust makes working with custom allocators somewhat painful, in exchange for safety, so if you don't need the safety, no point going through that pain.
  - notfed 3y ago
    What kinds of programs don't care about memory safety?
    - nyberg 3y ago
      Compiler enforced memory safety*. Games in particular tend to have their own allocators and memory management schemes which don't play well with global allocators. Using memory pools, frame (arena) allocators, system specific memory management, and so on. Handling memory in a very systematic way (avoiding the "malloc everywhere" anti-pattern) where ownership is clearly tied to systems and handles (integers (maybe with metadata)) passed instead of pointers helps keep this all sane. That and you can still throw a GC/Ref counting at things which have non-linear lifetimes if needed but there's no need to do so globally. One-shot programs also don't always need it as they're often fine with a less sophisticated scheme of arena allocation or reusing memory by resetting temporary buffers. You also have the option to classify pointers if you absolutely must pass them with similar techniques as https://dinfuehr.github.io/blog/a-first-look-into-zgc https://dinfuehr.github.io/blog/a-first-look-into-zgc.
- epage 3y ago
  matklad, of rust-analyzer fame among many other things, wrote up their thoughts on Zig: https://matklad.github.io/2023/03/26/zig-and-rust.html https://matklad.github.io/2023/03/26/zig-and-rust.html I've seen some put it as "zig is good when `unsafe` heavy code". Personally, even when writing life-or-death software, allocation errors were too much of a pain to deal with and much prefer Rust's approach for 99% of software. The question is if another language like zig provides enough value to justify existing for that 1% of use cases (all numbers made up :) ).
jasfi 3y ago
Nim isn't hard, it just has a small community.
- anta40 3y ago
  I haven't done any production-level stuff with Nim (still learning it), I think overall it's a nice language (I also like Python & Pascal). If your goal is applying for job, Go is obviously a better pick.
michaelcampbell 3y ago
I don't know Zig so I can't comment much on the content, but the author's writing style I enjoyed immensely; enough to make me want to pick up Zig for fun. I do have some C background, albeit decades ago, so maybe I'm in the right spot for it.
ok123456 3y ago
One annoying thing I ran into when trying zig is they don't distribute debs any more for Debian distributions. They just tell you to use a snap. I don't have snap, and don't want it. Compiling it requires the latest llvm toolchian (16), which is only realistically going to be available as a package if you're on a bleeding edge distribution.
- pacaro 3y ago
  I understand this, but haven't found this to be an issue personally. I just download the pre built tarball, expand it, make sure that /opt/zig-latest symlinks to the right folder, and setup path That's more work than apt-get install for sure, but not so much more
  - hellcow 3y ago
    You can also use something like zigup to make fetching the latest master/managing multiple versions easier.
- netule 3y ago
  Zig's in the process of getting added to the mainline Debian repositories: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 Hopefully, this process will continue soon as the bug seems to be getting a bit stale.
- eatonphil 3y ago
  What's wrong with downloading the binary? curl + mv + chown should do it?
- AndyKelley 3y ago
  let me clarify some facts. 1. we never distributed debs for debian distributions. I have, however, been patiently collaborating with Debian maintainers with regards to the zig ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 2. we don't tell you to "just use a snap.". Please see https://github.com/ziglang/zig/#installation https://github.com/ziglang/zig/#installation 3. we tag releases soon after llvm tags releases for the convenience of package maintainers. Distributions with LLVM 14 can package Zig 0.9.1; distributions with LLVM 15 can package Zig 0.10.1, etc.
askkk 3y ago
In new last version 0.10.1 it seems that for is not working with two arguments? const std = @import("std"); const expect = std.testing.expect; test "for basics" { const items = [_]i32 {4,5,3,4,0}; var sum: i32 = 0; for(items, 0.. ) |value,_| { sum += value; } try expect(sum == 16); } ubuntu 22.04, snap zig version 0.10.1 , zig test 1.zig produces: 1.zig:7:12: error: expected ')', found ',' for(items, 0.. ) |value,_| { ^ Edited: To update, I tried snap, but using snap install --classic --beta zig is a security risk because it can change the system and is not sandboxed.
- EscapeFromNY 3y ago
  For loop syntax was changed since 0.10.1. Zig 0.10.1: for(items) |value| {} for(items) |value, index| {} Zig 0.11-dev: for(items) |value| {} for(items, 0..) |value, index| {} for(as, bs, cs, ds, 0..) |a, b, c, d, index| {}
KingLancelot 3y ago
[dead]
LispSporks22 3y ago
> Only time will tell if comptime is the "greatest thing since sliced bread" or not. Common Lisp user here. Am I missing anything that Zig has in the compile time department? edit: Also, does the code in the comptime block have to be valid Zig?
- kps 3y ago
  It only has to be syntactically valid (parseable).
- kllrnohj 3y ago
  Personally I think comptime is a questionably design and is something both Rust & C++ did much better. In C++ branches that don't have to "compile" are explicitly marked as such with `if constexpr`. In Rust you've got macros that are also explicit with required `!`. In Zig any branch can be a ticking code rot time bomb, just like it was with C #ifdefs. It's better in Zig in that it at least has to parse and so you've got fewer blatant problems, but the category of problems of "I flipped DEBUG from `false` to `true` and now I have dozens of build errors to go fix" is still there. And you really don't have any warning signs other than "this is branching on something that might be known at compile time" But honestly that's also my general impression of Zig as a whole. It's very definitely a "better C", not something that's necessarily good/competitive with the broader state of the ecosystem. It's like a love letter to C, completely with many of the same general problems that C is known to have and that other languages have addressed.
Decabytes 3y ago
Zig is not my favorite language to program in, but I think it's focusing on a lot of the right stuff. 1. Easy Build System 2. Drop in Replacement for c/c++ compiler (zig cc) 3. Easy cross compliation 4. Single executable compiler 5. Package manager 6. Debugabillity It's the sort of developer focus that has a huge impact especially when you are doing it for more than just a hobby. Crystal, another language I love, is weak in this area. No tree sitter, No tier1 windows support, Major libraries like the Lucky Framework that don't build on Windows, a buggy LSP etc. Don't get me wrong I love the language, and I will continue to work in it, and all of these things are in various states of progress, but it's already at 1.8 and some of these issues haven't been ironed out yet. I'm not just armchair complaining, I know these are hard, and I will contribute once I am more familiar with the language
jksmith 3y ago
Is this a writeup about Zig, or any Wirth language written 50 years ago? Asking for some Modula2 OG.
parasense 3y ago
The main take away is: > Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior. Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the point here is the idea of undefined behaviour is tied to portability on some levels, and isn't just some purely academic idea about the compiler or abstract syntax trees. So I'm concerned about the potential over-zealous prejudice against undefined behaviour, but I think we can all agree deterministic software is better than otherwise. The catch is that sometimes UB is deterministic, and yet dares to not be idiomatic.
- Symmetry 3y ago
  Assuming that bytes are 8 bits long or that negative numbers are represented with two's complement is a lot less dangerous these days than it was when C came along.
- pklausler 3y ago
  Ironically, C is now way more portable than modern Fortran is. The Venn diagram of feature portability across the 6 or 7 actively-maintained Fortran compilers is very messy.
- kps 3y ago
  C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.
  - jsmith45 3y ago
    Yeah. In hindsight for a fair bit of it, it could have been sensibly changed to implementation defined behavior, or to constrained unspecified behavior. (Constrained such that people know what the possibilities are, but the compiler need not document its choice, and might not make the same choice in all circumstances. The latter could allow for scenarios where letting an optimizer do the faster thing when detectable, and what the hardware natively does otherwise, for example. Obviously still a potential footgun, but less of one than full undefined behavior).
_8j50 3y ago
Everything is hard when you first learn it. If you find it easy, that's only because you don't have to learn part of it because you learned the concept in a different language. Even learning to count was hard when we were small children. A better measure IMO is how long it might take you specifically. For example, Rust is much easier for me to learn than Haskell because I have never coded in a functional language before. Golang was very easy to pick up on. I never took time to learn python and powershell, I just kept referencing existing code and googling for examples because they were both mostly familiar languages with a different syntax.
galaxyLogic 3y ago
Love the picture. People often say how easy something was for them. They are saying they are a very capable, smart person. Would you rather hire someone for whom everything is easy, or someone for whom things seem difficult? In other words saying they learned something fast or that something is easy for them, is at least partially self-promotion. So claims of how easy something was for them it have to be taken with a grain of salt. The interesting thing for the rest of us is WHY something is easy, or difficult. That would be helpful for others to know. This article is just that, it tells us why Zig can be difficult. What to look out for.
codedokode 3y ago
I don't know anything about Zig except that it is a low-level language. Can someone please explain how it is better than Rust?
iskander 3y ago
Is there anything akin to Maturin for Zig? I would love to use it as an extension language for Python.
Alifatisk 3y ago
May I ask what the hype is with Zig? What makes it so attractive? Is it the performance? The easy interop with C? The ease of controlling the memory allocation?
WhereIsTheTruth 3y ago
The issues I have with Zig are similar to the ones I have with Rust, the syntax.. I will never get used to it, I find it tasteless and non-ergonomic But, I manage to set it aside because it provides enough benefits, I mainly use Zig as a toolchain to crosscompile my libraries.. and write some helper externs Hopefully they manage to improve and ease out the syntax by 1.0, I have hopes
- jadodev 3y ago
  Have any examples of syntax you find tasteless? Things in Zig that feel ergonomic to me: comptime params > separate generic args; ptr.* > *ptr; optional pointers > possibly null normal pointers; separate syntax for slices, arrays, & pointers > 1 syntax for ptr & arrays.
  - WhereIsTheTruth 3y ago
    var t: ?i32 = null; if (t) { t +=1; } This for example doesn't work, you have to capture, many little things like that that stacks up and ends up creating a non-ergonomic syntax No for loop, so you have to do multilines things like, and now you meet a new : construct, this pseudo for loop now looks confusing to look at var i: i32 = 0; while (i < 42) : (i+=1) { } Then constant casting between integers, and also floats.. also no operator overload for the math types etc.. Also not a fan of the pointer difference between [] * [:0], too much different nitpicking that makes iterating slow and painful, I understand the benefits, but the way it's done is not enjoyable, at least to me That's just whats on the top of my head, it's been a while I haven't wrote Zig code so I may be remembering wrong
erhaetherth 3y ago
> easy things seem easy primarily because they are familiar This is also why I struggle to answer the question "is it hard". Is it hard to build a web-app? No. But I've been building web-apps for 20 years. Will you find it hard (if you've never programmed before)? I don't know, if you want to build one this weekend, sure. If you have the patience to spend a few years learning first, then no.

401 points by signa11 3y ago

https://archive.is/cMm11 https://archive.is/cMm11

> Crucially, there is basically no documentation for the standard library except for the source code itself. From the viewpoint of someone learning about a new language, I find the accessibility of the standard libraries goes a long way toward helping me understand how things fit together. It is a first stop to see how experts in the language use it. Browsing through the standard libraries of languages like Zig, Go, and Python - they're usually well-documented and readable enough to be a tutorial, even before you've dug into learning it. Others (Rust, C++) are a bit more, ah, technical for the novice.

Vecr 3y ago
Rust has the standard library documentation at https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/ or on your local computer, if there's really nothing like that for Zig I think that's a problem. Are you sure there's no `info zig` or something like that?
- sciolistse 3y ago
  There is https://ziglang.org/documentation/master/std https://ziglang.org/documentation/master/std but it's not always been correct, and the descriptions are lacking. The new one should hopefully fix that. Personally I've never had an issue reading through the source for zig std, and if your editor supports it you can just 'go to implementation' on most things. Hopefully the code remains relatively readable since I find it preferable to see the actual code + some basic tests rather than trying to navigate those documentation sites.
tialaramex 3y ago
I certainly wouldn't recommend trying to figure out C++ by reading either of the three major C++ standard libraries.
TwentyPosts 3y ago
Afaik Zig has the issue that basically everything happens on the Discord server, where it can't be indexed via search engines, or found by anyone who wants to have a quick question answered. This would be "fine" if the standard library and language were much better documented, but it isn't, and it's still ripe with bugs. In other words, you're forced to use the Zig Discord server if you want to find answers to any simple questions, and this is (sadly) not obvious at all to newcomers to the language.
- girvo 3y ago
  This is true for Nim as well, in that most of the discussion is on the Discord/Matrix server. I’m not a fan personally, at least IRC was easily archived and searchable in practice. I really dislike how Discord has become “forums in the 2020s”
  - Tiberium 3y ago
    This is not actually true for Nim - almost all Nim Discord channels are bridged to different IRC channels, see https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats
    - girvo 3y ago
      Oh that's nice, I thought the IRC bridge had been left to languish. Good to know I was wrong!
- scns 3y ago
  The new Zulip version can make chats accessible from the outside. In the thread about it someone wrote OSS Projects should switch to it.

pron 3y ago

> there’s not a direct correlation between the slimness of a language’s syntax and ease of learning That's absolutely true, but (the standard library aside) the "syntax" -- or, rather the syntax and core semantics -- of a programming language are arbitrary axiomatic rules, while everything else is derivable from those axioms. So while it is true that a small language can lead to a not-necessarily-easy-to-learn overall programming experience, it is the only arbitrary part, and so the only part you need to memorise (or consult the documentation for when dealing with some subtlety you may have forgotten). So a smaller language reduces the need for "language lawyering" after you learn it. Some languages (e.g. lisps) are deceptively small by relying on macros that form a "second-order" language that interacts with the "first-order" language, but Zig doesn't have that. It has only one language level, which is small and easy to memorise. But yes, Zig is a bigger language than C, but a far smaller language than C++. What's amazing, though, is that C++ is strictly more expressive than C (i.e. there are programs that could grow exponentially faster in C than in C++, at least without the help of C macros), but Zig is as expressive as C++ (i.e. program sizes may differ by no more than a small constant factor) while being much closer to C in size, and it achieves that without the use of macros.

the_duke 3y ago
I'm not a Zig expert, but I have a different take here. Zig has comptime, which is essentially a compile time macro written in the main language and with type reflection capabilities. They can introduce complex behaviour and fail in very cryptic and unexpected ways, which results in an experience very similar to macros or C++ template literals.
- pron 3y ago
  The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of symbols like templates or macros, and so are easier to diagnose (you get a regular stack trace for one). There is also another interesting difference, albeit a theoretical one. Zig's comptime is what's known in formal languages to be referentially transparent (it basically means that you cannot distinguish between two otherwise identical objects that differ only in their reference name) while macros are not. Because referential transparency is strictly less expressive than "opacity" (but it's also simpler!), it's surprising that so many practical use cases for macros can be addressed with the less powerful (but simpler and much easier to debug) comptime. That's quite a discovery in language design. While other languages also have comptime-like constructs, they also have other complex features that have made it hard to see just how powerful something like comptime alone can be.

cies 3y ago

From the article: > Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective. I'd argue both are subjective, or with a better word: relative. I'd say Zig is easier and simpler than C in almost all regards. The article does not specify what Zig is compared to in order to make these statements. Probably the author had C in mind, but that was not explicitly mentioned.

bakuninsbart 3y ago

Where do you guys see good use cases for Zig? I'm intrigued by the language but don't really have any good ideas on where to try it out. I thought about trying it out in as small data engineering project, but I'm not sure if language support is sufficient for the kind of tooling I would need eg. Database adapters.

jgalt212 3y ago
I've been thinking about using it for Python hot paths. I'm not smart enough to write rust (at least without limitless supplies of aspirin). And I'd like to avoid C for all the obvious reasons.
- Dowwie 3y ago
  Try Elixir.
chjj 3y ago
Do you maintain any C projects? Personally, I tried using zig for its build system (which can also compile C and whose build files are written in zig). One of the benefits of this was easy cross-compilation to all major platforms. It might not be a _real_ use-case or anything, but writing a `build.zig` file for an existing C project might be a good way to at least dip your toe in the water.
pjmlp 3y ago
In what concerns userspace, I don't see any good case, if I want a better C, without much features, I rather stick to Go even if I dislike some of the design decisions. Or D, Nim, Swift, OCaml, Haskell, AOT C#, AOT Java,... If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust, not a language that still allows for use-after-free errors. Maybe it is a good language for those that would like to have Modula-2 with a C like syntax, and metaprogramming capabilities, and are ex-Objective-C developers.
- distcs 3y ago
  > If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?

jsheard 3y ago

I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.

bodge5000 3y ago
I'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern
- jsheard 3y ago
  Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.
  - felixgallo 3y ago
    as a long time game dev, I actively don't want operator overloading. That's some spooky action at a distance nonsense. I'm not sure I have seen a codebase that involved operator overloading, either, and I've worked in or near a good quantity of well-known titles.
    - jsheard 3y ago
      There's no accounting for taste, but the two major publicly available engines (Unreal and Unity) both use operator overloading in their standard math types.
    - Taywee 3y ago
      You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.

helen___keller 3y ago

My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages. Aside from lack of community I’d say the biggest nuisance is error handling in nearly everything including allocations. I get that allocation can fail but the vast majority of programs I write, I just want to panic on an allocation failure (granted these aren’t production programs…) Edit: in retrospect, allocator error handling verbosity is probably necessary due to the power the language gives you in choosing allocators. If I use the general purpose allocator then my edge case is PC out of memory; if I use a fixed buffer allocator, a failed allocation is a code bug or a common error case, so we might want to handle the failed allocation and recover

kuroguro 3y ago
I suppose you could write a few line wrapper that panics :) But yeah, most of the time I don't even want to think which allocator to use let alone handle it's errors.
- eatonphil 3y ago
  This is basically what I've come to do in the Zig scripts I write at work. It took a bit of getting used to when I joined but we agreed as a team to have all meaningful scripts written in Zig not bash (for one, bash doesn't work on Windows without WSL and we need to support Windows builds/testing/etc.). It makes about as much sense as any other cross-platform scripting option once I got used to it! Some examples: Docs generation: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/docs_generate.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c... Integration testing sample code: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/integration.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c... Running a command wrapped in a TigerBeetle server run: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/clients/run_with_tb.zig https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...

nickelcitymario 3y ago

> [...] easy things seem easy primarily because they are familiar. Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective. This should be printed out as a large poster in every office.

erichocean 3y ago
Rich Hickey has done more to popularize that idea in recent years than perhaps anyone else. [0] In a lot of ways, Zig is to the systems programming space what Clojure is to the information processing space. If you have 5+ years experience, you want simple, not easy. Both languages deliver real advances on that promise in their respective domains. ---- Back to the article, perhaps not coincidentally, the product my startup is developing is written primarily in Zig (language runtime), Clojure, and an in-house Forth/Factor/Joy derivative for user-level scripting. I guess I really do care about simplicity… [0] Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4

ldelossa 3y ago

I'm surprised that the reason I'm mostly interested in Zig is not mentioned. This is C interop. I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome. Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.

workethics 3y ago
Not only that, but zig makes linking against old glibc versions easy. For example, to make an x86_64 linux build linked against glibc 2.9 when using zig build all you have to do is pass: -Dtarget=x86_64-linux-gnu.2.9
- GordonS 3y ago
  Damn, that's a magnificent feature! Maybe I should have another look at Zig...
- beefcafe 3y ago
  This is a killer feature for CTFs/OSCP/etc and why I started using it.
- TDiblik 3y ago
  Hi, why is this feature interesting/important? (Coming from [uneducated] webdeveloper with interest for systems/embedded programming)
ziml77 3y ago
The thing that's espcially nice about that interop is that Zig includes its own C compiler. That eliminates the pain of having a build script locate an installed C compiler and figure out what options should be passed to it.
- lost_tourist 3y ago
  Why would I use zig c compiler in place of gcc or clang? Mainly for zig interactivity or does it have some advantage other than that over the aforementioned compilers?

latch 3y ago

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack of package manager, etc. For an insider living and breathing Zig, not only aren't these huge challenges, they aren't really "Zig" - they are just transient growing pains. For someone getting started though, the current state of Zig is Zig. I wish Zig had a polished package manager (there's one in the current development branch, but you don't as much use it as fight it). They could then move some of the less polished code into official experimental packages, helping to set expectations and maybe focus the development efforts.

zoogeny 3y ago
I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0
- arp242 3y ago
  Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.
  - ReleaseCandidat 3y ago
    > I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.

frankjr 3y ago

I've been playing with it and so far but I'm more impressed with their build system rather than the language itself (it seems to be way more flexible and simpler than alternatives which is pretty rare). They did however get the module system right. You can just organize the file structure in any way you like. I hate Rust's "everything is a single module" system with passion.

mike_hearn 3y ago
How do you find it simpler? From taking a quick look it appears to just be an API for invoking build steps, and the build script is itself a Zig program. I ask if it's really simple, because the JVM space went in the same direction with Gradle (build script = program) and by the time it gets more sophisticated that can turn out to be pretty painful. In particular, IDEs struggle to get the information they need, scripts can become highly complex, and there are various other problems.
- pjmlp 3y ago
  Gradle is Ant reinvented, by those that didn't learn why we moved into Maven.

jeroenhd 3y ago

I like Zig as a concept, but every time I've tried it, the toolchain lacked good IDE and debugger support. I've tried some plugins half a year ago but they either didn't work reliably or they missed important features. I'm personally sticking with Rust until the day comes that I can just add a VSCode/Clion plugin that'll give me an interactive debugger with full autocomplete support without fiddling around too much. There's a lot to like with Zig, despite its unconvential syntax and some language decisions I personally disagree with. The language is still in development but it's very promising and I'll definitely try to learn it before it reaches that magical 1.0 release.

jcalabro 3y ago
I've definitely had a good experience writing Zig in VS Code with the CodeLLDB extension on Linux [0] and the Microsoft C++ [1] one on Windows. It's also got the Zig extension which comes with the Zig language server [2]. [0] https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb https://marketplace.visualstudio.com/items?itemName=vadimcn.... [1] https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=ms-vscod... [2] https://marketplace.visualstudio.com/items?itemName=ziglang.vscode-zig https://marketplace.visualstudio.com/items?itemName=ziglang....

thih9 3y ago

> "I learned Zig in a weekend! … Six hours! … 6µs!" say the blissful lizards. I don’t get it; is this a reference? Could someone explain?

tylerscott 3y ago
IIRC the mascot is a lizard so here the comment is portraying a Zig enthusiast keen on promoting the ease of learning Zig as a lizard. That was my take.

rayiner 3y ago

Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a killer feature that justifies not just using C.

helen___keller 3y ago
If we’re comparing C to Zig I’m not sure what memory safety even needs to be mentioned for. For C to Zig there’s plenty of reasons one might prefer Zig. For memory safety obviously you might opt to choose neither.
- rayiner 3y ago
  In a vacuum, one might prefer Zig. But given that everyone already knows C and the ecosystem is so highly developed, it takes a gamechanging feature like Rust's memory safety to make an alternative language attractive (beyond a "this is cool" project--which I totally support).
  - helen___keller 3y ago
    That is probably why Zig has such a focus on seamless C interop. There’s a good thread in these comments talking about this. Regardless, point taken. You’re more or less describing the internal fear I have (mentioned in another thread) that if I dedicate time to a nontrivial Zig project I will regret it if/when there’s no Zig community in N years
  - alwaysbeconsing 3y ago
    I haven't tried Zig, but "all the things you like about C plus better versions of most/all of the awkward bits" seems like a reasonable value proposition. Especially since the compiler can apparently let you use C painlessly alongside your Zig -- enabling incremental rewriting.

cynicalsecurity 3y ago

Wait, it's a real language? I thought it was a sarcastic article about an imaginary language called zig making fun of hipster languages desperately trying to replace C/C++.

TaupeRanger 3y ago

Maybe a few years ago it would've been "worth it". But with LLMs coming to swallow up all coding tasks and turning programmers into prompt engineers within a few years time, I can't see it being "worth it" any more.

Taywee 3y ago
You still need to understand the code you are generating, testing, and debugging. LLMs don't replace a need for more expressive programming languages.
mr_00ff00 3y ago
I don’t want to make assumptions, but have you tried systems programming with LLMs? A few years and everyone will be prompt engineers is laughable. I hope I can actually use it productively for more than unit tests in a few years.

sarchertech 3y ago

I tried Zig for a few weeks but ended up choosing Odin for a game dev side project I’m working on. Odin feels a lot more high level, but still gives you low level control when you need it.

59nadir 3y ago
I've settled on Odin as well and I think it's currently way ahead for game development than Zig is. Even for other things I'm currently more likely to write it in Odin, despite writing Zig from 2019 to 2022. The reasons really come down to error handling being better in Odin overall with payloads being attachable to errors as well as the context system and zero values making it relatively painless to really only talk about the things that need talking about and letting the rest be unsaid. There are also several similarities: Custom allocators as part of the ecosystem and language, no RAII, easy ways to propagate and handle errors the right way, tagged unions with table stakes like exhaustiveness checking. I think Odin and Zig have some fundamental differences (and plenty of similarities) and when trying Odin out I was surprised to find that I preferred the Odin way overall. For gamedev stuff Odin wins due to a few things; swizzling on a code level is super nice, array programming built-in to the language, vendor libraries shipped with the language that allow you to just get going almost no matter what you're doing, and so on.
- truckerbill 3y ago
  I want to invest in Odin but I see the velocity and growing mindshare that Zig has and I wonder if it's not better to settle for that. Also how do you find the compile times?
  - 59nadir 3y ago
    I think by the time I have a massive project where compile times could actually hurt the newest endeavor with compiling to an intermediate form, etc., will already be released so it's likely that I'll dodge that entirely. For what it's worth I haven't found any language constructs that seem to make the compile time grow considerably, so I think the risk of adding a library and suddenly being faced with massive compile times is fairly low in comparison to some languages. With that said, I'm only using the core lib and vendor libraries. JangaFX by way of GingerBill reports that their 200kloc EmberGen[0] project takes 5 seconds to compile: > On my old machine, it took 5 seconds, and now it takes 2.2 seconds on my new machine. Before some paths in the compiler had multithreading added to them that number was 15 seconds for the same project. As far as I know both of these numbers are for unoptimized builds, i.e. development builds.

stared 3y ago

What are the use-cases in which it might be worth switching from Rust to Zig?

logicchains 3y ago
When you need to be very careful about memory allocation and use various custom allocators for stuff, and you don't care too much about memory safety. Rust makes working with custom allocators somewhat painful, in exchange for safety, so if you don't need the safety, no point going through that pain.
- notfed 3y ago
  What kinds of programs don't care about memory safety?
  - nyberg 3y ago
    Compiler enforced memory safety*. Games in particular tend to have their own allocators and memory management schemes which don't play well with global allocators. Using memory pools, frame (arena) allocators, system specific memory management, and so on. Handling memory in a very systematic way (avoiding the "malloc everywhere" anti-pattern) where ownership is clearly tied to systems and handles (integers (maybe with metadata)) passed instead of pointers helps keep this all sane. That and you can still throw a GC/Ref counting at things which have non-linear lifetimes if needed but there's no need to do so globally. One-shot programs also don't always need it as they're often fine with a less sophisticated scheme of arena allocation or reusing memory by resetting temporary buffers. You also have the option to classify pointers if you absolutely must pass them with similar techniques as https://dinfuehr.github.io/blog/a-first-look-into-zgc https://dinfuehr.github.io/blog/a-first-look-into-zgc.
epage 3y ago
matklad, of rust-analyzer fame among many other things, wrote up their thoughts on Zig: https://matklad.github.io/2023/03/26/zig-and-rust.html https://matklad.github.io/2023/03/26/zig-and-rust.html I've seen some put it as "zig is good when `unsafe` heavy code". Personally, even when writing life-or-death software, allocation errors were too much of a pain to deal with and much prefer Rust's approach for 99% of software. The question is if another language like zig provides enough value to justify existing for that 1% of use cases (all numbers made up :) ).

jasfi 3y ago

Nim isn't hard, it just has a small community.

anta40 3y ago
I haven't done any production-level stuff with Nim (still learning it), I think overall it's a nice language (I also like Python & Pascal). If your goal is applying for job, Go is obviously a better pick.

michaelcampbell 3y ago

I don't know Zig so I can't comment much on the content, but the author's writing style I enjoyed immensely; enough to make me want to pick up Zig for fun. I do have some C background, albeit decades ago, so maybe I'm in the right spot for it.

ok123456 3y ago

One annoying thing I ran into when trying zig is they don't distribute debs any more for Debian distributions. They just tell you to use a snap. I don't have snap, and don't want it. Compiling it requires the latest llvm toolchian (16), which is only realistically going to be available as a package if you're on a bleeding edge distribution.

pacaro 3y ago
I understand this, but haven't found this to be an issue personally. I just download the pre built tarball, expand it, make sure that /opt/zig-latest symlinks to the right folder, and setup path That's more work than apt-get install for sure, but not so much more
- hellcow 3y ago
  You can also use something like zigup to make fetching the latest master/managing multiple versions easier.
netule 3y ago
Zig's in the process of getting added to the mainline Debian repositories: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 Hopefully, this process will continue soon as the bug seems to be getting a bit stale.
eatonphil 3y ago
What's wrong with downloading the binary? curl + mv + chown should do it?
AndyKelley 3y ago
let me clarify some facts. 1. we never distributed debs for debian distributions. I have, however, been patiently collaborating with Debian maintainers with regards to the zig ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 2. we don't tell you to "just use a snap.". Please see https://github.com/ziglang/zig/#installation https://github.com/ziglang/zig/#installation 3. we tag releases soon after llvm tags releases for the convenience of package maintainers. Distributions with LLVM 14 can package Zig 0.9.1; distributions with LLVM 15 can package Zig 0.10.1, etc.

askkk 3y ago

In new last version 0.10.1 it seems that for is not working with two arguments? const std = @import("std"); const expect = std.testing.expect; test "for basics" { const items = [_]i32 {4,5,3,4,0}; var sum: i32 = 0; for(items, 0.. ) |value,_| { sum += value; } try expect(sum == 16); } ubuntu 22.04, snap zig version 0.10.1 , zig test 1.zig produces: 1.zig:7:12: error: expected ')', found ',' for(items, 0.. ) |value,_| { ^ Edited: To update, I tried snap, but using snap install --classic --beta zig is a security risk because it can change the system and is not sandboxed.

EscapeFromNY 3y ago
For loop syntax was changed since 0.10.1. Zig 0.10.1: for(items) |value| {} for(items) |value, index| {} Zig 0.11-dev: for(items) |value| {} for(items, 0..) |value, index| {} for(as, bs, cs, ds, 0..) |a, b, c, d, index| {}

KingLancelot 3y ago

[dead]

LispSporks22 3y ago

> Only time will tell if comptime is the "greatest thing since sliced bread" or not. Common Lisp user here. Am I missing anything that Zig has in the compile time department? edit: Also, does the code in the comptime block have to be valid Zig?

kps 3y ago
It only has to be syntactically valid (parseable).
kllrnohj 3y ago
Personally I think comptime is a questionably design and is something both Rust & C++ did much better. In C++ branches that don't have to "compile" are explicitly marked as such with `if constexpr`. In Rust you've got macros that are also explicit with required `!`. In Zig any branch can be a ticking code rot time bomb, just like it was with C #ifdefs. It's better in Zig in that it at least has to parse and so you've got fewer blatant problems, but the category of problems of "I flipped DEBUG from `false` to `true` and now I have dozens of build errors to go fix" is still there. And you really don't have any warning signs other than "this is branching on something that might be known at compile time" But honestly that's also my general impression of Zig as a whole. It's very definitely a "better C", not something that's necessarily good/competitive with the broader state of the ecosystem. It's like a love letter to C, completely with many of the same general problems that C is known to have and that other languages have addressed.

Decabytes 3y ago

Zig is not my favorite language to program in, but I think it's focusing on a lot of the right stuff. 1. Easy Build System 2. Drop in Replacement for c/c++ compiler (zig cc) 3. Easy cross compliation 4. Single executable compiler 5. Package manager 6. Debugabillity It's the sort of developer focus that has a huge impact especially when you are doing it for more than just a hobby. Crystal, another language I love, is weak in this area. No tree sitter, No tier1 windows support, Major libraries like the Lucky Framework that don't build on Windows, a buggy LSP etc. Don't get me wrong I love the language, and I will continue to work in it, and all of these things are in various states of progress, but it's already at 1.8 and some of these issues haven't been ironed out yet. I'm not just armchair complaining, I know these are hard, and I will contribute once I am more familiar with the language

jksmith 3y ago

Is this a writeup about Zig, or any Wirth language written 50 years ago? Asking for some Modula2 OG.

parasense 3y ago

The main take away is: > Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior. Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the point here is the idea of undefined behaviour is tied to portability on some levels, and isn't just some purely academic idea about the compiler or abstract syntax trees. So I'm concerned about the potential over-zealous prejudice against undefined behaviour, but I think we can all agree deterministic software is better than otherwise. The catch is that sometimes UB is deterministic, and yet dares to not be idiomatic.

Symmetry 3y ago
Assuming that bytes are 8 bits long or that negative numbers are represented with two's complement is a lot less dangerous these days than it was when C came along.
pklausler 3y ago
Ironically, C is now way more portable than modern Fortran is. The Venn diagram of feature portability across the 6 or 7 actively-maintained Fortran compilers is very messy.
kps 3y ago
C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.
- jsmith45 3y ago
  Yeah. In hindsight for a fair bit of it, it could have been sensibly changed to implementation defined behavior, or to constrained unspecified behavior. (Constrained such that people know what the possibilities are, but the compiler need not document its choice, and might not make the same choice in all circumstances. The latter could allow for scenarios where letting an optimizer do the faster thing when detectable, and what the hardware natively does otherwise, for example. Obviously still a potential footgun, but less of one than full undefined behavior).

_8j50 3y ago

Everything is hard when you first learn it. If you find it easy, that's only because you don't have to learn part of it because you learned the concept in a different language. Even learning to count was hard when we were small children. A better measure IMO is how long it might take you specifically. For example, Rust is much easier for me to learn than Haskell because I have never coded in a functional language before. Golang was very easy to pick up on. I never took time to learn python and powershell, I just kept referencing existing code and googling for examples because they were both mostly familiar languages with a different syntax.

galaxyLogic 3y ago

Love the picture. People often say how easy something was for them. They are saying they are a very capable, smart person. Would you rather hire someone for whom everything is easy, or someone for whom things seem difficult? In other words saying they learned something fast or that something is easy for them, is at least partially self-promotion. So claims of how easy something was for them it have to be taken with a grain of salt. The interesting thing for the rest of us is WHY something is easy, or difficult. That would be helpful for others to know. This article is just that, it tells us why Zig can be difficult. What to look out for.

codedokode 3y ago

I don't know anything about Zig except that it is a low-level language. Can someone please explain how it is better than Rust?

iskander 3y ago

Is there anything akin to Maturin for Zig? I would love to use it as an extension language for Python.

Alifatisk 3y ago

May I ask what the hype is with Zig? What makes it so attractive? Is it the performance? The easy interop with C? The ease of controlling the memory allocation?

WhereIsTheTruth 3y ago

The issues I have with Zig are similar to the ones I have with Rust, the syntax.. I will never get used to it, I find it tasteless and non-ergonomic But, I manage to set it aside because it provides enough benefits, I mainly use Zig as a toolchain to crosscompile my libraries.. and write some helper externs Hopefully they manage to improve and ease out the syntax by 1.0, I have hopes

jadodev 3y ago
Have any examples of syntax you find tasteless? Things in Zig that feel ergonomic to me: comptime params > separate generic args; ptr.* > *ptr; optional pointers > possibly null normal pointers; separate syntax for slices, arrays, & pointers > 1 syntax for ptr & arrays.
- WhereIsTheTruth 3y ago
  var t: ?i32 = null; if (t) { t +=1; } This for example doesn't work, you have to capture, many little things like that that stacks up and ends up creating a non-ergonomic syntax No for loop, so you have to do multilines things like, and now you meet a new : construct, this pseudo for loop now looks confusing to look at var i: i32 = 0; while (i < 42) : (i+=1) { } Then constant casting between integers, and also floats.. also no operator overload for the math types etc.. Also not a fan of the pointer difference between [] * [:0], too much different nitpicking that makes iterating slow and painful, I understand the benefits, but the way it's done is not enjoyable, at least to me That's just whats on the top of my head, it's been a while I haven't wrote Zig code so I may be remembering wrong

erhaetherth 3y ago

> easy things seem easy primarily because they are familiar This is also why I struggle to answer the question "is it hard". Is it hard to build a web-app? No. But I've been building web-apps for 20 years. Will you find it hard (if you've never programmed before)? I don't know, if you want to build one this weekend, sure. If you have the patience to spend a few years learning first, then no.