12 ms·

Zig Roadmap 2024 [video]

65 points by YuukiRey 3y ago

skywal_l 3y ago
TLDW: Andrew talk about the financials, the bug bounty program, the versioning strategy and the two main objectives on the short/medium term: 1. Get rid of LLVM and 2. Improve compiler performance. Then there is a Q&A session.
- lr1970 3y ago
  He said release 0.12 will happen soon.
- speps 3y ago
  What's replacing LLVM? I didn't think LLVM was a problem, rather a necessary dependency to get all the optimization benefits, etc.
  - pbaam 3y ago
    They want to replace LLVM with their own backends. Zig's master branch can now be compiled without LLVM (and without CMake, see bootstrap.c) in x86 Linux because they implemented their own ELF linker and x86 code generation. It's explained in the talk why they want it: Most of the compile time is spent in LLVM, not in AST lowering or semantic analysis. Andrew also said that LLVM's coroutines weren't good enough to implement async/await.
    - MaxBarraclough 3y ago
      (Discussion of the LLVM-free compiler begins at 10:30 in the video.) As someone who hasn't been following this: improved compile-times seem achievable, but they surely can't hope to compete with LLVM in terms of opimisation, can they? Is the new backend intended to be used for quicker dev builds, or for final release builds too? From a look here [0] it seems to be the latter - full removal of LLVM for all builds - which surprises me. [0] https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
      - Laremere 3y ago
        It's a full removal of LLVM code being linked into the compiler. Currently Zig calls LLVM's API to build with it. Instead the compiler will gain the ability to emit LLVM IR into files. Those files can be passed to a separate install of LLVM to produce final machine code. As for the new backend vs LLVM, the new can be used for everything if it meets your needs. Initially LLVM is going to produce more optimized builds than Zig by itself can, but that is likely to change over time. LLVM isn't some magical blessing from the heavens, it's just software made by people. There's nothing besides effort and competence preventing another compiler matching its optimization performance. Plus, while a lot of research effort has been put into finding LLVM's optimizations, they've been found and can be copied.
        tialaramex 3y ago
        There is however no reason to imagine you can get similar optimizations yet go much faster. Some of the optimization problems are just plain hard, indeed the optimal choices are often Undecidable for non-trivial cases, so LLVM is already trading time for better results. I have other reasons not to like LLVM, but I don't like the habit of blaming LLVM for how slow your compiler is, and Zig isn't alone in doing that. The segue into optimisation was Andrew noting that there are too many bugs. I haven't seen Andrew speak often before, so maybe it was a joke I didn't get, but the impression I got reminded me of Herb Sutter's introduction of Cpp2 / CppFront his "New syntax" (a C++ successor language by another name). Herb gives genuine complaints people have about C++ but rather than explain why his proposal would fix them (it wouldn't) he just decides they're wrong and rewrites them, then explains how his proposal fixes these made up complaints instead. So instead of "It's much too unsafe" Herb decides the "real" problem is that it's not easy enough to write - see if it was easier you wouldn't have bugs right? An audience members even calls him out for that, but Herb is undeterred. Like I said, maybe it's just a joke and I didn't get it. But if Andrew seriously thinks that: Zig has too many bugs => Make compiler faster makes any sense that's a problem.
        mlugg 3y ago
        Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how long it takes to emit debug builds. Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file). I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation. It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+llvm+label%3Aupstream https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.
  - flohofwoe 3y ago
    A mix of own code and the Clang toolchain moved into an optional package. As far as I understand it, the ability to optimize via LLVM and compile C++ and ObjC code via Clang won't be lost, just moved out of the Zig compiler into a package, integrated via the build system. The ability to import C headers and compile C code will remain in the core compiler though.
  - jenadine 3y ago
    > What's replacing LLVM? AI? Just a LLM that convert Zig to optimized binary? /s
- deleted 3y ago
  [deleted]
