11 ms·

Type resolution redesign, with language changes to taste

401 points by Retro_Dev 7mo ago

h4ch1 7mo ago
I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.
- Cloudef 7mo ago
  The language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need. > Are there cases where packages you may use fall behind the language? Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.
  - Zambyte 7mo ago
    Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06 https://ziglang.org/devlog/2026/#2026-02-06
  - hrmtst93837 7mo ago
    [flagged]
- latch 7mo ago
  Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% of the time I do that, it's an easy error, but the other 10%, I get a message-less compiler crash). It sounds like the changes in the OP might be specifically addressing these types of issues. Also, my .zig-cache is currently at 173GB, which causes some issues on the small Linux ARM VPS I test with. As for upgrades. I upgraded lightpanda to 0.14 then 0.15 and it was fine. I think for lightpanda, the 0.16 changes might not be too bad, with the only potential issue coming from our use of libcurl and our small websocket server (for CDP connections). Those layers are relatively isolated / abstracted, so I'm hopeful. As a library developer, I've given up following / tracking 0.16. For one, the change don't resonate with me, and for another, it's changing far too fast. I don't think anyone expects 0.16 support in a library right now. I've gotten PRs for my "dev" branches from a few brave souls and everyone seems happy with that arrangement.
  - quag 7mo ago
    That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full. Do you see any major problems when you remove your .zig-cache and start over?
    - latch 7mo ago
      Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
      - sgt 7mo ago
        Does Zig have incremental builds yet? Or is it 20 secs each time for your build.
        latch 7mo ago
        20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
        sgt 7mo ago
        I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
        cwillu 7mo ago
        It's discussed in the post.
      - h4ch1 7mo ago
        But why is it so big in the first place? I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193 https://codeberg.org/ziglang/zig/issues/30193 The following quotes stand out > zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process. > I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB. > not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?
- Escapade5160 7mo ago
  I recently tried to learn it and found it frustrating. A lot of docs are for 0.15 but the latest is (or was) 0.16 which changed a lot of std so none of the existing write ups were valid anymore. I plan to revisit once it gets more stable because I do like it when I get it to work.
  - Cloudef 7mo ago
    0.16 is the development version. 0.15.2 is latest release.
- rtfeldman 7mo ago
  I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark). The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to land (I think it might have been 0.12 -> 0.13 but I could be misremembering the exact version) but it's been smooth sailing for a long time now. These days I'd put breaking releases in the "minor nuisance" category, and when people ask what I've liked and disliked about using Zig I rarely even remember to bring it up. [0]: https://github.com/roc-lang/roc https://github.com/roc-lang/roc
  - sureglymop 7mo ago
    At this point do you believe porting the codebase to Zig was the right decision? Do you have any regrets? Also, I'm excited about trying out your language even moreso than Zig. :)
  - wvlia5 7mo ago
    What's the main value proposition of roc? I found interesting tags (like symbols in mathematica) and tags with payloads (like python namedtuple or dataclasses). I haven't seen this elsewhere. Otherwise seems quite typical (Pattern matching is quite common, for example). Example programs that you couldn't easily express in other languages?
  - rkangel 7mo ago
    Are you aware that your Github README doesn't actually tell us anything about Roc is or why we might be interested? This might be on purpose given the first words are "Work in progress" and "not ready for release", but linking as above does lose some value.
    - messe 7mo ago
      Instead of being rude, consider checking Roc's website: https://roc-lang.org/ https://roc-lang.org/ He wasn't pitching the language directly, but linking to the codebase as that was what was relevant to the comment he was replying to.
- throwaway27448 7mo ago
  For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software) https://en.wikipedia.org/wiki/Bun_(software)
  - beoberha 7mo ago
    Bun is a full fledged JavaScript runtime! Think node.js but fast
    - throwaway27448 7mo ago
      > Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....
      - leonflexo 7mo ago
        Bun uses JSC (JavaScriptCore) instead of V8. From what I understand, whereas Node/V8 has a higher tier 4 "top speed", JSC is more optimized for memory and is faster to tier up early/less overhead. Good for serverless. Great for agents -> Anthropic purchase.
        throwaway27448 7mo ago
        > Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.
        messe 7mo ago
        > Surely nobody would use javascript for either yea? It's probably the most popular language for serverless.
        7mo ago
- boomlinde 7mo ago
  I stopped updating the compiler at 0.14 for three projects. Getting the correct toolchain is part of my (incremental) build process. I don't use any external Zig packages. I think one of the more PITA changes necessary to get these projects to 0.15 is removing `usingnamespace`, which I've used to implement a kind of mixin. The projects are all a few thousand LOC and it shouldn't be that much trouble, but enough trouble that none of what I gain from upgrading currently justify doing it. I think that's fine.
- scuff3d 7mo ago
  Mitchell Hashimoto (developer of Ghostty) talks about Zig a lot. Ghostty is written in it, and he seems to love it. The churn doesn't seem to bother him at all. I asked him about in a thread a while back: https://news.ycombinator.com/item?id=47206009#47209313 https://news.ycombinator.com/item?id=47206009#47209313 The makers of TigerBeatle also rave about how good Zig is.
- nickysielicki 7mo ago
  The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.
  - fouronnes3 7mo ago
    Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.
    - pjmlp 7mo ago
      As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken. There is still this disconnection on how languages under ISO process work in the industry.
      - jonstewart 7mo ago
        The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.
        pjmlp 7mo ago
        And you will be the one telling the losers that their compiler, operating systems and OS doesn't count? By the way this applies to the C language so beloved on this corner as well. As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).
    - munificent 7mo ago
      The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.
