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 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) backend for Zig. ;)
For comptime perf improvements, I know what needs to be done - I even started working on a branch a long time ago. Unfortunately, it is going to require reworking a lot of the semantic analysis code. Something that absolutely can, should, and will be done, but is competing with other priorities.
I am not sure, but why can't C,Rust and Zig with others (like Ada,Odin etc.) and of course C++ (how did I forget it?) just coexist.
Not sure why but I was definitely getting some game of thrones vibes from your comment and I would love to see some competition but I don't know, Just code in whatever is productive to you while being systems programming language I guess.
But I don't know low level languages so please, take my words at 2 cents.
I am just watching the Game of Throne series right now, so this comment sounds funnier than it should to me :D.
The fight for the Iron Throne, lots of self-proclaimed kings trying to take it... C is like King Joffrey, Rust is maybe Robb Stark?! And Zig... probably princess Daenerys with her dragons.
The industry has the resources to sustain maybe two and a half proper IDEs with debuggers, profilers etc.. So much as we might wish otherwise, language popularity matters. The likes of LSP mitigate this to a certain extent, but at the moment they only go so far.
That's where extensible IDEs like VSCode (and with it the Language Server Protocol and Debug Adapter Protocol) come in.
It's not perfect yet, but I can do C/C++/ObjC, Zig, Odin, C3, Nim, Rust, JS/TS, Python, etc... development and debugging all in the same IDE, and even within the same project.
For Virgil I went through three different compile-time interpreters. The first walked a tree-like IR that predated SSA. Then, after SSA, I designed a linked-list-like representation specifically for interpretation speed. After dozens of little discrepancies between this custom interpreter and compile output, I finally got rid of it and wrote an interpreter that works directly on the SSA intermediate representation. In the worst case, the SSA interpreter is only 2X slower than the custom interpreter. In the best case, it's faster, and saves a translation step. I feel it is worth it because of the maintenance burden and bugs.
It's a funny question because, as far as I'm aware, Zig Software Foundation is the only organization among its peers that spends the bulk of its revenue directly paying contributors for their time - something I'm quite proud of.
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.
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).
Yes, at a huge cost. That only works on Microsoft platforms.
MSVC++ is a nice compiler, sure, but it's not GCC or Clang. It's very easy to have a great feature set when you purposefully cut down your features to the bare minimum. It's like a high-end restaurant. The menu is concise and small and high quality, but what if I'm allergic to shellfish?
GCC and Clang have completely different goals, and they're much more ambitious. The upside of that is that they work on a lot of different platforms. The downside is that the quality of features may be lower, or some features may be missing.
I ended up switching from Zig to C# for a tiny game project because C# already supports cross-platform hot reload by default. (It’s just `dotnet watch`.) Coupled with cross-compilation, AOT compilation and pretty good C interop, C# has been great so far.
That is basically what they do when using Lua, Python, C#, Java, but with less parenthesis, which apparently are too scary for some folks, moving from print(x) to (print x).
There was a famous game with Lisp scripting, Abuse, and Naughty Dog used to have Game Oriented Assembly Lisp.
I had exactly the same title in mind, remember my very young self being in shock when I learned that it was lisp. If you didn't look under the hood you'd never be able to tell, it just worked.
Is comptime slowness really an issue? I'm building a JSON-RPC library and heavily relying on comptime to be able to dispatch a JSON request to arbitrary function. Due to strict static typing, there's no way to dynamically dispatch to a function with arbitrary parameters in runtime. The only way I found was figuring the function type mapping during compile time using comptime. I'm sure it will blow up the code size with additional copies of the comptimed code with each arbitrary function.
Yes, last time I checked, Zig's comptime was 20x slower than interpreted Python. Parsing a non-trivial JSON file at comptime is excrutiatingly slow and can take minutes.
I would argue that it's not meaningful to do so for larger files with comptime as there doesn't seem to be a need for parsing JSON like the target platform would (comptime emulates it) - I expect it to be independent. You're also not supposed to do I/O using comptime, and @embedFile kind of falls under that. I suppose it would be better to write a build.zig for this particularly use case, which I think would then also be able to run fast native code?
Is it easy to build out a custom backend? I haven't looked at it yet but I'd like to try some experiments with that -- to be specific, I think that I can build out a backend that will consume AIR and produce a memory safety report. (it would identify if you're using undefined values, stack pointer escape, use after free, double free, alias xor mut)
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.
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.
> 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.
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.
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
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.
Can’t speak for the op but there’s a number of high performance interfaces that avoid redundant computations that are only available directly from hashbrown.
Yes that’s exactly it. If speed is a priority and the input is trusted, change the hasher to something faster like ahash. The ahash crate makes this easy.
You too! Yeah I think that was a great call. I took inspiration from D for sure when aiming for this milestone that we reached today.
Some people say you should use an old computer for development to help you write faster code. I say you should use a new computer for development, and write the fastest code you possibly can by exploiting all the new CPU instructions and optimizing for newer caching characteristics.
I'm still in the camp of using computers our users tend to have.
Also, self-compile times are strongly related to how much code there is in the compiler, not just the compile speed.
I also confess to being a bit jaded on this. I've been generating code from 8086 processors to the latest. Which instructions and combinations are faster is always flip-flopping around from chip to chip. So I leave it to the gdc/ldc compilers for the top shelf speed, and just try to make the code gen bulletproof and do a solid job.
Working on the new AArch64 has been quite fun. I'll be doing a presentation on it later in the summer. My target machine is a Raspberry Pi, which is a great machine.
Having the two code generators side by side also significantly increased the build times, because it's a lot more code being compiled.
Fair enough, and yeah I hear you on the compilation cost of all the targets. We don't have aarch64 yet but in addition to x86_64 we do have an LLVM backend, a C backend, a SPIR-V backend, WebAssembly backend, RISC-V backend, and sparc backend. All that plus the stuff I mentioned earlier in 15s on a modern laptop.
I considered a C backend at one time, but C is not expressive enough. The generated code would be ugly. For example, exception handling. D's heavy reliance on common blocks in the object code is another issue. C doesn't support nested functions (static links). And so on.
Some users want a C backend, not for maintainability reasons, but for the ability to compile on platforms that have nothing but a C compiler. The maintainability or aesthetics of the C is irrelevant, it's like another intermediate representation.
I bet it would be easier to write a code gen for such platforms than to wrassal generated C code and work around the endless problems.
Anyhow, one of the curious features of D is its ability to translate C code to D code. Curious as it was never intentionally designed, it was discovered by one of our users.
D has the ability to create a .di file from a .d file, which is analogous to writing a .h file from a .c file. When D gained the ability to compile C files, you just ask it to create a .di file, and voila! the C code translated to D!
I think it would be a good idea to have some kind of "speedbump" tool that makes your software slower, but in a way where optimizing it would also optimize the faster version.
I don't know whether this is technically feasible, maybe you could run it on CPUs with good power management and force them to underclock or something.
Do you have any metrics on which parts of the whole compiler, std, package manager, etc. take the longest to compile?
How much does comptime slowness affect the total build time?
Well, one interesting number is what happens when you limit the compiler to this feature set:
* Compilation front-end (tokenizing/parsing, IR lowering, semantic analysis)
* Our own ("self-hosted") x86_64 code generator
* Our own ("self-hosted") ELF linker
...so, that's not including the LLVM backend and LLD linker integration, the package manager, `zig build`, etc. Building this subset of the compiler (on the branch which the 15 second figure is from) takes around 9 seconds. So, 6 seconds quicker.
This is essentially a somewhat-educated guess, so it could be EXTREMELY wrong, but of those 6s, I would imagine that around 1-2 are spent on all the other codegen backends and linkers (they aren't too complex and most of them are fairly incomplete), and probably a good 3s or so are from package management, since that pulls in HTTP, TLS, zip+tar, etc. TLS in particular does bring in some of our std.crypto code which sometimes sucks up more compile time than it really should. The remaining few seconds can be attributed to some "everything else" catch-all.
Amusingly, when I did some slightly more in-depth analysis of compiler performance some time ago, I discovered that most of the compiler's time -- at least during semantic analysis -- is spent analyzing different calls to formatted printing (since they're effectively "templated at compile time" in Zig, so the compiler needs to do a non-trivial amount of work for every different-looking call to something like `std.log.info`). That's not actually hugely unreasonable IMO, because formatted printing is a super common operation, but it's an example of an area we could improve on (both in the compiler itself, and in the standard library by simplifying and speeding up `std.fmt`). This is one example of a case where `comptime` execution is a big contributor to compile times.
However, aside from that one caveat of `std.fmt`, I would say that `comptime` slowness isn't a huge deal for many projects. Really, it depends how much they use `comptime`. You can definitely feel the limited speed of `comptime` execution if you use it heavily (e.g. try to parse a big file at `comptime`). However, most codebases are more restrained in their use of `comptime`; it's like a spice, a bit is lovely, but you don't want to overdo it! As with any kind of metaprogramming, overuse of `comptime` can lead to horribly unreadable code, and many major Zig projects have a pretty tasteful approach to using `comptime` in the right places. So for something like the Zig compiler, the speed of `comptime` execution honestly doesn't factor in that much (aside from that `std.fmt` caveat discussed above). `comptime` is very closely tied in to general semantic analysis (things like type checking) in Zig's design, so we can't really draw any kind of clear line, but on the PR I'm taking these measurements against, the threading actually means that even if semantic analysis (i.e. `comptime` execution plus more stuff) were instantaneous, we wouldn't see a ridiculous performance boost, since semantic analysis is now running in parallel to code generation and linking, and those three phases are faiiirly balanced right now in terms of speed.
In general (note that I am biased, since I'm a major contributor to the project!), I find that the Zig compiler is honestly a fair bit faster than people give it credit for. Like, it might sound pretty awful that (even after these improvements), building a "Hello World" takes (for me) around 0.3s -- but unlike C (where libc is precompiled and just needs to be linked, so the C compiler literally has to handle only the `main` you wrote), the Zig compiler is actually freshly building standard library code to handle, for instance, debug info parsing and stack unwinding in the case of a panic (code which is actually sorta complicated!). Right now, you're essentially getting a clean build of these core standard library components every time you build your Zig project (this will be improved upon in the future with incremental compilation). We're still planning to make some huge improvements to compilation speed across the board of course -- as Andrew says, we're really only just getting started with the x86_64 backend -- but I think we've already got something pretty decently fast.
We used to have such fast compile times with Turbo Pascal, and other dialects, Modula-2, Oberon dialects, across 16 bit and early 32 bit home computers.
Then everything went south, with the languages that took over mainstream computing.
Not to disagree with you, but even C++ is going through great efforts to improve compile-times through C++20 modules and C++23 standard library modules (import std;). Although no compiler fully supports both, you can get an idea of how they can improve compile-times with clang and libc++
$ # No modules
$ clang++ -std=c++23 -stdlib=libc++ a.cpp # 4.8s
$ # With modules
$ clang++ -std=c++23 -stdlib=libc++ --precompile -o std.pcm /path/to/libc++/v1/std.cppm # 4.6s but this is done once
$ clang++ -std=c++23 -stdlib=libc++ -fmodule-file=std=std.pcm b.cpp # 1.5s
a.cpp and b.cpp are equivalent but b.cpp does `import std;` and a.cpp imports every standard C++ header file (same thing as import std, you can find them in libc++' std.cppm).
Notice that this is an extreme example since we're importing the whole standard library and is actually discouraged [^1]. Instead you can get through the day with just these flags: `-stdlib=libc++ -fimplicit-modules -fimplicit-module-maps` and of course -std=c++20 or later, no extra files/commands required! but you are only restricted to doing import <vector>; and such, no import std.
[^1]: non-standard headers like `bits/stdc++.h` which does the same thing (#including the whole standard library) is what is actually discouraged because a. non-standard and b. compile-times, but I can see `import std` solving these two and being encouraged once it's widely available!
Agreed, I would say the main problem is lack of focus on developer productivity.
Ok, the goalpost has moved on with what -O0 is expected to deliver in machine code quality, lets then have something like -ffast-compile, or interpreter/jit as alternative toolchain in the box.
Practical example from D land, compile D with dmd during development, use gdc or ldc for release.
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"
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.
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.
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.
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.
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.
- 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.
> 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.
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.
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.
Do developers actually need anything more than assembly?
When choosing a new language (and ecosystem) in which to invest my time, I'm more likely to pick one that's versatile than one that struggles outside of a niche. Even with a background in processes, threads, manual event loops and callbacks, I find that higher level concurrency features make my life easier in enough different situations that first-class support for them is now fairly high on my shopping list.
Do I actually need a language with something resembling coroutines? No; I got by for decades with C and C++. But I want it. It makes me more productive and helps me to keep my code simpler, both of which are valuable to me. These days, I have found myself walking away from languages for being weak in this area.
Keeping Zig simple and close to C seems the most beneficial. Something that can be used everywhere that C is currently used. Otherwise it moves from systems programming language into applications programming.
IMO there are plenty of cases where you don't need to sqeeze every little drop of performance by going all in with epoll/io_uring directly, but you still want to handle 10k+ concurrent connections more effectively than with threads
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".
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.
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`.
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.
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
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.
Zig is not a memory safe language and does not attempt to prevent its users from shooting themselves in the leg; it tries to make those unsafe actions explicit and simple, unlike something like C++ that drowns you in complexity, but if you really want to do pointer wrangling and using memory after freeing it, zig allows you to do it.
This design philosophy should lead to countless segfaults that are the result of Zig working as designed. It also relegates Zig to the small niche of projects in modern programming where performance and developer productivity are more important than resilience and correctness.
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.
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.
It is my opinion that even if Zig were nothing more than a syntactical tweak of C, it would be preferable over C. C has a lot of legacy cruft that can't go away, and decades of software built with poor practices and habits. The status-quo in Zig is evolving to help mitigate these issues. One obvious example that sets Zig apart from C is error handling built into the language itself.
Can you be more precise? Memory safety does not only affect C programs and - despite people repeating this over and over - I do not believe it is true that it is actually harder to build safe programs in C compared to many other languages. Ada and Rust have certainly some advantage, but I think also this is exaggerated.
Memory corruption caused by lack of bounds checking, or vocabulary types like the ones provided by SDS and glib.
Microsoft had to come up with SAL during Windows XP SP2, Apple with -fbounds-safety alongside Safe C dialect for iBoot firmware, Oracle with ADI on Solaris/SPARC, Apple's ARM PAC extension, ARM and Microsoft's collaboration on Pluton and CHERI Morello, Apple, Microsoft, Google and Samsung's collaboration on ARM's MTE.
Lots of money being spent on R&D, for something WG14 considers exaggerated.
Those extensions are mostly to be able to enhance safety of legacy code though and not necessary when writing new code that is safe. But it is only the later that is relevant when comparing to new alternative languages.
Where can we find examples of such newly written C code that is memory safe, given that language features that would make it possible are only now under discussion for future standards, after governments and industry pressure?
Basically any code that does not use pointer arithmetic or raw pointer dereferences and instead puts string handling and buffer management behind abstractions.
The new feature we will put in are not to enable safe programming, but to make it more convenient and to make safety demonstrable.
And I wish there was actually some real industry interest to pushing this forward. Industry seems more interested into claiming this an unfixable problem and we all have to switch to Rust, which gives them another decade of punting the problems with existing code.
I could help with searching some public examples if you really do not know any code that uses safe string abstractions in C. But my original aim was to understand what specific "legacy cruft" in C is seen as problematic, and why its presence requires an entirely language to fix. So far, I did not get a good answer to this. I certainly do know some legacy cruft I want to see go but its presence does not prevent me from writing bounds-safe code.
WG14 is a very small number of volunteers. It would help if the industry would actually invest development resources for safety on the compiler / language side and in cleaning up legacy code.
Exactly, there are very few pearls of best practices in C, and those that exist, are probably in high integrity computing, with the relevant certification costs.
When all major OS vendors, some of whom are also compiler vendors, see more return into investment, contributing their money to alternative language foundations, or open source projects, than sending their employees to either WG14, or WG21, it is kind of clear ISO isn't going the way they would like to.
I would not call this an exaggeration, rather not listening.
Additionally, it would not surprise me if one of Zig, Odin, Rust eventually started popping up on console DevKits, or Khronos standards as well.
I don't know. WG21 is very big. WG14 is very small, so it is different. But in neither there is ISO going in some direction. Whoever shows up can influence the standard. Some of my proposals towards safety were opposed by compiler vendors because they do not want to put up too much pressure on their customer upgrading their legacy code. But of course, rewriting the code in another language would be much more effort than maintaining it... So I think the true answer is that nobody want to invest in maintenance of legacy code. But this will increasingly also be a problem for other languages once they are not young anymore.
Im pretty sure valgrind and friends can be used in zig.
Zig is still not 1.0, theres not much stability guarantees, making something like Frama-C, even tho it is possible is simply going to be soo much pain due to constant breakages as compared to something like C.
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).
I guess formal verification tools? That is the peak that even rust is trying to reach with creusot and friends. Ada has support for it using Spark subset [which can use why3 or have you write the proofs in coq]
Frama-C exists for C.
Astree exists for C++ but i dont think lone developers can access it. But it is used in Boeing.
The other comments get the general idea, but here's a slightly more detailed explanation.
Code generation backends in the Zig compiler work by lowering an SSA-like structured IR called AIR to machine code (or actually first to another intermediate data structure called MIR, but don't worry about that). The thing is, AIR is intentionally quite high-level, the intention being that the code emitting AIR (which is complex and difficult to parallelize) doesn't have to waste loads of valuable single-threaded time turning e.g. a single line of Zig code into tens or hundreds of instructions.
However, this approach sort of just moves this work of "expanding" these high-level operations into low-level instructions, from the code producing AIR, into the codegen backend. That's good for compiler performance (and also actually for avoiding spaghetti in the compiler :P), but it makes it much more difficult to write backends, because you need to implement much more complex lowerings, and for a much greater number of operations.
To solve this problem, `Legalize` is a new system we've introduced to the compiler which effectively performs "rewrites" on AIR. The idea is that if a codegen backend doesn't want to support a certain high-level operation, it can set a flag which tells `Legalize` that before sending the AIR to codegen, it should rewrite all occurences of that instruction to a longer string of simpler instructions. This could hugely simplify the task of writing a backend; we don't have that many legalizations implemented right now, but they could, for instance, convert arithmetic on large integer types (e.g. u256) into multiple operations on a "native" integer size (e.g. u64), significantly decreasing the number of integer sizes which you need to handle in order to get a functional backend. The resulting implementation might not emit as efficient machine code as it otherwise should (generally speaking, manually implementing "expansions" like the one I just mentioned in the backend rather than in `Legalize` will lead to better code because the backend can sort of "plan ahead" better), but you can implement it with way less work. Then, if you want, you can gradually extend the list of operations which the backend actually supports directly lowering, and just turn off the corresponding legalizations; so everything works before and after, but you get better code (and possibly slightly faster compilation) from implementing the operation "directly".
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.
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
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.
> 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`
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].
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) backend for Zig. ;)
reply