That's quite impressive. For comparison, Python had 2 full time paid devs in 2019 (not sure about now).
GVR for example works for Microsoft and has worked at Dropbox and other places, but spends much of his time on Python. So he isn't listed as an employee of the foundation, but at times is full time.
If a company donates employee time they have more influence on the project than donating cash to pay for development.
The fact that Zig had the cash donation to do it this way is brilliant, and probably a better model.
The most the PSF could do is “bolt on” a developer to solve packaging in yet another non embraced and supported way.
The Zig team are doing great work and they care about the contributor experience.
It's very memory efficient, everything compiles of the box to WebAssembly (freestanding or wasi), the resulting code is compact and fast, and it can take advantage of the latest WebAssembly extensions (threads, SIMD, ...) without any code changes. If you are using a webassembly-powered cloud service and not using Zig to write your functions, you are wasting money. Seriously.
Unsurprisingly, this is the most popular language to write games running on WebAssembly: https://wasm4.org/blog/jam-2-results/
Beyond the language, Zig is also a toolchain to compile C code to WebAssembly. When targeting WASI, it will seamlessly optimize the C library for size, performance or runtime features. I used it to port OpenSSL, BoringSSL and ffmpeg to WebAssembly. Works well.
Also, Zig can generate WebAssembly libraries that can then be included in other languages that support WebAssembly. Most of my Rust crates for WebAssembly are now actually written in Zig.
It's also supported by Extism, so can be used to easily write safe plugins for applications written in other languages.
Are the memory safety guarantees that Rust offers over Zig not as important or critical when targeting WASM?
I've been interested in checking out Zig for a while now.
I also heard someone say "Zig is to C what Rust is to C++". Which I interpret as, it's another maximum-performance modern language, but smaller than Rust; "smaller" meaning that it has less safety and also abstraction (no encapsulation [1]), but less requirements and complexity.
Particularly with games, many devs want to build a working prototype really fast and then iterate fast. They don't want to deal with the borrow checker especially if their code has a lot of complex lifetime rules (and the borrow checker is a real issue; it caused evanw to switch esbuild to Go [1]). In small scripts with niche uses, safety and architecture are a waste of effort, the script just has to be done and work (and the latter is only partly necessary, because the script may not even be fed enough inputs to cover edge cases). Plus, there are plenty of projects where custom allocation is especially important, and having every type support custom allocation is a big help vs. having to rewrite every type yourself or use `no_std` variants.
[1] https://github.com/ziglang/zig/issues/2974
[2] https://github.com/evanw/esbuild/issues/189#issuecomment-647...
This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust.
But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based destructors (defer) and you need to remember to write them and ensure they're called exactly once per value. Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) but do benefit from nice built-in syntax due to their special-cased-ness. Rust has typed errors whereas Zig only has integers, though again that allows Zig to have much simpler syntax for defining arbitary error sets which would require defining a combinatorial explosion of enums in Rust.
Of course from Zig's point-of-view these are features, not deficiences, which is completely understandable given what kind of language it wants to be. And the other advantages you listed like comptime (Rust's const-eval is very constrained and has been WIP for ages) and custom allocator support from day 1 (the way Rust is bolting it on will make most existing code unusable with custom allocators, including parts of Rust's own standard library) are indeed good advantages. Zig also has very nice syntax unification - generic types are type constructor functions fn(type) -> type, modules are structs, etc.
I hope that one day we'll have a language that combines the best of Rust's strictness and Zig's comptime and syntax.
2. You can do type introspection (and switching) during compile-time, and it's not just some stupid TokenStream transformer, you really have type information available, you can do if/else on the presence of methods, etc.
3. There are no generics, but your functions can accept anytype, which is still type-safe. See https://github.com/ziglang/zig/blob/9c05810be60756e07bd7fee0... and note the return type is "computed" from the type of the input.
4. Types are first-class values (during comptime), so any function can take or return a new type, this is how you get generic types, without (syntax/checking) support for generics.
5. You can easily call anything which does not allocate in these comptime blocks.
6. There's @compileError which you can use for custom type assertions -> therefore, you have programmable type-system.
7. It's super-easy to call C from Zig.
8. This is subjective: You don't feel bad about using pointers. Linked data structures are fine.
The typical urban myth that never comes with profiler proofs.
In my opinion, Zig seems likely to grow the necessary bits to be good at embedded while Rust is unlikely to figure out how to shrug off the clanky bits that make it a poor fit for embedded devices.
However, I'm a personal believer that the future is polyglot. We're just at the beginning of shrugging off the C ABI that has been preventing useful interoperability for decades.
Once that happens, I can use Rust for the parts that Rust is good for and Zig for the parts that Zig is good for.
What do you see as "clanky bits that make it a poor fit" for such a broad range of stuff as "embedded devices" ?
Embedded goes at least as far as from "It's actually just a Linux box" which is obviously well suited to Rust, to devices too small to justify any "high level language" where even C doesn't really fit comfortably. Rust specifically has no ambitions for hardware too small to need 16-bit addresses, but much of that range seems very do-able to me.
I’m not really convinced because in Andrew’s livestreams he’s actively uncovered significant stdlib bugs that he is aware of and tables for later.
Hopefully those will all be gone by 1.0, but I doubt it. For now, I cannot consider it a viable alternative to anything for production software. I do hope it will be some day, because it’s a nice language, even if it has a few syntactic warts :)
that said... I feel safer choosing C89 or C99 for certain things due to its extremely wide availability and longevity.
It’s great for it to have competitors, but C and C++ are more like standards and less like one tool with a handful of people working on it.
(although I think we still managed to write up all of the most important bits)
Is there are chart or a "are we xxxx yet" page one can reference?
- A pixel art editor https://github.com/fabioarnold/MiniPixel
- A Mega Man clone https://github.com/fabioarnold/zeroman
- Zig Gorillas https://github.com/fabioarnold/zig-gorillas
And most recently I had the opportunity to build a visualization for TigerBeetle's database simulator: https://sim.tigerbeetle.com
Before I was using C++ and Zig has been an improvement in every way.
It's nowhere near usable yet, but Zig has been a joy to work with for over a year, and I can definitely see myself using it for a big piece of software.
Looks like I'll be porting to 0.11.1 as soon as the documentation is in place... I hope they slow down soon, already feels complete. The WASM support is amazing, much smaller outputs than the other options I tried (Java & Go). Great work team!
A number of my libraries are used for https://www.aolium.com/ which I decided to write for myself.
I try to write a bit every day with the benefit that I can "waste" time digging into things or exploring likely-to-fail paths.
Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.
We’re really talking about safety on a continuum, not as a binary switch. Zig has some strong safety features, and some gaps. Well, one notable big gap, UAF. (Perhaps they’ll figure out a way to plug thisin the future? Perhaps by 1.0?)
Actually, safety has multiple axes as well.
> Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue
The more safe languages make significant tradeoffs to achieve their level of safety. The promise of zig (I don’t know if it will ultimately achieve this, but it’s plausible, IMO), is “a better C”, including much more safety. For one thing, it has a great C interop/incremental adoption story, which increases the chance it will actually be used to improve existing codebases. The “RIIR” meme is a joke because, of course, there is no feasible way to do so for so many of the useful and widely used vulnerable codebases.
I am somewhat surprised this is being mentioned. And the whole thread is without the usual people complaining it about unsafe.
Interesting changes happening on HN.
Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust).
There are plenty of use cases where none of these tradeoffs are feasible.
To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehensive as other languages.
The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.
Perhaps as an escape hatch (unsafe Rust) or a compiler target, but ideally not as a "general purpose language" as Zig is marketed as.
You're not limited by anything there, period.
What I'm trying to say: There are use cases where areas of safety are required other than memory safety.
Number of memory bugs in several fairly huge projects: 0
Zig is way more maintainable, leads to less code which translates to fewer bugs
How about that?
"The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities."
I realize Zig is just 0.11, but wondering what resources people relied on to pick it up?
Do you, by chance, know the reasoning behind this step?
Not supporting proprietary OSes is a bummer. Especially if it is marked as deprecated since it is unlikely to change. People choosing Zig to anything choose their users to throw away their devices.
.. the number of hardware and software just keeps growing and growing endlessly, and the number of their combinations grows even faster. We probably need some more virtual machines as targets to cover them all.
Apple is asking you to throw away your devices, not Zig. Getting proper CI coverage for supported versions of the OS is already pretty expensive and doing the same for unsupported systems is entirely unfeasible at this moment.
Don't buy Apple if you don't want to throw away functioning hardware.
Having 'we support proprietary systems until their makers support it' as a hard rule is unnecessary and harsh. It is a simple rule, but I don't think it is good. Why not choose the supported systems on individual merits, e.g. on usage statistics? I think for example the Linux kernel does that.
edit: I just continued the previous thought. If your reply means that you are open or likely to target deprecated systems in the future, that's much better!
So it’s not really zig deprecating 32-bit macos’s, but Apple, and there’s not a lot zig can do about that.