- kprotty 7mo ago
  I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1]. These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies. [0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a... [1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...
  - ryanxsim 7mo ago
    I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
    - lionkor 7mo ago
      Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
      - bayindirh 7mo ago
        Seriously asking, where Go sits in this categorization?
        shilgapira 7mo ago
        It's also a modern C. If you enjoy C and wish it was less verbose and more modern, try Go.
        bayindirh 7mo ago
        Thanks. I write some Go, and feel the same about it. I really enjoy it actually. Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard. Maybe gccrs will change that, IDK, yet.
- sgt 7mo ago
  > I know Bun's using zig to a degree of success, was wondering how the rest were doing. Just a degree of success?
- ptrwis 7mo ago
  You can fix you code 10 times you will fix it.
- hansvm 7mo ago
  It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day. Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.
- steeve 7mo ago
  hi, i'm the founder of https://github.com/zml/zml https://github.com/zml/zml, very happy with Zig
- MrResearcher 7mo ago
  Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib. Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well. Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development. We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.
throwaway17_17 7mo ago
Congratulations to the dev, a 30,000 line PR for a language compiler (and a very much non-trivial compiler) is a feat to be proud of. But a change of this magnitude is a serious bit of development and gave me pause. I understand both of the following: 1. Language development is a tricky subject, in general, but especially for those languages looking for wide adoption or hoping for ‘generational’ (program life span being measured in multiple decades) usage in infrastructure, etc. 2) Zig is a young-ish language, not at 1.0, and explicitly evolving as of the posting of TFA With those points as caveats, I find the casualness of the following (from the codeburg post linked on the devlog) surprising: ‘’’This branch changes the semantics of "uninstantiable" types (things like noreturn, that is, types which contain no values). I wasn't originally planning to do this here, but matching the semantics of master was pretty difficult because the existing semantics don't make much sense.’’’ I don’t know Zig’s particular strategy and terminology for language and compiler development, but I would assume the usage of ‘branch’ here implies this is not a change fully/formally adopted by the language but more a fully implemented proposal. Even if it is just a proposal for change, the large scale of the rewrite and clear implication that the author expects it to be well received strikes me as uncommon confidence. Changing the semantics of a language with any production use is nearly definitionally MAJOR, to just blithely state your PR changes semantics and proceed with no deep discussion (which could have previously happened, IDK) or serious justification or statements concerning the limited effect of those changes is not something I have experienced watching the evolution (or de-evolution) of other less ‘serious’ languages. Is this a “this dev” thing, a Zig thing, or am just out of touch with modern language (or even larger scale development) projects? Also, not particularly important or really significant to the overall thrust of TFA, but the author uses the phrase “modern Zig”, which given Zig’s age and seeming rate of change currently struck me as a very funny turn of phrase.
- smj-edison 7mo ago
  mlugg is one of the core contributors of Zig, and is a member of the Zig foundation iirc. They've been wanting to work on dependency resolution for a while now, so I'm really glad they're cleaning this up (I've been bitten before by unclear circular dependency errors). There's not a formal language spec yet, since it's moving pretty fast, but tbh I don't see the need for a standard, since that's not one of their goals currently.
patchnull 7mo ago
[flagged]
- sethops1 7mo ago
  AI slop. Get lost.
sidkshatriya 7mo ago
I am impressed by the achievements of the Zig team. I use the ghostty terminal emulator regularly -- it is built in Zig and it is super stable. It is a fantastic piece of software. This makes me feel that the underlying technology behind Zig is solid. But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description). This gives Zig very powerful meta programming abilities but is a pain because you don't know what kind of type "shapes" will be used in a particular piece of code. Zig is similar to C++ templates in some respects. This has a ripple effect everywhere. Rust generated documentation is very rich and explicit about what functions a structure supports (as each trait is explicitly enrolled and implemented). In Zig the dynamic nature of the code becomes a problem with autocomplete, documentation, LSP support, ...
- Zanfa 7mo ago
  > But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description). Do you happen to have a more specific example by any chance? I’d be interested in what this looks like in practice, because what you described sounds a bit like Go interfaces and from my understanding of Zig, there’s no direct equivalent to it, other than variations of fieldParentPtr.
  - lukaslalinsky 7mo ago
    They are referring to `anytype`, which is a comptime construct telling the compiler that the parameter can be of any type and as long as the code compiles with the given value, it's good. It's an extremely useful thing, but unconstrained, it's essentially duck typing during compile time. People has been wanting some kind of trait/interface support to constrain it, but it's unlikely to happen.
deleted 7mo ago
[deleted]
ansi_c 7mo ago
[dead]
sesm 7mo ago
Instead of implementing a workaround for types as namespaces, wouldn't it better to explicitly add namespaces to the language?
- Arch485 7mo ago
  It's not so much a workaround as it is an elegance in design. In Zig, when you @import a file, that file is converted to a struct with comptime fields for all of the public members. Similarly, a "namespace" in Zig is just a nested struct with more fields. Usually it's just another import of something else. N.B.: Coffee hasn't reached my bloodstream yet; accuracy not guaranteed.
  - peesem 7mo ago
    files aren't converted to structs on import, they _are_ structs (well, their contents are the inside of a struct declaration). also, public members don't become comptime fields? file structs are basically left as-is on import, nearly like you copy&pasted the file contents into a struct declaration
- txdv 7mo ago
  I think zig is striving for language minimalism, make it minimal as possible then if a feature optimized multiple places use cases benefit
