6 ms·

Self-hosted x86 back end is now default in debug mode

289 points by brson 1y ago

xmorse 1y ago
This could be the greatest programming language development of the last 10 years. Finally a language that compiles fast and is fast at runtime too.
- ArtixFox 1y ago
  theres a long way to go but its better than nothing!
- pjmlp 1y ago
  Turbo Pascal 5.5 for MS-DOS, one example out of many others from those days, running on lame IBM PCs. If anything, it is a generation rediscovering what we have lost.
- 0points 1y ago
  > Finally a language that compiles fast and is fast at runtime too. We been enjoying golang for the last decade and then some ;-)
  - xmorse 1y ago
    that's why i added fast at runtime too
    - 0points 1y ago
      Enlighten me, what's so slow about the golang runtime?
- rurban 1y ago
  We are talking zig here, not lua
treeshateorcs 1y ago
so, a helloworld program (`zig init`) is 9.3MB compiled. compared to `-Doptimize=ReleaseSmall` 7.6KB that is huge (more than 1000 times larger)
- AndyKelley 1y ago
  Indeed, good observation. Another observation is that 82% of that is debug info. -OReleaseSmall -fno-strip produces a 580K executable, while -ODebug -fstrip produces a 1.4M executable. zig's x86 backend makes for a significantly better debugging experience with this zig-aware lldb fork: https://github.com/ziglang/zig/wiki/LLDB-for-Zig https://github.com/ziglang/zig/wiki/LLDB-for-Zig I don't recall whether it supports stepping through comptime logic at the moment; that was something we discussed recently.
  - 9d 1y ago
    [flagged]
  - treeshateorcs 1y ago
    is it naive to expect the new backend to release -OReleaseSmall binaries as small as llvm in the future?
    - squeek502 1y ago
      As far as I'm aware, using the self-hosted backend for anything other than Debug mode is a goal, but a far-future goal. I believe the most relevant links are https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270 and https://github.com/orgs/ziglang/projects/2/views/1?pane=issue&itemId=75955123 https://github.com/orgs/ziglang/projects/2/views/1?pane=issu... (as you can see, nothing is concrete yet, just vague mentions of optimization passes)