levzettelin 3y ago
Didn't watch; will they implement RAII?
- boricj 3y ago
  As in C++'s constructors/destructors? That's against their stance on hidden control flow as stated on Zig's website.
- DrNosferatu 3y ago
  Zig has a “defer” keyword.
  - davikr 3y ago
    Is allocating without a subsequent `defer` a warning?
    - flohofwoe 3y ago
      How would you handle the valid case that a function returns a pointer to heap allocated memory? "Manual memory management" is exactly what the label says, it's "manual". What you usually do is group all allocated items with the same max lifetime in an arena allocator created somewhere up the call stack, and then defer-free the entire arena instead of each individual item. In real world code there's hardly a situation where each item requires its own lifetime tracking, instead they are usually lumped together with other items of a similar lifetime. Zig's GeneralPurposeAllocator also helps to catch typical memory-related issues at runtime (like leaks and dangling access), e.g. see: https://github.com/ziglang/zig/blob/master/lib/std/heap/general_purpose_allocator.zig https://github.com/ziglang/zig/blob/master/lib/std/heap/gene... Tagged-index-handles are also always an option to achieve spatial and temporal runtime memory safety at a higher level: https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
      - fatihpense 3y ago
        Yes, another valid case is passing heap-allocated pointers between WASM guest and host. I have an example here if anyone is interested: https://github.com/fatihpense/zig-wasm-string-and-struct https://github.com/fatihpense/zig-wasm-string-and-struct As a newbie in low-level programming, being able to return "heap-allocated pointer" instead of "stack-allocated pointer to a struct in heap" was a challenge at first :) But I love how everything is explicit in Zig.
lionkor 3y ago
[flagged]
- avgcorrection 3y ago
  We should stop linking this at every non-opportunity. In fact ban the number 927 just to be safe.
- quikoa 3y ago
  Are you suggesting we shouldn't invent more programming languages and/or more will make things worse?
bsaul 3y ago
Very impressed by zig ambitions, but i found it very peculiar that their focus seems to be going "down" the stack ( aka, compiler infrastructure rewriting) rather than "up" (stdlib and lib ecosystem). Am i wrong to feel a bit worried by this direction ? Is the team large enough do both at the same time ?
- jitl 3y ago
  The farther up the stack, the easier it is for the community to contribute. The compiler infra has been the major investment they’ve made for a few years, and it’s starting to show dividends but most of the benefit is still on the table there.
diimdeep 3y ago
Comparatively > Incremental rebuilds cause a lot of compilation problems, bugs, and errors. Incremental rebuilds are also slow due to the amount of in between files generated between builds. Jai will contain no incremental rebuild steps. All will be compiled in one fresh compilation. This means that the compiler will need to run fast with high performance. The eventual goal is to compile a 1 million lines of code in 1 second, but as of right now, the compiler can only do 250,000 lines in 1 second. https://github.com/Jai-Community/Jai-Community-Library/wiki/Philosophy-of-Jai#incremental-rebuilds https://github.com/Jai-Community/Jai-Community-Library/wiki/...
- mlugg 3y ago
  We have written proof-of-concepts for how incremental rebuilds will work in the Zig compiler, which can achieve incredible speed. Let's say you change a single constant value in a function (e.g. you change a string). The rebuild process looks something like this: * We re-run the `AstGen` pass on the modified file, which is responsible for generating our first IR. `AstGen` is pretty fast - on a ~38k line file, it takes 0.25s on my laptop, so we can guess that for a ~1k line file (much more typical) it'll take under 10ms. * We identify changes and do some logic on the dependency graph of functions and declarations to figure out what might be outdated. In this case, we would find that only the changed function is outdated. * We re-run semantic analysis (`Sema`) on that function. For a small function, this is a trivial amount of time, probably on the order of a single millisecond. This generates our second IR. * We re-run `CodeGen` on the updated IR for this function. This will take a similar amount of time to `Sema`, perhaps around 1ms. * We directly perform the necessary patches to the final binary; appending the new machine code to the binary, updating the GOT entry to refer to it, and updating any modified debug info. This whole process is on the order of milliseconds. This is not hypothetical: this is just how long the compiler pipeline takes to do certain things. We have a lot of work to do with tying these bits together for incremental rebuilds to work, but I do not predict any big losses compared to this performance estimate.
  - vitaminCPP 3y ago
    Insight full comments. Thanks for sharing.