lerno 7mo ago
It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years. There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics. To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is no expectation that Zig is trying to minimize upgrading problems. This is a cultural thing, it would be no real problem to be clear about deprecations, but in the Zig community it’s simply not valued. In fact it’s a source of pride to be able to adapt as fast as possible to the new changes. I like to talk about expectation management, and this is a great example of it. In discussions, it is often falsely argued that ”Zig is not 1.0 so breaks are expected” in order to motivate the frequent breaks. However, there are degrees to how you handle breaks, and Zig is clearly in the ”we don’t care to reduce the work”-camp. If someone is trying to get a more objective look at the Zig upgrade path, then it’s worth keeping in mind that the tradition in Zig is to offload all the work on the user. The argument, which is frequently voiced, is that ”breaking things will make the language get better and so it’s good that there are language breaks” It is certainly true that breaking changes are needed, but most people outside of the Zig community would expect it to be done with more care (deprecation paths etc) Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year. 10 years is the common point where languages go 1.0. However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0. This means that in the future, projects using Zig can still expect any libraries and applications to bitrot quickly if they are not constantly maintained. Putting this in contrast with Odin (9 years old) which is essentially 1.0 already and has been stable for several years. Maybe this also explains the difference in actual output. For example the number of games I know of written in Odin is somewhere between 5 to 10 times as many as Zig games. Now weighing in that Zig has maybe 5 or 10 times as many users, it means Odin users are somewhere between 20-100 times as likely to have written a playable game. There are several explanations as to why this is: we could discuss whether the availability of SDL, Raylib etc is easier on Odin (then why is Zig less friendly?), maybe more Odin has better programmers (then why do better programmers choose Odin over Zig), maybe it’s just easier to write resource intensive applications with Odin than Zig (then what do we make of Zig’s claim of optimality?) If we look past the excuses made for Zig (”it’s easy to fix breaks” ”it’s not 1.0”) and the hype (”Zig is much safer than C” ”Zig makes me so productive”) and compare with Odin in actual productivity, stability and compilation speed (neither C3 nor Odin requires 100s of GB of cache to compile in less than a second using LLVM) then Zig is not looking particularly good. Even things like build.zig, often touted as a great thing, is making it really hard for a Zig beginner (”to build your first Hello World, first understand this build script in non-trivial Zig”). Then for IDEs, suddenly something like just reading the configuration of what is going to be used for building is hidden behind an opaque Zig script. These trade-offs are rarely talked about, as both criticism and hype is usually based on surface rather than depth. Well, that’s long enough of a comment. To round it off I’d like to end on a positive note: I find the Zig community nice and welcoming. So if you’re trying Zig out (and better do that, don’t let others’ opinions - including mine - prevent you from trying things out) do so. If you want to evaluate Zig against competitors, I’d recommend comparing it to D, Odin, Jai and C3.
saritekin 7mo ago
[flagged]
- postflopclarity 7mo ago
  please don't use AI to write comments
- deleted 7mo ago
  [deleted]
- nindalf 7mo ago
  dang can we please ban any user that writes comments with AI?
king_geedorah 7mo ago
The kernel32 -> Ntdll changes are the most interesting thing to me here. A lot of the rationale is applicable also to the linux userspace APIs, especially errors in return at the kernel-userspace boundary vs GetLastError/errno in kernel32/libc. Of course on linux the "problem" is that libc and the kernel API are intimately intertwined and the former mandates using errno. I wonder how the pattern made its way into windows as well. That environment has never seemed to me to promote using libc.
- simonask 7mo ago
  The errno/GetLastError() pattern is a remnant from a time before threads were a thing. You could have multiple processes, but they were largely scheduled collaboratively (rather than preemptively). In that world, things like global variables are perfectly fine. But then we got first preemptive scheduling and threads, then actual multicore CPUs, so global variables became really dangerous. Thread locals are the escape hatch that carried these patterns into the 21st century, for better or worse.
  - jlokier 7mo ago
    Indeed, and this change of philosophy shows up in the pthread (POSIX threads) API, which returns error values directly (as a negative integer) instead of setting the errno variable.
- deleted 7mo ago
  [deleted]
yowang 7mo ago
[dead]
ChrisSD 7mo ago
> Many projects including Chromium, boringssl, Firefox, and Rust call SystemFunction036 from advapi32.dll because it worked on versions older than Windows 8. That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chromium: https://github.com/chromium/chromium/blob/dc7016d1ef67e3e1281dce92bf27ed1f9743ea2f/base/rand_util_win.cc#L74 https://github.com/chromium/chromium/blob/dc7016d1ef67e3e128... > If [ProcessPrng] fails it returns NO_MEMORY in a BOOL (documented behavior is to never fail, and always return TRUE). From Windows 10 onward ProcessPrng will never fail. There's a whitepaper that gives the justification for this (https://aka.ms/win10rng https://aka.ms/win10rng): > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request... > For each user-mode process, we have a (buffered) base PRNG maintained by BCryptPrimitives.dll. When this DLL loads it requests a random seed from kernel mode (where it is produced by the per-CPU states) and seeds the process base PRNG. If this were to fail, BCryptPrimitive.dll fails to load, which in most cases causes the process to terminate. This behavior ensures that we never have to return an error code from the RNG system.
- winterqt 7mo ago
  (This is a response to a different devlog entry on the same page, not TFA.)
  - ChrisSD 7mo ago
    Oh sorry, I thought this was just listing changes since the branch.