Retro_Dev 1y ago
As far as I know, Zig has a bunch of things in the works for a better development experience. Almost every day there's something being worked on - like https://github.com/ziglang/zig/pull/24124 https://github.com/ziglang/zig/pull/24124 just now. I know that Zig had some plans in the past to also work on hot code swapping. At this rate of development, I wouldn't be surprised if hot code swapping was functional within a year on x86_64. The biggest pain point I personally have with Zig right now is the speed of `comptime` - The compiler has a lot of work to do here, and running a brainF** DSL at compile-time is pretty slow (speaking from experience - it was a really funny experiment). Will we have improvements to this section of the compiler any time soon? Overall I'm really hyped for these new backends that Zig is introducing. Can't wait to make my own URCL (https://github.com/ModPunchtree/URCL https://github.com/ModPunchtree/URCL) backend for Zig. ;)
- sali0 1y ago
  URCL is sending me down a rabbithole. Haven't looked super deeply yet, but the most hilarious timeline would be that an IR built for Minecraft becomes a viable compilation target for languages.
- bgthompson 1y ago
  Hot code swapping will be huge for gamedev. The idea that Zig will basically support it by default with a compiler flag is wild. Try doing that, clang.
  - Retro_Dev 1y ago
    Totally agree with that - although even right now zig is excellent for gamedev, considering it's performant, uses LLVM (in release modes), can compile REALLY FAST (in debug mode), it has near-seamless C integration, and the language itself is really pleasant to use (my opinion).
    - sgt 1y ago
      Is Zig actually being used for real game dev already?
bgthompson 1y ago
This is already such a huge achievement, yet as the devlog notes, there is plenty more to come! The idea of a compiler modifying only the parts of a binary that it needs to during compilation is simultaneously refreshing and totally wild, yet now squarely within reach of the Zig project. Exciting times ahead.
BrouteMinou 1y ago
[flagged]
- 9d 1y ago
  All languages are safe if you use them correctly, and unsafe if you don't. But Rust is notorious for catching memory errors that could easily be exploited. Does Zig do this too now, or did I miss something?
  - ArtixFox 1y ago
    it doesnt catch temporal memory errors, but what it offers currently is still better than most of its competitors [defer, explicit allocators, custom allocators with integrated support for valgrind and friends,etc]. Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig. There are some quite interesting demos that can even go beyond basic borrow checking and straight into refinement types. Zig's integrated build system will make it easy to add these tools into any project. Or maybe the zig compiler itself will integrate it. the future is quite hopeful for zig but it is probably not one that is restricted to just borrow checking. I personally think it can go beyond and slowly become what C+FramaC or Ada is now for the critical systems world.
    - SkiFire13 1y ago
      > Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig. Parsing is almost irrelevant for static analysis. The most important thing is how restricted are the semantics, which allow you to make assumptions and restrict the behaviour of the program to a small enough set that can be understood. From what I can see Zig is not much different than C on this front, and potentially is even harder to analyze due to `comptime`
      - ArtixFox 1y ago
        my bad for using the word "parse", "working with the language" is better to explain my intent, the language is minimal [unfortunately it follows llvm's semantics but its planned to change]. Comptime cannot affect runtime, it cannot do syscalls and cannot go on forever. Due to how limited it is, we can simply let it evaluate and then work with the code that is left. It is still a better method than either writing text macros[which are also fine but are a pain to use] or using proc macros which can do syscalls and open up a whole new can of worms. In languages that dont have any metaprogramming support, you must rely on some thing of a generator which is most probably not provided by the compiler vendor and verifying and trusting it is now the responsibility of the user. Now you are left with things like template metaprogramming where higher and more complex techniques are not supported by the standard or any verification tools and you must trust the compiler to take the right decision regarding the code and having no tools support its verification. Out of all the options for metaprogramming for a language that must also be verification friendly, comptime is probably one of the best solutions, if not the best. Zig not being much different from C in this aspect is quite an unexpected compliment because of plethora of work done for its verification. Those same tools can be modified to be used for zig but you would not have to worry about much beyond logic and memory allocation verification [there exists a prototype for both].
9d 1y ago
> For a larger project like the Zig compiler itself, it takes the time down from 75 seconds to 20 seconds. We’re only just getting started. Excited to see what he can do with this. He seems like a really smart guy. What's the package management look like? I tried to get an app with QuickJS + SDL3 working, but the mess of C++ pushed me to Rust where it all just works. Would be glad to try it out in Zig too.
- stratts 1y ago
  Package management in Zig is more manual than Rust, involving fetching the package URL using the CLI, then importing the module in your build script. This has its upsides - you can depend on arbitrary archives, so lots of Zig packages of C libraries are just a build script with a dependency on a unmodified tarball release. But obviously it's a little trickier for beginners. SDL3 has both a native Zig wrapper: https://github.com/Gota7/zig-sdl3 https://github.com/Gota7/zig-sdl3 And a more basic repackaging on the C library/API: https://github.com/castholm/SDL https://github.com/castholm/SDL For QuickJS, the only option is the C API: https://github.com/allyourcodebase/quickjs-ng https://github.com/allyourcodebase/quickjs-ng Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API
  - LAC-Tech 1y ago
    It's also worth pointing out that the Zig std library covers a lot more than the rust one. No need for things like rustix, rand, hashbrown, and a few others I always have to add whenever I do rust stuff.
    - nindalf 1y ago
      You add hashbrown as an explicit dependency? The standard library HashMap is a re-export of hashbrown. Doesn’t it work for you?
      - LAC-Tech 1y ago
9d 1y ago
> And we’re looking at aarch64 next - work that is expected to be accelerated thanks to our new Legalize pass. Sorry, what?
- garbagepatch 1y ago
  It seems to be Zig's equivalent to this part of LLVM: https://llvm.org/docs/GlobalISel/Legalizer.html https://llvm.org/docs/GlobalISel/Legalizer.html
- nektro 1y ago
  afaict its a new pass that transforms Air generated from Sema into Air understood by a particular backend, since theyre not all at the same level of maturity
- WalterBright 1y ago
  I'm about halfway done writing an AArch64 backend for the dmd D compiler. Of course, the gdc and ldc compilers already support that.
  - 9d 1y ago
    Every few years I look into D and read it and think it's really good and want to write something in it. But then I come across comments on HN that make me feel like it's not good enough compared to something like C++ or Rust. I know I should ignore those, and I do like having a GC, so D seems like maybe a better Go. But one thing I always put ahead of everything else is developer convenience, for example, autocompletion and hover-docs in VS Code. I assume D has these, but I also assume that it's not as well supported as it is in Rust, mostly thanks to some sort of principle that probably has a name by now, where the more hype a language has, the more support its entire ecosystem has, regardless of whether it's a good language or not. Kind of like how writing TypeScript for the web is now amazing to work with, being a zeroeth-class citizen in VS Code (soon to be lowered to first-class after the Go rewrite), simply because JavaScript is the only native language the web speaks. Anyway, if D has wrapper libs for SDL3 and V8, decent docs, works well on both Win&Mac, and has good enough VS Code support, I'd be glad to give it a shot.
VWWHFSfQ 1y ago
I'm interested in Zig but kind of discouraged by the 30 pages of open issues mentioning "segfault" on their Github tracker. It's disheartening for a systems programming language being developed in the 21st century.
- AndyKelley 1y ago
  I see 40 pages in rust-lang/rust. Are you sure this heuristic is measuring what you think it's measuring?
  - VWWHFSfQ 1y ago
    Oh I wasn't comparing to Rust. But just a quick glance between the two repos shows a pretty big difference between the nature of the "segfault" issues reported. yikes... https://github.com/ziglang/zig/issues/23556 https://github.com/ziglang/zig/issues/23556
    - steveklabnik 1y ago
      Every mature compiler (heck, project of any kind) has thousands of bugs open. It’s just a poor metric.
      - VWWHFSfQ 1y ago
        Yep and like I said, I'm interested in Zig. But it's still somewhat discouraging as a C replacement just because it seems to still have all the same problems but without the decades of tools and static analyzers to help out. But I'm keeping an eye on it.
        stratts 1y ago
        What's the state of the art here? Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).
mirekrusin 1y ago
Sounds like Julia should consider switching to Zig to get considerable performance gains. I remember authors feeling uneasy with each llvm release worrying about performance degradations.
- bobbylarrybobby 1y ago
  Isn't LLVM considered part of Julia’s public API? You've got macros like @code_llvm that actually give you IR
- patagurbon 1y ago
  Julia is effectively hard locked to LLVM. Large swathes of the ecosystem rely on the presence of LLVM either for intrinsics, autodiff (Enzyme) or gpu compilation. Nevermind Base and Core. The compiler is fairly retargetable, this is an active area of work. So it’s maybe possible in the future to envision zig as an alternative compiler for fragments of the language.
- jakobnissen 1y ago
  That could be a way to get compile times down, but I think there is still much to do on the Julia side. Such as a more fine grained compile cache, better tooling to prevent i validations, removal of the world splitting optimisation, more use of multithreading in the compiler, automatic precompilation of concrete signatures, and generation of lazier code which hot-swaps in code when it is compiled.
- eigenspace 1y ago
  People say this about every compiler backend that shows up. I have serious doubts, but if someone wants to take it on as a project it'd be pretty interesting to see what happens.
foresto 1y ago
Isn't this one of the preconditions for bringing async/await back to Zig? https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-of-async-in-zig https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...
- geodel 1y ago
  Reading the link, it seems to me async is never coming back or at least not till 2028.
  - mlugg 1y ago
    I don't understand how you reached this conclusion. Nothing is decided for sure, but the plan is most likely to re-introduce stackless coroutines as a set of lower-level primitives [0], and support implementing the planned `std.Io` abstraction [1] using them. The usage isn't quite as "pretty" as our old async/await syntax, but this approach sidesteps a lot of design problems, allows applications to seamlessly switching between different async implementations (e.g. stackless vs stackful), and simplifies the eventual language specification. It's true that we're not doing this work right now, but that doesn't mean async is "never coming back", nor that you'll be waiting "till 2028". [0]: https://github.com/ziglang/zig/issues/23446 https://github.com/ziglang/zig/issues/23446 [1]: https://github.com/ziglang/zig/blob/async-await-demo/lib/std/Io.zig https://github.com/ziglang/zig/blob/async-await-demo/lib/std...
    - geodel 1y ago
      Sure, I was just tempering expectations. In large project there are always tons of competing priorities competing. Considering many things needed before async and not all of them may be complete before other important work like incremental compilation, new backends etc. It maybe a while to see async.
- AndyKelley 1y ago
  I've got that stuff all figured out, should have some interesting updates for everyone over the next 2-3 months. Been redoing I/O from the ground up - mostly standard library work.
fjnfndnf 1y ago
That's just the backend swapped out, all the analysis and type passes are still present or is it also reducing verifications? While a quick compile cycle is beneficial for productivity, this is only the case if it also includes fast tests Thus wouldn't it be easier to just interpret zig for debug? That would also solve the issue of having to repeat the work for each target
- ArtixFox 1y ago
  Only backend has been swapped out. The tests will be fast too yes. There is no real need to add an interpreter. Having custom backend s means that while currently it is being used for debug, far in future it might be able to compete with llvm for speed. Adding an interpreter would be useless as u would still need to write a custom backend. The problem is llvms slowness for debug and release.
- flohofwoe 1y ago
  > Thus wouldn't it be easier to just interpret zig for debug The whole point of debug mode is debuggability, and hooking up such an interpreted Zig to a standard debugger like gbd or lldb probably isn't trivial, since those expect an executable with DWARF debug info. PS: also acceptable debug-mode performance is actually very important, especially in areas like game development.
WhereIsTheTruth 1y ago
I said it for D and Nature, and every other languages that comes with its own backend, we all have a duty to support projects that tries to not depend on LLVM, compiler R&D has stagnated because of LLVM, far too many languages chose to depend on it, far too many people don't value fast iteration time, or perhaps they grew to not expect any better? Fast iteration time with incremental compilation and binary patching, good debugging should be the expectation for new languages, not something niche or "too hard to do"
- pjmlp 1y ago
  Indeed, that is one of the few things I find positive on Go, being bootstraped, and not dependent on LLVM.
- flohofwoe 1y ago
  OTH LLVM caused an explosion of languages created by individuals which immediately had competitive performance and a wide range of supported platforms (Zig being one of them!). The entire realtime rendering industry is essentially built on top of LLVM (or forks of LLVM), even Microsoft have switched their shader compiler to LLVM and is now (finally) starting to upstream their code. The compiler infrastructure of most game consoles is Clang based (except Xbox which - so far - sticks to MSVC). So all in all, LLVM has been a massive success, especially for bootstrapping new things.
candrewlee 1y ago
This is awesome for Zig, I think this direction is gonna be a primary differentiator when comparing to Rust. And hey, I wrote a lot of the rendering code for that perf analyzer. Always fun to see your work show up on the internet. https://github.com/andrewrk/poop https://github.com/andrewrk/poop
- ctz 1y ago
  > This is awesome for Zig, I think this direction is gonna be a primary differentiator when comparing to Rust. FWIW there is a similar effort for Rust using cranelift: <https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift>
whinvik 1y ago
As a complete noob what is the advantage of Zig over other languages? I believe it's a more modern C but what is the modern part?
- flohofwoe 1y ago
  [flagged]
- dns_snek 1y ago
  A few things off the top of my head: - an integrated build system that doesn't use multiple separate arcane tools and languages - slices with known length in Zig vs arrays in C (buffer overflows) - an explicit optional type that you're forced to check, null pointers aren't* allowed (*when they are, for integrating with C code, the type makes that obviously clear) - enums, tagged unions and enforced exhaustive checks on "switch" expressions - error handling is explicit, functions return an error (an enum value) that the caller must handle in some way. In C the function might return some integer to indicate an error which you're allowed to completely ignore. What is missing is a standard way of returning some data with an error that's built into the language (the error-struct-passed-through-parameters pattern feels bolted on, there should be special syntax for it) - "defer", "errdefer" blocks for cleanup after function returns or errors - comptime code generation (in Zig) instead of macros, type reflection (@typeInfo and friends) - caller typically makes decisions about how and where memory is allocated by passing an allocator to libraries - easier (at least for a noob) to find memory leaks by just using GeneralPurposeAllocator As someone who's always used higher level languages since I started programming and strongly disliked many of the arcane, counterintuitive things about C and surrounding ecosystem whenever I tried it, Zig finally got me into systems programming in a way that I find enjoyable.
d3ckard 1y ago
In no way I want to sound demanding/ungrateful, since Zig is free work, but I am mostly interested in some realistic 1.0 timeline. Zig is pretty much exactly what I would want from low level language, I'm just waiting for it to be stable. And, of course, kudos - I really appreciate minimalist design philosophy of Zig.
- ArtixFox 1y ago
  I am pretty sure serious projects like tigerbeetle freeze a version [most probably latest release] and use it. nightly is for experimental stuff.
xmorse 1y ago
Will macOS also get support for the self hosted back end at some point?
- meepmorp 1y ago
  that work is in progress, though the self-hosted backend is x86 only for now.
  - xmorse 1y ago
    x86 runs fine in Apple Silicon too thanks to Rosetta
    - mlugg 1y ago
      I believe (although I won't claim to know details) that Rosetta is unable to handle the code our self-hosted backend emit. I don't know whether it's related to the machine code or the Mach-O object, nor do I know in what way it breaks. Feel free to try it out of course!-- my understanding could be wrong.
      - xmorse 1y ago
        Next time you try Rosetta and it fails can you open an issue with the error messages? I think this task would be perfect for o3 to work on, you basically have to browse hundreds of issues on GitHub and find other people that got into the same problem
txdv 1y ago
Is there a guide of how to build zig in 20 seconds? (for fast development cycles) I would like to contribute but faced difficulties because the compilation for all stage1/2/3 combined took a lot of time
- mlugg 1y ago
  The whole "stage1/2/3" jazz is about our bootstrap process; that is, the way you get a Zig compiler starting from nothing but a C compiler. This is a tricky problem because of the fact that the Zig compiler is written in Zig. The bootstrap is unfortunately quite slow to run, for two main reasons: * We want the final Zig binary it produces to be optimized using LLVM, and LLVM is incredibly slow. * The start of the bootstrap chain involves a kinda-weird step where we translate a WASM binary to a gigantic C file which we then build; this takes a while and makes the first Zig compiler in the process ("stage1"/"zig1") particularly slow. Luckily, you very rarely need to bootstrap! Most of the time, you can simply download a recent Zig binary from ziglang.org. The only reason the bootstrap process exists is essentially so you can make that tarballs yourself (useful if you want to link against system LLVM, or optimize for your native CPU, or you are a distro package maintainer). You don't actually need to do it to develop the compiler; you just need to get a relatively recent build of Zig to use to build the compiler, and it's fine to grab that from ziglang.org (or a mirror). Once you have that, it's as simple as `zig build -Dno-lib` in the Zig repository root. The `-Dno-lib` option just prevents the build script from copying the contents of the `lib/` directory into your installation prefix (zig-out by default); that's desirable to avoid when working on the compiler because it's a lot of files so can take a while to copy. You can also add `-Ddev=x86_64-linux` to build a smaller subset of compiler functionality, speeding up the build more. For the other `-Ddev` options, look at the fields of `Env` in `src/dev.zig`.
deleted 1y ago
[deleted]

289 points by brson 1y ago

This could be the greatest programming language development of the last 10 years. Finally a language that compiles fast and is fast at runtime too.

ArtixFox 1y ago
theres a long way to go but its better than nothing!
pjmlp 1y ago
Turbo Pascal 5.5 for MS-DOS, one example out of many others from those days, running on lame IBM PCs. If anything, it is a generation rediscovering what we have lost.
0points 1y ago
> Finally a language that compiles fast and is fast at runtime too. We been enjoying golang for the last decade and then some ;-)
- xmorse 1y ago
  that's why i added fast at runtime too
  - 0points 1y ago
    Enlighten me, what's so slow about the golang runtime?
rurban 1y ago
We are talking zig here, not lua

treeshateorcs 1y ago

so, a helloworld program (`zig init`) is 9.3MB compiled. compared to `-Doptimize=ReleaseSmall` 7.6KB that is huge (more than 1000 times larger)

AndyKelley 1y ago
Indeed, good observation. Another observation is that 82% of that is debug info. -OReleaseSmall -fno-strip produces a 580K executable, while -ODebug -fstrip produces a 1.4M executable. zig's x86 backend makes for a significantly better debugging experience with this zig-aware lldb fork: https://github.com/ziglang/zig/wiki/LLDB-for-Zig https://github.com/ziglang/zig/wiki/LLDB-for-Zig I don't recall whether it supports stepping through comptime logic at the moment; that was something we discussed recently.
- 9d 1y ago
  [flagged]
- treeshateorcs 1y ago
  is it naive to expect the new backend to release -OReleaseSmall binaries as small as llvm in the future?
  - squeek502 1y ago
    As far as I'm aware, using the self-hosted backend for anything other than Debug mode is a goal, but a far-future goal. I believe the most relevant links are https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270 and https://github.com/orgs/ziglang/projects/2/views/1?pane=issue&itemId=75955123 https://github.com/orgs/ziglang/projects/2/views/1?pane=issu... (as you can see, nothing is concrete yet, just vague mentions of optimization passes)

Retro_Dev 1y ago

As far as I know, Zig has a bunch of things in the works for a better development experience. Almost every day there's something being worked on - like https://github.com/ziglang/zig/pull/24124 https://github.com/ziglang/zig/pull/24124 just now. I know that Zig had some plans in the past to also work on hot code swapping. At this rate of development, I wouldn't be surprised if hot code swapping was functional within a year on x86_64. The biggest pain point I personally have with Zig right now is the speed of `comptime` - The compiler has a lot of work to do here, and running a brainF** DSL at compile-time is pretty slow (speaking from experience - it was a really funny experiment). Will we have improvements to this section of the compiler any time soon? Overall I'm really hyped for these new backends that Zig is introducing. Can't wait to make my own URCL (https://github.com/ModPunchtree/URCL https://github.com/ModPunchtree/URCL) backend for Zig. ;)

sali0 1y ago
URCL is sending me down a rabbithole. Haven't looked super deeply yet, but the most hilarious timeline would be that an IR built for Minecraft becomes a viable compilation target for languages.
bgthompson 1y ago
Hot code swapping will be huge for gamedev. The idea that Zig will basically support it by default with a compiler flag is wild. Try doing that, clang.
- Retro_Dev 1y ago
  Totally agree with that - although even right now zig is excellent for gamedev, considering it's performant, uses LLVM (in release modes), can compile REALLY FAST (in debug mode), it has near-seamless C integration, and the language itself is really pleasant to use (my opinion).
  - sgt 1y ago
    Is Zig actually being used for real game dev already?

bgthompson 1y ago

This is already such a huge achievement, yet as the devlog notes, there is plenty more to come! The idea of a compiler modifying only the parts of a binary that it needs to during compilation is simultaneously refreshing and totally wild, yet now squarely within reach of the Zig project. Exciting times ahead.

BrouteMinou 1y ago

[flagged]

9d 1y ago
All languages are safe if you use them correctly, and unsafe if you don't. But Rust is notorious for catching memory errors that could easily be exploited. Does Zig do this too now, or did I miss something?
- ArtixFox 1y ago
  it doesnt catch temporal memory errors, but what it offers currently is still better than most of its competitors [defer, explicit allocators, custom allocators with integrated support for valgrind and friends,etc]. Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig. There are some quite interesting demos that can even go beyond basic borrow checking and straight into refinement types. Zig's integrated build system will make it easy to add these tools into any project. Or maybe the zig compiler itself will integrate it. the future is quite hopeful for zig but it is probably not one that is restricted to just borrow checking. I personally think it can go beyond and slowly become what C+FramaC or Ada is now for the critical systems world.
  - SkiFire13 1y ago
    > Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig. Parsing is almost irrelevant for static analysis. The most important thing is how restricted are the semantics, which allow you to make assumptions and restrict the behaviour of the program to a small enough set that can be understood. From what I can see Zig is not much different than C on this front, and potentially is even harder to analyze due to `comptime`
    - ArtixFox 1y ago
      my bad for using the word "parse", "working with the language" is better to explain my intent, the language is minimal [unfortunately it follows llvm's semantics but its planned to change]. Comptime cannot affect runtime, it cannot do syscalls and cannot go on forever. Due to how limited it is, we can simply let it evaluate and then work with the code that is left. It is still a better method than either writing text macros[which are also fine but are a pain to use] or using proc macros which can do syscalls and open up a whole new can of worms. In languages that dont have any metaprogramming support, you must rely on some thing of a generator which is most probably not provided by the compiler vendor and verifying and trusting it is now the responsibility of the user. Now you are left with things like template metaprogramming where higher and more complex techniques are not supported by the standard or any verification tools and you must trust the compiler to take the right decision regarding the code and having no tools support its verification. Out of all the options for metaprogramming for a language that must also be verification friendly, comptime is probably one of the best solutions, if not the best. Zig not being much different from C in this aspect is quite an unexpected compliment because of plethora of work done for its verification. Those same tools can be modified to be used for zig but you would not have to worry about much beyond logic and memory allocation verification [there exists a prototype for both].

9d 1y ago

> For a larger project like the Zig compiler itself, it takes the time down from 75 seconds to 20 seconds. We’re only just getting started. Excited to see what he can do with this. He seems like a really smart guy. What's the package management look like? I tried to get an app with QuickJS + SDL3 working, but the mess of C++ pushed me to Rust where it all just works. Would be glad to try it out in Zig too.

stratts 1y ago
Package management in Zig is more manual than Rust, involving fetching the package URL using the CLI, then importing the module in your build script. This has its upsides - you can depend on arbitrary archives, so lots of Zig packages of C libraries are just a build script with a dependency on a unmodified tarball release. But obviously it's a little trickier for beginners. SDL3 has both a native Zig wrapper: https://github.com/Gota7/zig-sdl3 https://github.com/Gota7/zig-sdl3 And a more basic repackaging on the C library/API: https://github.com/castholm/SDL https://github.com/castholm/SDL For QuickJS, the only option is the C API: https://github.com/allyourcodebase/quickjs-ng https://github.com/allyourcodebase/quickjs-ng Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API
- LAC-Tech 1y ago
  It's also worth pointing out that the Zig std library covers a lot more than the rust one. No need for things like rustix, rand, hashbrown, and a few others I always have to add whenever I do rust stuff.
  - nindalf 1y ago
    You add hashbrown as an explicit dependency? The standard library HashMap is a re-export of hashbrown. Doesn’t it work for you?
    - LAC-Tech 1y ago

9d 1y ago

> And we’re looking at aarch64 next - work that is expected to be accelerated thanks to our new Legalize pass. Sorry, what?

garbagepatch 1y ago
It seems to be Zig's equivalent to this part of LLVM: https://llvm.org/docs/GlobalISel/Legalizer.html https://llvm.org/docs/GlobalISel/Legalizer.html
nektro 1y ago
afaict its a new pass that transforms Air generated from Sema into Air understood by a particular backend, since theyre not all at the same level of maturity
WalterBright 1y ago
I'm about halfway done writing an AArch64 backend for the dmd D compiler. Of course, the gdc and ldc compilers already support that.
- 9d 1y ago
  Every few years I look into D and read it and think it's really good and want to write something in it. But then I come across comments on HN that make me feel like it's not good enough compared to something like C++ or Rust. I know I should ignore those, and I do like having a GC, so D seems like maybe a better Go. But one thing I always put ahead of everything else is developer convenience, for example, autocompletion and hover-docs in VS Code. I assume D has these, but I also assume that it's not as well supported as it is in Rust, mostly thanks to some sort of principle that probably has a name by now, where the more hype a language has, the more support its entire ecosystem has, regardless of whether it's a good language or not. Kind of like how writing TypeScript for the web is now amazing to work with, being a zeroeth-class citizen in VS Code (soon to be lowered to first-class after the Go rewrite), simply because JavaScript is the only native language the web speaks. Anyway, if D has wrapper libs for SDL3 and V8, decent docs, works well on both Win&Mac, and has good enough VS Code support, I'd be glad to give it a shot.

VWWHFSfQ 1y ago

I'm interested in Zig but kind of discouraged by the 30 pages of open issues mentioning "segfault" on their Github tracker. It's disheartening for a systems programming language being developed in the 21st century.

AndyKelley 1y ago
I see 40 pages in rust-lang/rust. Are you sure this heuristic is measuring what you think it's measuring?
- VWWHFSfQ 1y ago
  Oh I wasn't comparing to Rust. But just a quick glance between the two repos shows a pretty big difference between the nature of the "segfault" issues reported. yikes... https://github.com/ziglang/zig/issues/23556 https://github.com/ziglang/zig/issues/23556
  - steveklabnik 1y ago
    Every mature compiler (heck, project of any kind) has thousands of bugs open. It’s just a poor metric.
    - VWWHFSfQ 1y ago
      Yep and like I said, I'm interested in Zig. But it's still somewhat discouraging as a C replacement just because it seems to still have all the same problems but without the decades of tools and static analyzers to help out. But I'm keeping an eye on it.
      - stratts 1y ago
        What's the state of the art here? Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).

mirekrusin 1y ago

Sounds like Julia should consider switching to Zig to get considerable performance gains. I remember authors feeling uneasy with each llvm release worrying about performance degradations.

bobbylarrybobby 1y ago
Isn't LLVM considered part of Julia’s public API? You've got macros like @code_llvm that actually give you IR
patagurbon 1y ago
Julia is effectively hard locked to LLVM. Large swathes of the ecosystem rely on the presence of LLVM either for intrinsics, autodiff (Enzyme) or gpu compilation. Nevermind Base and Core. The compiler is fairly retargetable, this is an active area of work. So it’s maybe possible in the future to envision zig as an alternative compiler for fragments of the language.
jakobnissen 1y ago
That could be a way to get compile times down, but I think there is still much to do on the Julia side. Such as a more fine grained compile cache, better tooling to prevent i validations, removal of the world splitting optimisation, more use of multithreading in the compiler, automatic precompilation of concrete signatures, and generation of lazier code which hot-swaps in code when it is compiled.
eigenspace 1y ago
People say this about every compiler backend that shows up. I have serious doubts, but if someone wants to take it on as a project it'd be pretty interesting to see what happens.

foresto 1y ago

Isn't this one of the preconditions for bringing async/await back to Zig? https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-of-async-in-zig https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...

geodel 1y ago
Reading the link, it seems to me async is never coming back or at least not till 2028.
- mlugg 1y ago
  I don't understand how you reached this conclusion. Nothing is decided for sure, but the plan is most likely to re-introduce stackless coroutines as a set of lower-level primitives [0], and support implementing the planned `std.Io` abstraction [1] using them. The usage isn't quite as "pretty" as our old async/await syntax, but this approach sidesteps a lot of design problems, allows applications to seamlessly switching between different async implementations (e.g. stackless vs stackful), and simplifies the eventual language specification. It's true that we're not doing this work right now, but that doesn't mean async is "never coming back", nor that you'll be waiting "till 2028". [0]: https://github.com/ziglang/zig/issues/23446 https://github.com/ziglang/zig/issues/23446 [1]: https://github.com/ziglang/zig/blob/async-await-demo/lib/std/Io.zig https://github.com/ziglang/zig/blob/async-await-demo/lib/std...
  - geodel 1y ago
    Sure, I was just tempering expectations. In large project there are always tons of competing priorities competing. Considering many things needed before async and not all of them may be complete before other important work like incremental compilation, new backends etc. It maybe a while to see async.
AndyKelley 1y ago
I've got that stuff all figured out, should have some interesting updates for everyone over the next 2-3 months. Been redoing I/O from the ground up - mostly standard library work.

fjnfndnf 1y ago

That's just the backend swapped out, all the analysis and type passes are still present or is it also reducing verifications? While a quick compile cycle is beneficial for productivity, this is only the case if it also includes fast tests Thus wouldn't it be easier to just interpret zig for debug? That would also solve the issue of having to repeat the work for each target

ArtixFox 1y ago
Only backend has been swapped out. The tests will be fast too yes. There is no real need to add an interpreter. Having custom backend s means that while currently it is being used for debug, far in future it might be able to compete with llvm for speed. Adding an interpreter would be useless as u would still need to write a custom backend. The problem is llvms slowness for debug and release.
flohofwoe 1y ago
> Thus wouldn't it be easier to just interpret zig for debug The whole point of debug mode is debuggability, and hooking up such an interpreted Zig to a standard debugger like gbd or lldb probably isn't trivial, since those expect an executable with DWARF debug info. PS: also acceptable debug-mode performance is actually very important, especially in areas like game development.

WhereIsTheTruth 1y ago

I said it for D and Nature, and every other languages that comes with its own backend, we all have a duty to support projects that tries to not depend on LLVM, compiler R&D has stagnated because of LLVM, far too many languages chose to depend on it, far too many people don't value fast iteration time, or perhaps they grew to not expect any better? Fast iteration time with incremental compilation and binary patching, good debugging should be the expectation for new languages, not something niche or "too hard to do"

pjmlp 1y ago
Indeed, that is one of the few things I find positive on Go, being bootstraped, and not dependent on LLVM.
flohofwoe 1y ago
OTH LLVM caused an explosion of languages created by individuals which immediately had competitive performance and a wide range of supported platforms (Zig being one of them!). The entire realtime rendering industry is essentially built on top of LLVM (or forks of LLVM), even Microsoft have switched their shader compiler to LLVM and is now (finally) starting to upstream their code. The compiler infrastructure of most game consoles is Clang based (except Xbox which - so far - sticks to MSVC). So all in all, LLVM has been a massive success, especially for bootstrapping new things.

candrewlee 1y ago

This is awesome for Zig, I think this direction is gonna be a primary differentiator when comparing to Rust. And hey, I wrote a lot of the rendering code for that perf analyzer. Always fun to see your work show up on the internet. https://github.com/andrewrk/poop https://github.com/andrewrk/poop

ctz 1y ago
> This is awesome for Zig, I think this direction is gonna be a primary differentiator when comparing to Rust. FWIW there is a similar effort for Rust using cranelift: <https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift>

whinvik 1y ago

As a complete noob what is the advantage of Zig over other languages? I believe it's a more modern C but what is the modern part?

flohofwoe 1y ago
[flagged]
dns_snek 1y ago
A few things off the top of my head: - an integrated build system that doesn't use multiple separate arcane tools and languages - slices with known length in Zig vs arrays in C (buffer overflows) - an explicit optional type that you're forced to check, null pointers aren't* allowed (*when they are, for integrating with C code, the type makes that obviously clear) - enums, tagged unions and enforced exhaustive checks on "switch" expressions - error handling is explicit, functions return an error (an enum value) that the caller must handle in some way. In C the function might return some integer to indicate an error which you're allowed to completely ignore. What is missing is a standard way of returning some data with an error that's built into the language (the error-struct-passed-through-parameters pattern feels bolted on, there should be special syntax for it) - "defer", "errdefer" blocks for cleanup after function returns or errors - comptime code generation (in Zig) instead of macros, type reflection (@typeInfo and friends) - caller typically makes decisions about how and where memory is allocated by passing an allocator to libraries - easier (at least for a noob) to find memory leaks by just using GeneralPurposeAllocator As someone who's always used higher level languages since I started programming and strongly disliked many of the arcane, counterintuitive things about C and surrounding ecosystem whenever I tried it, Zig finally got me into systems programming in a way that I find enjoyable.

d3ckard 1y ago

In no way I want to sound demanding/ungrateful, since Zig is free work, but I am mostly interested in some realistic 1.0 timeline. Zig is pretty much exactly what I would want from low level language, I'm just waiting for it to be stable. And, of course, kudos - I really appreciate minimalist design philosophy of Zig.

ArtixFox 1y ago
I am pretty sure serious projects like tigerbeetle freeze a version [most probably latest release] and use it. nightly is for experimental stuff.

xmorse 1y ago

Will macOS also get support for the self hosted back end at some point?

meepmorp 1y ago
that work is in progress, though the self-hosted backend is x86 only for now.
- xmorse 1y ago
  x86 runs fine in Apple Silicon too thanks to Rosetta
  - mlugg 1y ago
    I believe (although I won't claim to know details) that Rosetta is unable to handle the code our self-hosted backend emit. I don't know whether it's related to the machine code or the Mach-O object, nor do I know in what way it breaks. Feel free to try it out of course!-- my understanding could be wrong.
    - xmorse 1y ago
      Next time you try Rosetta and it fails can you open an issue with the error messages? I think this task would be perfect for o3 to work on, you basically have to browse hundreds of issues on GitHub and find other people that got into the same problem

txdv 1y ago

Is there a guide of how to build zig in 20 seconds? (for fast development cycles) I would like to contribute but faced difficulties because the compilation for all stage1/2/3 combined took a lot of time

mlugg 1y ago
The whole "stage1/2/3" jazz is about our bootstrap process; that is, the way you get a Zig compiler starting from nothing but a C compiler. This is a tricky problem because of the fact that the Zig compiler is written in Zig. The bootstrap is unfortunately quite slow to run, for two main reasons: * We want the final Zig binary it produces to be optimized using LLVM, and LLVM is incredibly slow. * The start of the bootstrap chain involves a kinda-weird step where we translate a WASM binary to a gigantic C file which we then build; this takes a while and makes the first Zig compiler in the process ("stage1"/"zig1") particularly slow. Luckily, you very rarely need to bootstrap! Most of the time, you can simply download a recent Zig binary from ziglang.org. The only reason the bootstrap process exists is essentially so you can make that tarballs yourself (useful if you want to link against system LLVM, or optimize for your native CPU, or you are a distro package maintainer). You don't actually need to do it to develop the compiler; you just need to get a relatively recent build of Zig to use to build the compiler, and it's fine to grab that from ziglang.org (or a mirror). Once you have that, it's as simple as `zig build -Dno-lib` in the Zig repository root. The `-Dno-lib` option just prevents the build script from copying the contents of the `lib/` directory into your installation prefix (zig-out by default); that's desirable to avoid when working on the compiler because it's a lot of files so can take a while to copy. You can also add `-Ddev=x86_64-linux` to build a smaller subset of compiler functionality, speeding up the build more. For the other `-Ddev` options, look at the fields of `Env` in `src/dev.zig`.

deleted 1y ago

[deleted]