Voultapher 3y ago
How about improving documentation? Last year I tried Zig and the documentation was abysmal. The majority of standard library functions had no documentation. The sparingly few examples that exist on the webpage didn't work with the current Zig version and more. I say that as a Zig sponsor who wants to see research and innovation in the systems programming space. Documentation is maybe not as sexy as replacing LLVM with your own backend, but sorely needed.
- YuukiRey 3y ago
  It might be a bit early to invest in the documentation of APIs and implementations that are still subject to significant change. For the stable parts of the stdlib this would indeed be a very welcome change and would also lower the barrier for people to use Zig.
- Laremere 3y ago
  As a small tip, I have found that the [src] links in the documentation that go to the source to be very useful. Zig prioritizes readability, and often I can find the answer quickly when the documentation is lacking. That said, yeah it's not great. This talk gave some good reasons for doing things in the order they are. Spec and documentation are best done after the target has stopped moving, and it's simply going to be awhile until that happens.
- flohofwoe 3y ago
  There's still too much change in the stdlib APIs to make 'tutorial style documentation' worth the effort, because they will most likely be outdated within a couple of weeks or months. There's an auto-generated documentation here (with many parts still 'under-documented': https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/ ...but the best option is usually to just look right into the stdlib source code to figure out how things are supposed to work (IME stdlib code is generally easy to read, and easy to find - and with the VSCode ZLS plugin you can also directly lookup the stdlib source code by clicking on a stdlib type or function call). For larger-scale changes, keep track of Github issues and PRs (those are usually extensively documented) or ask around on the Discord, folk are actually very helpful there.
deleted 3y ago
[deleted]

65 points by YuukiRey 3y ago

TLDW: Andrew talk about the financials, the bug bounty program, the versioning strategy and the two main objectives on the short/medium term: 1. Get rid of LLVM and 2. Improve compiler performance. Then there is a Q&A session.

lr1970 3y ago
He said release 0.12 will happen soon.
speps 3y ago
What's replacing LLVM? I didn't think LLVM was a problem, rather a necessary dependency to get all the optimization benefits, etc.
- pbaam 3y ago
  They want to replace LLVM with their own backends. Zig's master branch can now be compiled without LLVM (and without CMake, see bootstrap.c) in x86 Linux because they implemented their own ELF linker and x86 code generation. It's explained in the talk why they want it: Most of the compile time is spent in LLVM, not in AST lowering or semantic analysis. Andrew also said that LLVM's coroutines weren't good enough to implement async/await.
  - MaxBarraclough 3y ago
    (Discussion of the LLVM-free compiler begins at 10:30 in the video.) As someone who hasn't been following this: improved compile-times seem achievable, but they surely can't hope to compete with LLVM in terms of opimisation, can they? Is the new backend intended to be used for quicker dev builds, or for final release builds too? From a look here [0] it seems to be the latter - full removal of LLVM for all builds - which surprises me. [0] https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270
    - Laremere 3y ago
      It's a full removal of LLVM code being linked into the compiler. Currently Zig calls LLVM's API to build with it. Instead the compiler will gain the ability to emit LLVM IR into files. Those files can be passed to a separate install of LLVM to produce final machine code. As for the new backend vs LLVM, the new can be used for everything if it meets your needs. Initially LLVM is going to produce more optimized builds than Zig by itself can, but that is likely to change over time. LLVM isn't some magical blessing from the heavens, it's just software made by people. There's nothing besides effort and competence preventing another compiler matching its optimization performance. Plus, while a lot of research effort has been put into finding LLVM's optimizations, they've been found and can be copied.
      - tialaramex 3y ago
        There is however no reason to imagine you can get similar optimizations yet go much faster. Some of the optimization problems are just plain hard, indeed the optimal choices are often Undecidable for non-trivial cases, so LLVM is already trading time for better results. I have other reasons not to like LLVM, but I don't like the habit of blaming LLVM for how slow your compiler is, and Zig isn't alone in doing that. The segue into optimisation was Andrew noting that there are too many bugs. I haven't seen Andrew speak often before, so maybe it was a joke I didn't get, but the impression I got reminded me of Herb Sutter's introduction of Cpp2 / CppFront his "New syntax" (a C++ successor language by another name). Herb gives genuine complaints people have about C++ but rather than explain why his proposal would fix them (it wouldn't) he just decides they're wrong and rewrites them, then explains how his proposal fixes these made up complaints instead. So instead of "It's much too unsafe" Herb decides the "real" problem is that it's not easy enough to write - see if it was easier you wouldn't have bugs right? An audience members even calls him out for that, but Herb is undeterred. Like I said, maybe it's just a joke and I didn't get it. But if Andrew seriously thinks that: Zig has too many bugs => Make compiler faster makes any sense that's a problem.
        mlugg 3y ago
        Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how long it takes to emit debug builds. Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file). I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation. It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+llvm+label%3Aupstream https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.