mlugg 7mo ago
Hi, author of this devlog here! Not to dismiss concerns about breaking language changes, but there seems to be a bit of a misconception here that this compiler change was highly breaking and will require significant effort from Zig users to update for. Perhaps I unintentionally gave that impression in the devlog or the PR writeup, apologies if so---but it's not the case! Although there were breaking changes in this patch, they were quite minor: most users are unlikely to hit them, and if they do then they're straightforward to deal with. For a concrete example, while testing this branch, I tried building ZLS (https://github.com/zigtools/zls/ https://github.com/zigtools/zls/). To do that, the only change I had to make was changing `.{}` to `.empty` in a couple of its dependencies (i.e. not even in ZLS itself!). This was needed because I removed some default values from `std.ArrayList` (so the change was in standard library code rather than the language). Those default values had actually already been deprecated (with intent to remove) for around a year, so this wasn't exactly a new change either. As another example, Andrew has updated Awebo (https://codeberg.org/awebo-chat/awebo https://codeberg.org/awebo-chat/awebo), a text and voice chat application, to the new version of Zig. Across Awebo's entire dependency tree (which includes various packages for graphics, audio, and probably some other stuff), the full set of necessary changes was: * Same as above, change `.{}` to `.empty` in a few places, due to removal of deprecated defaults * Add one extra `comptime` annotation to logic which was constructing an array at comptime * Append `orelse @alignOf(T)` onto an expression to deal with a newly-possible `null` case These are all trivial fixes which Zig developers would be able to do pretty much on autopilot upon seeing the compile errors. So, while there were a handful of small breaking changes, they don't seem to me like a particularly big deal (for a language where some level of breakage is still allowed). The main thing this PR achieved was instead a combination of bugfixes, and enhancements to existing features (particularly incremental compilation).
- throwaway17_17 7mo ago
  I made one of the comments that seems to be perceived a critical of the changes (I made a statement about the seemingly brief paragraph on changing semantics). As I replied to Andrew, I will tell you: the PR had a large amount of planning and implementation that seems of great quality. I certainly did not intend to discredit you or the obviously large amount of work you have done previously or on the change. I guess that will teach me to post without even more caveats.
sharyphil 7mo ago
Move 'ZIG'.
lerno 7mo ago
I just have to add another reflection: One thing that tends to be overlooked when discussing changes is the ecosystem effect of frequent changes. A language that breaks frequently doesn't just impose upgrade work on apps, but also discourages the creation of long-lived libraries and tools. Anything that sits between the language and the user (linters, bindings, frameworks, teaching material, tutorials etc) has to to some degree "chase the language" This means that the ecosystem will skew toward very actively maintained libraries and away from "write once then leave it alone" libs. And this the trade-off is reasonable during early language design, but it's worth acknowledging that it has real consequences for ecosystem growth. One should note that other newer languages have put significant effort into minimizing this churn, precisely to allow the latter type of ecosystem to also form. So it's kind of an experiment, and it will be interesting to see which approach ends up producing the larger ecosystem over time.
- riidom 7mo ago
  An example for this is the Blender addon ecosystem. Blender moves very fast, breaking API changes every few versions. Now I am not an addon developer myself, but from github issues I follow, changes are fairly often trivial to do. Yet, someone has to do them. Ideally it is the creator of the addon, sometimes it's the users who do it, when the addon is not maintained anymore (in case of trivial changes). It kinda works that way, but it also is some kind of gamble for the user. When you see a new addon (and a new addon developer), you can't know if they gonna stick to it or not. If you have to pay for the addon, it's more likely they maintain it, of course. But also not a guarantee.
- bro45x 7mo ago
  Zig's worth it though. I don't care for libraries that aren't maintained anyway. If they don't maintain it, it's just bad anyway. Why do you always nag about Zig. Stop shilling your C3 here.
  - MintPaw 7mo ago
    This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable. But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good. Requiring every dependency to be constantly maintained is a massive drain on productivity.
burgerone 7mo ago
What makes zig special as a language? I have the impression that it has quite a large fan base here on HN but don't really hear any talks about it anywhere else.
- portly 7mo ago
  I can share mine. I am not sure if this connects with you because maybe you are more experienced. I'm DevOps writing boring Python microservices for €. I have no CS background and never did systems programming. However, writing Python always bothered me because there are so many layers between you and what's happening on the metal. For me, Django is the peak example of this, to me it feels almost like doing no code. It makes me very uncomfortable writing it. Then I heard about this new programming language Zig on YouTube and I just gave it a try. After using it for a few months, I really like it. I guess mostly because it is so explicit. It is almost like the language encourages you to think in terms of system design. Zig offers a lot of freedom so you can design the perfect tool for your problem. And somehow, it feels very effective for it. I think it is a blessing that there are few third party libraries for the same reason. For example. I am working on a tool to parse CIM (some XML standard). If I had to use Python for this, my solution would probably use the most popular xml parsing library and then go from there. Yawn. Instead, with Zig I started to think with a very fresh mind about the problem. I started thinking more from the first principles of the problem. And I got very excited again about programming. During my swimming practice or biking, I kept thinking about the design and how I can make it simpler and improving it by simply not doing certain busy work. I can't fully explain it. But the language gets you in that mindset. Maybe other system languages also offer this experience, Zig (marketing?) just happened to cross my paths at the right moment.
  - Tadpole9181 7mo ago
    I'm sure it's not what you meant, but the argument "it makes me slower at my job and deliver less stable solutions, but I feel cool doing it" is not exactly a compelling endorsement.
    - troad 7mo ago
raphaelmolly8 7mo ago
[dead]
patchnull 7mo ago
[flagged]
xthunk 7mo ago
One thing I’ve noticed reading Zig discussions is that many semantics seem simple on their own but interactions can be subtle – like in the behavior fixed here. I wonder if this ends up similar to C++ template rules where the surface looks small but the edge cases accumulate over time.

401 points by Retro_Dev 7mo ago

h4ch1 7mo ago

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

Cloudef 7mo ago
The language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need. > Are there cases where packages you may use fall behind the language? Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.
- Zambyte 7mo ago
  Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06 https://ziglang.org/devlog/2026/#2026-02-06
- hrmtst93837 7mo ago
  [flagged]
latch 7mo ago
Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% of the time I do that, it's an easy error, but the other 10%, I get a message-less compiler crash). It sounds like the changes in the OP might be specifically addressing these types of issues. Also, my .zig-cache is currently at 173GB, which causes some issues on the small Linux ARM VPS I test with. As for upgrades. I upgraded lightpanda to 0.14 then 0.15 and it was fine. I think for lightpanda, the 0.16 changes might not be too bad, with the only potential issue coming from our use of libcurl and our small websocket server (for CDP connections). Those layers are relatively isolated / abstracted, so I'm hopeful. As a library developer, I've given up following / tracking 0.16. For one, the change don't resonate with me, and for another, it's changing far too fast. I don't think anyone expects 0.16 support in a library right now. I've gotten PRs for my "dev" branches from a few brave souls and everyone seems happy with that arrangement.
- quag 7mo ago
  That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full. Do you see any major problems when you remove your .zig-cache and start over?
  - latch 7mo ago
    Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
    - sgt 7mo ago
      Does Zig have incremental builds yet? Or is it 20 secs each time for your build.
      - latch 7mo ago
        20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
        sgt 7mo ago
        I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
        cwillu 7mo ago
        It's discussed in the post.
    - h4ch1 7mo ago
      But why is it so big in the first place? I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193 https://codeberg.org/ziglang/zig/issues/30193 The following quotes stand out > zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process. > I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB. > not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?
Escapade5160 7mo ago
I recently tried to learn it and found it frustrating. A lot of docs are for 0.15 but the latest is (or was) 0.16 which changed a lot of std so none of the existing write ups were valid anymore. I plan to revisit once it gets more stable because I do like it when I get it to work.
- Cloudef 7mo ago
  0.16 is the development version. 0.15.2 is latest release.
rtfeldman 7mo ago
I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark). The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to land (I think it might have been 0.12 -> 0.13 but I could be misremembering the exact version) but it's been smooth sailing for a long time now. These days I'd put breaking releases in the "minor nuisance" category, and when people ask what I've liked and disliked about using Zig I rarely even remember to bring it up. [0]: https://github.com/roc-lang/roc https://github.com/roc-lang/roc
- sureglymop 7mo ago
  At this point do you believe porting the codebase to Zig was the right decision? Do you have any regrets? Also, I'm excited about trying out your language even moreso than Zig. :)
- wvlia5 7mo ago
  What's the main value proposition of roc? I found interesting tags (like symbols in mathematica) and tags with payloads (like python namedtuple or dataclasses). I haven't seen this elsewhere. Otherwise seems quite typical (Pattern matching is quite common, for example). Example programs that you couldn't easily express in other languages?
- rkangel 7mo ago
  Are you aware that your Github README doesn't actually tell us anything about Roc is or why we might be interested? This might be on purpose given the first words are "Work in progress" and "not ready for release", but linking as above does lose some value.
  - messe 7mo ago
    Instead of being rude, consider checking Roc's website: https://roc-lang.org/ https://roc-lang.org/ He wasn't pitching the language directly, but linking to the codebase as that was what was relevant to the comment he was replying to.
throwaway27448 7mo ago
For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software) https://en.wikipedia.org/wiki/Bun_(software)
- beoberha 7mo ago
  Bun is a full fledged JavaScript runtime! Think node.js but fast
  - throwaway27448 7mo ago
    > Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....
    - leonflexo 7mo ago
      Bun uses JSC (JavaScriptCore) instead of V8. From what I understand, whereas Node/V8 has a higher tier 4 "top speed", JSC is more optimized for memory and is faster to tier up early/less overhead. Good for serverless. Great for agents -> Anthropic purchase.
      - throwaway27448 7mo ago
        > Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.
        messe 7mo ago
        > Surely nobody would use javascript for either yea? It's probably the most popular language for serverless.
        7mo ago
boomlinde 7mo ago
I stopped updating the compiler at 0.14 for three projects. Getting the correct toolchain is part of my (incremental) build process. I don't use any external Zig packages. I think one of the more PITA changes necessary to get these projects to 0.15 is removing `usingnamespace`, which I've used to implement a kind of mixin. The projects are all a few thousand LOC and it shouldn't be that much trouble, but enough trouble that none of what I gain from upgrading currently justify doing it. I think that's fine.
scuff3d 7mo ago
Mitchell Hashimoto (developer of Ghostty) talks about Zig a lot. Ghostty is written in it, and he seems to love it. The churn doesn't seem to bother him at all. I asked him about in a thread a while back: https://news.ycombinator.com/item?id=47206009#47209313 https://news.ycombinator.com/item?id=47206009#47209313 The makers of TigerBeatle also rave about how good Zig is.
nickysielicki 7mo ago
The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.
- fouronnes3 7mo ago
  Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.
  - pjmlp 7mo ago
    As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken. There is still this disconnection on how languages under ISO process work in the industry.
    - jonstewart 7mo ago
      The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.
      - pjmlp 7mo ago
        And you will be the one telling the losers that their compiler, operating systems and OS doesn't count? By the way this applies to the C language so beloved on this corner as well. As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).
  - munificent 7mo ago
    The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.