- flohofwoe 3y ago
  A mix of own code and the Clang toolchain moved into an optional package. As far as I understand it, the ability to optimize via LLVM and compile C++ and ObjC code via Clang won't be lost, just moved out of the Zig compiler into a package, integrated via the build system. The ability to import C headers and compile C code will remain in the core compiler though.
- jenadine 3y ago
  > What's replacing LLVM? AI? Just a LLM that convert Zig to optimized binary? /s
deleted 3y ago
[deleted]

levzettelin 3y ago

Didn't watch; will they implement RAII?

boricj 3y ago
As in C++'s constructors/destructors? That's against their stance on hidden control flow as stated on Zig's website.
DrNosferatu 3y ago
Zig has a “defer” keyword.
- davikr 3y ago
  Is allocating without a subsequent `defer` a warning?
  - flohofwoe 3y ago
    How would you handle the valid case that a function returns a pointer to heap allocated memory? "Manual memory management" is exactly what the label says, it's "manual". What you usually do is group all allocated items with the same max lifetime in an arena allocator created somewhere up the call stack, and then defer-free the entire arena instead of each individual item. In real world code there's hardly a situation where each item requires its own lifetime tracking, instead they are usually lumped together with other items of a similar lifetime. Zig's GeneralPurposeAllocator also helps to catch typical memory-related issues at runtime (like leaks and dangling access), e.g. see: https://github.com/ziglang/zig/blob/master/lib/std/heap/general_purpose_allocator.zig https://github.com/ziglang/zig/blob/master/lib/std/heap/gene... Tagged-index-handles are also always an option to achieve spatial and temporal runtime memory safety at a higher level: https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
    - fatihpense 3y ago
      Yes, another valid case is passing heap-allocated pointers between WASM guest and host. I have an example here if anyone is interested: https://github.com/fatihpense/zig-wasm-string-and-struct https://github.com/fatihpense/zig-wasm-string-and-struct As a newbie in low-level programming, being able to return "heap-allocated pointer" instead of "stack-allocated pointer to a struct in heap" was a challenge at first :) But I love how everything is explicit in Zig.

lionkor 3y ago

[flagged]

avgcorrection 3y ago
We should stop linking this at every non-opportunity. In fact ban the number 927 just to be safe.
quikoa 3y ago
Are you suggesting we shouldn't invent more programming languages and/or more will make things worse?

bsaul 3y ago

Very impressed by zig ambitions, but i found it very peculiar that their focus seems to be going "down" the stack ( aka, compiler infrastructure rewriting) rather than "up" (stdlib and lib ecosystem). Am i wrong to feel a bit worried by this direction ? Is the team large enough do both at the same time ?