kprotty 7mo ago
I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1]. These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies. [0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a... [1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...
- ryanxsim 7mo ago
  I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
  - lionkor 7mo ago
    Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
    - bayindirh 7mo ago
      Seriously asking, where Go sits in this categorization?
      - shilgapira 7mo ago
        It's also a modern C. If you enjoy C and wish it was less verbose and more modern, try Go.
        bayindirh 7mo ago
        Thanks. I write some Go, and feel the same about it. I really enjoy it actually. Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard. Maybe gccrs will change that, IDK, yet.
sgt 7mo ago
> I know Bun's using zig to a degree of success, was wondering how the rest were doing. Just a degree of success?
ptrwis 7mo ago
You can fix you code 10 times you will fix it.
hansvm 7mo ago
It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day. Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.
steeve 7mo ago
hi, i'm the founder of https://github.com/zml/zml https://github.com/zml/zml, very happy with Zig
MrResearcher 7mo ago
Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib. Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well. Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development. We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.

throwaway17_17 7mo ago

Congratulations to the dev, a 30,000 line PR for a language compiler (and a very much non-trivial compiler) is a feat to be proud of. But a change of this magnitude is a serious bit of development and gave me pause. I understand both of the following: 1. Language development is a tricky subject, in general, but especially for those languages looking for wide adoption or hoping for ‘generational’ (program life span being measured in multiple decades) usage in infrastructure, etc. 2) Zig is a young-ish language, not at 1.0, and explicitly evolving as of the posting of TFA With those points as caveats, I find the casualness of the following (from the codeburg post linked on the devlog) surprising: ‘’’This branch changes the semantics of "uninstantiable" types (things like noreturn, that is, types which contain no values). I wasn't originally planning to do this here, but matching the semantics of master was pretty difficult because the existing semantics don't make much sense.’’’ I don’t know Zig’s particular strategy and terminology for language and compiler development, but I would assume the usage of ‘branch’ here implies this is not a change fully/formally adopted by the language but more a fully implemented proposal. Even if it is just a proposal for change, the large scale of the rewrite and clear implication that the author expects it to be well received strikes me as uncommon confidence. Changing the semantics of a language with any production use is nearly definitionally MAJOR, to just blithely state your PR changes semantics and proceed with no deep discussion (which could have previously happened, IDK) or serious justification or statements concerning the limited effect of those changes is not something I have experienced watching the evolution (or de-evolution) of other less ‘serious’ languages. Is this a “this dev” thing, a Zig thing, or am just out of touch with modern language (or even larger scale development) projects? Also, not particularly important or really significant to the overall thrust of TFA, but the author uses the phrase “modern Zig”, which given Zig’s age and seeming rate of change currently struck me as a very funny turn of phrase.

smj-edison 7mo ago
mlugg is one of the core contributors of Zig, and is a member of the Zig foundation iirc. They've been wanting to work on dependency resolution for a while now, so I'm really glad they're cleaning this up (I've been bitten before by unclear circular dependency errors). There's not a formal language spec yet, since it's moving pretty fast, but tbh I don't see the need for a standard, since that's not one of their goals currently.

patchnull 7mo ago

[flagged]

sethops1 7mo ago
AI slop. Get lost.

sidkshatriya 7mo ago

I am impressed by the achievements of the Zig team. I use the ghostty terminal emulator regularly -- it is built in Zig and it is super stable. It is a fantastic piece of software. This makes me feel that the underlying technology behind Zig is solid. But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description). This gives Zig very powerful meta programming abilities but is a pain because you don't know what kind of type "shapes" will be used in a particular piece of code. Zig is similar to C++ templates in some respects. This has a ripple effect everywhere. Rust generated documentation is very rich and explicit about what functions a structure supports (as each trait is explicitly enrolled and implemented). In Zig the dynamic nature of the code becomes a problem with autocomplete, documentation, LSP support, ...

Zanfa 7mo ago
> But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description). Do you happen to have a more specific example by any chance? I’d be interested in what this looks like in practice, because what you described sounds a bit like Go interfaces and from my understanding of Zig, there’s no direct equivalent to it, other than variations of fieldParentPtr.
- lukaslalinsky 7mo ago
  They are referring to `anytype`, which is a comptime construct telling the compiler that the parameter can be of any type and as long as the code compiles with the given value, it's good. It's an extremely useful thing, but unconstrained, it's essentially duck typing during compile time. People has been wanting some kind of trait/interface support to constrain it, but it's unlikely to happen.

deleted 7mo ago

[deleted]

ansi_c 7mo ago

[dead]

sesm 7mo ago

Instead of implementing a workaround for types as namespaces, wouldn't it better to explicitly add namespaces to the language?

Arch485 7mo ago
It's not so much a workaround as it is an elegance in design. In Zig, when you @import a file, that file is converted to a struct with comptime fields for all of the public members. Similarly, a "namespace" in Zig is just a nested struct with more fields. Usually it's just another import of something else. N.B.: Coffee hasn't reached my bloodstream yet; accuracy not guaranteed.
- peesem 7mo ago
  files aren't converted to structs on import, they _are_ structs (well, their contents are the inside of a struct declaration). also, public members don't become comptime fields? file structs are basically left as-is on import, nearly like you copy&pasted the file contents into a struct declaration
txdv 7mo ago
I think zig is striving for language minimalism, make it minimal as possible then if a feature optimized multiple places use cases benefit

lerno 7mo ago

It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years. There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics. To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is no expectation that Zig is trying to minimize upgrading problems. This is a cultural thing, it would be no real problem to be clear about deprecations, but in the Zig community it’s simply not valued. In fact it’s a source of pride to be able to adapt as fast as possible to the new changes. I like to talk about expectation management, and this is a great example of it. In discussions, it is often falsely argued that ”Zig is not 1.0 so breaks are expected” in order to motivate the frequent breaks. However, there are degrees to how you handle breaks, and Zig is clearly in the ”we don’t care to reduce the work”-camp. If someone is trying to get a more objective look at the Zig upgrade path, then it’s worth keeping in mind that the tradition in Zig is to offload all the work on the user. The argument, which is frequently voiced, is that ”breaking things will make the language get better and so it’s good that there are language breaks” It is certainly true that breaking changes are needed, but most people outside of the Zig community would expect it to be done with more care (deprecation paths etc) Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year. 10 years is the common point where languages go 1.0. However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0. This means that in the future, projects using Zig can still expect any libraries and applications to bitrot quickly if they are not constantly maintained. Putting this in contrast with Odin (9 years old) which is essentially 1.0 already and has been stable for several years. Maybe this also explains the difference in actual output. For example the number of games I know of written in Odin is somewhere between 5 to 10 times as many as Zig games. Now weighing in that Zig has maybe 5 or 10 times as many users, it means Odin users are somewhere between 20-100 times as likely to have written a playable game. There are several explanations as to why this is: we could discuss whether the availability of SDL, Raylib etc is easier on Odin (then why is Zig less friendly?), maybe more Odin has better programmers (then why do better programmers choose Odin over Zig), maybe it’s just easier to write resource intensive applications with Odin than Zig (then what do we make of Zig’s claim of optimality?) If we look past the excuses made for Zig (”it’s easy to fix breaks” ”it’s not 1.0”) and the hype (”Zig is much safer than C” ”Zig makes me so productive”) and compare with Odin in actual productivity, stability and compilation speed (neither C3 nor Odin requires 100s of GB of cache to compile in less than a second using LLVM) then Zig is not looking particularly good. Even things like build.zig, often touted as a great thing, is making it really hard for a Zig beginner (”to build your first Hello World, first understand this build script in non-trivial Zig”). Then for IDEs, suddenly something like just reading the configuration of what is going to be used for building is hidden behind an opaque Zig script. These trade-offs are rarely talked about, as both criticism and hype is usually based on surface rather than depth. Well, that’s long enough of a comment. To round it off I’d like to end on a positive note: I find the Zig community nice and welcoming. So if you’re trying Zig out (and better do that, don’t let others’ opinions - including mine - prevent you from trying things out) do so. If you want to evaluate Zig against competitors, I’d recommend comparing it to D, Odin, Jai and C3.

saritekin 7mo ago

[flagged]

postflopclarity 7mo ago
please don't use AI to write comments
deleted 7mo ago
[deleted]
nindalf 7mo ago
dang can we please ban any user that writes comments with AI?

king_geedorah 7mo ago

The kernel32 -> Ntdll changes are the most interesting thing to me here. A lot of the rationale is applicable also to the linux userspace APIs, especially errors in return at the kernel-userspace boundary vs GetLastError/errno in kernel32/libc. Of course on linux the "problem" is that libc and the kernel API are intimately intertwined and the former mandates using errno. I wonder how the pattern made its way into windows as well. That environment has never seemed to me to promote using libc.

simonask 7mo ago
The errno/GetLastError() pattern is a remnant from a time before threads were a thing. You could have multiple processes, but they were largely scheduled collaboratively (rather than preemptively). In that world, things like global variables are perfectly fine. But then we got first preemptive scheduling and threads, then actual multicore CPUs, so global variables became really dangerous. Thread locals are the escape hatch that carried these patterns into the 21st century, for better or worse.
- jlokier 7mo ago
  Indeed, and this change of philosophy shows up in the pthread (POSIX threads) API, which returns error values directly (as a negative integer) instead of setting the errno variable.
deleted 7mo ago
[deleted]

yowang 7mo ago

[dead]

ChrisSD 7mo ago

> Many projects including Chromium, boringssl, Firefox, and Rust call SystemFunction036 from advapi32.dll because it worked on versions older than Windows 8. That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chromium: https://github.com/chromium/chromium/blob/dc7016d1ef67e3e1281dce92bf27ed1f9743ea2f/base/rand_util_win.cc#L74 https://github.com/chromium/chromium/blob/dc7016d1ef67e3e128... > If [ProcessPrng] fails it returns NO_MEMORY in a BOOL (documented behavior is to never fail, and always return TRUE). From Windows 10 onward ProcessPrng will never fail. There's a whitepaper that gives the justification for this (https://aka.ms/win10rng https://aka.ms/win10rng): > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request... > For each user-mode process, we have a (buffered) base PRNG maintained by BCryptPrimitives.dll. When this DLL loads it requests a random seed from kernel mode (where it is produced by the per-CPU states) and seeds the process base PRNG. If this were to fail, BCryptPrimitive.dll fails to load, which in most cases causes the process to terminate. This behavior ensures that we never have to return an error code from the RNG system.

winterqt 7mo ago
(This is a response to a different devlog entry on the same page, not TFA.)
- ChrisSD 7mo ago
  Oh sorry, I thought this was just listing changes since the branch.

mlugg 7mo ago