jitl 3y ago
The farther up the stack, the easier it is for the community to contribute. The compiler infra has been the major investment they’ve made for a few years, and it’s starting to show dividends but most of the benefit is still on the table there.

diimdeep 3y ago

Comparatively > Incremental rebuilds cause a lot of compilation problems, bugs, and errors. Incremental rebuilds are also slow due to the amount of in between files generated between builds. Jai will contain no incremental rebuild steps. All will be compiled in one fresh compilation. This means that the compiler will need to run fast with high performance. The eventual goal is to compile a 1 million lines of code in 1 second, but as of right now, the compiler can only do 250,000 lines in 1 second. https://github.com/Jai-Community/Jai-Community-Library/wiki/Philosophy-of-Jai#incremental-rebuilds https://github.com/Jai-Community/Jai-Community-Library/wiki/...

mlugg 3y ago
We have written proof-of-concepts for how incremental rebuilds will work in the Zig compiler, which can achieve incredible speed. Let's say you change a single constant value in a function (e.g. you change a string). The rebuild process looks something like this: * We re-run the `AstGen` pass on the modified file, which is responsible for generating our first IR. `AstGen` is pretty fast - on a ~38k line file, it takes 0.25s on my laptop, so we can guess that for a ~1k line file (much more typical) it'll take under 10ms. * We identify changes and do some logic on the dependency graph of functions and declarations to figure out what might be outdated. In this case, we would find that only the changed function is outdated. * We re-run semantic analysis (`Sema`) on that function. For a small function, this is a trivial amount of time, probably on the order of a single millisecond. This generates our second IR. * We re-run `CodeGen` on the updated IR for this function. This will take a similar amount of time to `Sema`, perhaps around 1ms. * We directly perform the necessary patches to the final binary; appending the new machine code to the binary, updating the GOT entry to refer to it, and updating any modified debug info. This whole process is on the order of milliseconds. This is not hypothetical: this is just how long the compiler pipeline takes to do certain things. We have a lot of work to do with tying these bits together for incremental rebuilds to work, but I do not predict any big losses compared to this performance estimate.
- vitaminCPP 3y ago
  Insight full comments. Thanks for sharing.

Voultapher 3y ago

How about improving documentation? Last year I tried Zig and the documentation was abysmal. The majority of standard library functions had no documentation. The sparingly few examples that exist on the webpage didn't work with the current Zig version and more. I say that as a Zig sponsor who wants to see research and innovation in the systems programming space. Documentation is maybe not as sexy as replacing LLVM with your own backend, but sorely needed.

YuukiRey 3y ago
It might be a bit early to invest in the documentation of APIs and implementations that are still subject to significant change. For the stable parts of the stdlib this would indeed be a very welcome change and would also lower the barrier for people to use Zig.
Laremere 3y ago
As a small tip, I have found that the [src] links in the documentation that go to the source to be very useful. Zig prioritizes readability, and often I can find the answer quickly when the documentation is lacking. That said, yeah it's not great. This talk gave some good reasons for doing things in the order they are. Spec and documentation are best done after the target has stopped moving, and it's simply going to be awhile until that happens.
flohofwoe 3y ago
There's still too much change in the stdlib APIs to make 'tutorial style documentation' worth the effort, because they will most likely be outdated within a couple of weeks or months. There's an auto-generated documentation here (with many parts still 'under-documented': https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/ ...but the best option is usually to just look right into the stdlib source code to figure out how things are supposed to work (IME stdlib code is generally easy to read, and easy to find - and with the VSCode ZLS plugin you can also directly lookup the stdlib source code by clicking on a stdlib type or function call). For larger-scale changes, keep track of Github issues and PRs (those are usually extensively documented) or ask around on the Discord, folk are actually very helpful there.

deleted 3y ago

[deleted]