Hi, author of this devlog here! Not to dismiss concerns about breaking language changes, but there seems to be a bit of a misconception here that this compiler change was highly breaking and will require significant effort from Zig users to update for. Perhaps I unintentionally gave that impression in the devlog or the PR writeup, apologies if so---but it's not the case! Although there were breaking changes in this patch, they were quite minor: most users are unlikely to hit them, and if they do then they're straightforward to deal with. For a concrete example, while testing this branch, I tried building ZLS (https://github.com/zigtools/zls/ https://github.com/zigtools/zls/). To do that, the only change I had to make was changing `.{}` to `.empty` in a couple of its dependencies (i.e. not even in ZLS itself!). This was needed because I removed some default values from `std.ArrayList` (so the change was in standard library code rather than the language). Those default values had actually already been deprecated (with intent to remove) for around a year, so this wasn't exactly a new change either. As another example, Andrew has updated Awebo (https://codeberg.org/awebo-chat/awebo https://codeberg.org/awebo-chat/awebo), a text and voice chat application, to the new version of Zig. Across Awebo's entire dependency tree (which includes various packages for graphics, audio, and probably some other stuff), the full set of necessary changes was: * Same as above, change `.{}` to `.empty` in a few places, due to removal of deprecated defaults * Add one extra `comptime` annotation to logic which was constructing an array at comptime * Append `orelse @alignOf(T)` onto an expression to deal with a newly-possible `null` case These are all trivial fixes which Zig developers would be able to do pretty much on autopilot upon seeing the compile errors. So, while there were a handful of small breaking changes, they don't seem to me like a particularly big deal (for a language where some level of breakage is still allowed). The main thing this PR achieved was instead a combination of bugfixes, and enhancements to existing features (particularly incremental compilation).

throwaway17_17 7mo ago
I made one of the comments that seems to be perceived a critical of the changes (I made a statement about the seemingly brief paragraph on changing semantics). As I replied to Andrew, I will tell you: the PR had a large amount of planning and implementation that seems of great quality. I certainly did not intend to discredit you or the obviously large amount of work you have done previously or on the change. I guess that will teach me to post without even more caveats.

sharyphil 7mo ago

Move 'ZIG'.

lerno 7mo ago

I just have to add another reflection: One thing that tends to be overlooked when discussing changes is the ecosystem effect of frequent changes. A language that breaks frequently doesn't just impose upgrade work on apps, but also discourages the creation of long-lived libraries and tools. Anything that sits between the language and the user (linters, bindings, frameworks, teaching material, tutorials etc) has to to some degree "chase the language" This means that the ecosystem will skew toward very actively maintained libraries and away from "write once then leave it alone" libs. And this the trade-off is reasonable during early language design, but it's worth acknowledging that it has real consequences for ecosystem growth. One should note that other newer languages have put significant effort into minimizing this churn, precisely to allow the latter type of ecosystem to also form. So it's kind of an experiment, and it will be interesting to see which approach ends up producing the larger ecosystem over time.

riidom 7mo ago
An example for this is the Blender addon ecosystem. Blender moves very fast, breaking API changes every few versions. Now I am not an addon developer myself, but from github issues I follow, changes are fairly often trivial to do. Yet, someone has to do them. Ideally it is the creator of the addon, sometimes it's the users who do it, when the addon is not maintained anymore (in case of trivial changes). It kinda works that way, but it also is some kind of gamble for the user. When you see a new addon (and a new addon developer), you can't know if they gonna stick to it or not. If you have to pay for the addon, it's more likely they maintain it, of course. But also not a guarantee.
bro45x 7mo ago
Zig's worth it though. I don't care for libraries that aren't maintained anyway. If they don't maintain it, it's just bad anyway. Why do you always nag about Zig. Stop shilling your C3 here.
- MintPaw 7mo ago
  This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable. But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good. Requiring every dependency to be constantly maintained is a massive drain on productivity.

burgerone 7mo ago

What makes zig special as a language? I have the impression that it has quite a large fan base here on HN but don't really hear any talks about it anywhere else.

portly 7mo ago
I can share mine. I am not sure if this connects with you because maybe you are more experienced. I'm DevOps writing boring Python microservices for €. I have no CS background and never did systems programming. However, writing Python always bothered me because there are so many layers between you and what's happening on the metal. For me, Django is the peak example of this, to me it feels almost like doing no code. It makes me very uncomfortable writing it. Then I heard about this new programming language Zig on YouTube and I just gave it a try. After using it for a few months, I really like it. I guess mostly because it is so explicit. It is almost like the language encourages you to think in terms of system design. Zig offers a lot of freedom so you can design the perfect tool for your problem. And somehow, it feels very effective for it. I think it is a blessing that there are few third party libraries for the same reason. For example. I am working on a tool to parse CIM (some XML standard). If I had to use Python for this, my solution would probably use the most popular xml parsing library and then go from there. Yawn. Instead, with Zig I started to think with a very fresh mind about the problem. I started thinking more from the first principles of the problem. And I got very excited again about programming. During my swimming practice or biking, I kept thinking about the design and how I can make it simpler and improving it by simply not doing certain busy work. I can't fully explain it. But the language gets you in that mindset. Maybe other system languages also offer this experience, Zig (marketing?) just happened to cross my paths at the right moment.
- Tadpole9181 7mo ago
  I'm sure it's not what you meant, but the argument "it makes me slower at my job and deliver less stable solutions, but I feel cool doing it" is not exactly a compelling endorsement.
  - troad 7mo ago

raphaelmolly8 7mo ago

[dead]

patchnull 7mo ago

[flagged]

xthunk 7mo ago

One thing I’ve noticed reading Zig discussions is that many semantics seem simple on their own but interactions can be subtle – like in the behavior fixed here. I wonder if this ends up similar to C++ template rules where the surface looks small but the edge cases accumulate over time.