I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.
I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.
> that will let me iterate at the speed of JS or Python with performance of C or Rust.
Didn't Go already do that?
> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement
Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...
Rust is significantly different.
Go is for the cases where GC works for you (many, many cases).
Zig is for when you need control over the allocator (also many such cases).
> Kotlin of C
That sounds good on paper. But as a guy who tried to learn Kotlin and only it. It comes with baggage to learn Java to use its libraries because... You know... they interact seamlessly and stuff. In the end, for a new learner, it might actually make things harder.
Nothing about Zig and C here, just a bit salty from my experience with Kotlin.
Clojure also "comes with the baggage" of learning Java libraries.
And JavaScript comes with the baggage of learning about web browsers and NodeJS's "fs" module.
Kotlin <-> Java interop is a totally optional topic you could have skipped over, telling you as a Kotlin developer (who recently had to switch to .NET because Ukrainian job market is fucked up). besides, Java itself isn't that hard if it's Java 17 or newer, and it's rather good if it's Java 25 or newer
> Kotlin <-> Java interop is a totally optional topic you could have skipped over
This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?
It's already sort of possible. https://codeberg.org/fellowtraveler/flux here is my Zig DAW. It has been amazing for the audio engine, but the ui is currently using imgui.
idk, making @cImport just "@import" is an improvement imo.
`@import` that you have to configure in the build system first.
this makes porting projects gradually, file by file, rather cumbersome. now I have to rewrite quite a lot of Chocolate Doom because my port was halfway there and then @cImport got gutted... or keep going with Zig 0.16.2 until it's either 100% Zig or has little enough files that upgrading won't make my build.zig file implode in lines of code
i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?
> Zig-native immediate-mode
dvui?
many thanks, will look into that...
I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.
The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).
I believed it had the best build system design and was the best transpilation target, and I really believe that 6 months later.
The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).
Working on something kinda similar. No GC, Python feel, managed memory, performance approaching C. It's here: https://blorp-lang.org if you want to compare approaches.
It looks pretty cool!
It's not clear how much concurrency is part of what you're trying to solve.
Definitely down to chat more - looks like you've got some traction, which is impressive and awesome!
I'd love to pick your brain as it appears you're further along than I am.
Yeah, concurrency in blorp doesn't allow shared mutable references, so deadlocks aren't really a concern. Otherwise it's meant to be simple-ish -- virtual threads, channels, no async/await. Pure functions allow safe parallelism naturally, so that's fairly straightforward, though the API is still incomplete, for example the "Parallel" section here: https://blorp-lang.org/docs/lists/. It's still under heavy development (working on it right now).
What are the over-arching goals of your language?
Right on.
1) I want to minimize global complexity, which by definition maximizes local reasoning.
2) I want to make the vast majority of bugs simply unrepresentable - taking it past Rust, and even past Pony - WHILE allowing shared mutable memory, but without requiring a PhD to use.
The goal is in EASY mode, it's barely harder to use than Ruby or Python (just the occasional pedant compiler error that has automatic options to fix itself most of the time). You don't even have to supply types or compile. It has a REPL, etc.
When you bump to DEFAULT mode and then to STRICT mode, all the annotation is automatic - your code just might look "ugly" if you like having no types anywhere etc.
But DEFAULT & STRICT mode give people and LLMs everything they need to know to understand the effects of an individual function.
I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could know types, required capabilities etc, without the user ever needing to type anything, but when the user needs it, they can find it, query it, test against it.
Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more.
WRT to inference, yes. I infer everything in EASY mode.
And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that).
I couldn't tell if you're using affine ownership, but I assume so if you don't have a GC. If they try to create an alias - they get a use after move error, and the compiler tells them they need to either COPY (auto-fix) or create a RefCount (usually auto-fix) - they pick.
There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.
Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.
I am following Raku and Zig from afar, and they both share similarities in that both languages are "optimized for fun" in a way, so no surprize that they come together.
Zig focus on compilation speed and give developers control (even more so than C). Raku, as a Perl descendant is a giant toybox and there is no one telling you not to use them. Both have in common that they give a lot of freedom to developers, which is really enjoyable. They also have in common that they are not very mature and have a limited market share and fine with it, and a community that looks genuinely nice.
The opposite of Rust. The language has the "bondage and discipline" philosophy, kind of like ADA, the idea being that it does everything it can to stop you from making mistakes. There is a lot of value in that, but it is not particularly fun. Its community was similarly defined by rules, its code of conduct was infamous, again, it serves a purpose but to me, putting the rules forward doesn't make the community look like a fun place to be. And there is the evangelism, the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!", etc... I have never seen such attitude from the Zig community. Sure they love their language and will tell you it is the best in the world, but they will not say that you are wrong for not using it. As for Raku, they don't seem to care that no one else use their language, they just hope it will happen eventually if they continue going forward.
If you decide to try this, feel free to share your progress and struggles on IRC, ziggit, or ZSF zulip. Plenty of people would be interested in helping out.
Good luck and happy hacking!
minor correction, moar stands for metamodel on a runtime, not meta-object aware runtime
So, this linker does fast incremental linking, which is great for development iteration speed.
But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?
Research "cl:define-compiler-macro".
It has been done before.
And LTO is when the C people and the C++ people started to agree.
[deleted]
This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!
Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.
Compilation speed isn’t that much of a factor of language as far as I can understand. It is more related to how optimization is done and how machine code is generated.
Also obviously it is about how fast the actual implementation of the compiler/build-system is.
This has drastically changed with "recent developments".
Iteration speed is everything now, if and only if you learn from the additional iterations.
Definitely not true. Otherwise we would have really fast C++ compilers and no one would ever have implemented hacks like precompiled headers.
Isn’t go (with cgo disabled) still at least as fast to compile?
I really would like a 1.0, then I think it can actually be adopted by business.
i'm not cool and hip like hacker news devs, but I've been seeing Zig a lot, is this the new cool thing on the street? no more Rust?
Zig's been around for ~10 years. It's more low-level and lightweight than Rust. Different goals, different trade-offs. If Rust is the new C++, Zig is the new C.
> If Rust is the new C++, Zig is the new C.
thank you, this helps!
Still no 1.0 version though. So technically it's year 0.
These improvements are quite promising and I'm looking forward to giving that a spin once it is released.
Will the Windows side for 0.17.x get some compiler improvements as well or is this Linux only?
I wonder how much this work being pushed forward right now is a response to the Bun drama.
None of it, we've been working on this stuff for a long time already, scroll the devlog backwards, you will find plenty of entries on that topic.
It's the opposite: people have become more receptive to communication about this work now that there's "drama" attached to it.
This post I co-authored with Andrew is from 2020. In it we announce the idea of getting rid of LLVM from the debug build pipeline and since then work has been steadily going forward, it's just not trivial to bootstrap a full compiler pipeline for all major targets, but we're finally getting there.
I'm very glad to see the work, thank you for all of the efforts.
There is absolutely no "Bun drama", there are just two projects with different goals and methodologies, mutually incompatible. All this thing is just a small bunch of bored, terminally-twitting people ...
In any case, I'm super glad for this milestone (and impressed!).
Some people really can’t operate without stirring unnecessary drama.
What if that’s true and what if that’s not true?
None? All of these things were in flight for a while and given Zigs anti-AI stance i think they wrote off Bun ever since the acquisition
what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.
I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.
I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.
> that will let me iterate at the speed of JS or Python with performance of C or Rust.
Didn't Go already do that?
> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement
Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...
Rust is significantly different.
Go is for the cases where GC works for you (many, many cases).
Zig is for when you need control over the allocator (also many such cases).
> Kotlin of C
That sounds good on paper. But as a guy who tried to learn Kotlin and only it. It comes with baggage to learn Java to use its libraries because... You know... they interact seamlessly and stuff. In the end, for a new learner, it might actually make things harder.
Nothing about Zig and C here, just a bit salty from my experience with Kotlin.
Clojure also "comes with the baggage" of learning Java libraries.
And JavaScript comes with the baggage of learning about web browsers and NodeJS's "fs" module.
Kotlin <-> Java interop is a totally optional topic you could have skipped over, telling you as a Kotlin developer (who recently had to switch to .NET because Ukrainian job market is fucked up). besides, Java itself isn't that hard if it's Java 17 or newer, and it's rather good if it's Java 25 or newer
> Kotlin <-> Java interop is a totally optional topic you could have skipped over
This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?
It's already sort of possible. https://codeberg.org/fellowtraveler/flux here is my Zig DAW. It has been amazing for the audio engine, but the ui is currently using imgui.
idk, making @cImport just "@import" is an improvement imo.
`@import` that you have to configure in the build system first.
this makes porting projects gradually, file by file, rather cumbersome. now I have to rewrite quite a lot of Chocolate Doom because my port was halfway there and then @cImport got gutted... or keep going with Zig 0.16.2 until it's either 100% Zig or has little enough files that upgrading won't make my build.zig file implode in lines of code
i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?
> Zig-native immediate-mode
dvui?
many thanks, will look into that...
I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.
The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).
I believed it had the best build system design and was the best transpilation target, and I really believe that 6 months later.
The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).
Working on something kinda similar. No GC, Python feel, managed memory, performance approaching C. It's here: https://blorp-lang.org if you want to compare approaches.
It looks pretty cool!
It's not clear how much concurrency is part of what you're trying to solve.
All I could find is this: https://blorp-lang.org/docs/concurrency/ - which doesn't give me much as to how you handle shared memory, safety, deadlocks, etc.
Definitely down to chat more - looks like you've got some traction, which is impressive and awesome!
I'd love to pick your brain as it appears you're further along than I am.
Yeah, concurrency in blorp doesn't allow shared mutable references, so deadlocks aren't really a concern. Otherwise it's meant to be simple-ish -- virtual threads, channels, no async/await. Pure functions allow safe parallelism naturally, so that's fairly straightforward, though the API is still incomplete, for example the "Parallel" section here: https://blorp-lang.org/docs/lists/. It's still under heavy development (working on it right now).
What are the over-arching goals of your language?
Right on.
1) I want to minimize global complexity, which by definition maximizes local reasoning.
2) I want to make the vast majority of bugs simply unrepresentable - taking it past Rust, and even past Pony - WHILE allowing shared mutable memory, but without requiring a PhD to use.
The goal is in EASY mode, it's barely harder to use than Ruby or Python (just the occasional pedant compiler error that has automatic options to fix itself most of the time). You don't even have to supply types or compile. It has a REPL, etc.
When you bump to DEFAULT mode and then to STRICT mode, all the annotation is automatic - your code just might look "ugly" if you like having no types anywhere etc.
But DEFAULT & STRICT mode give people and LLMs everything they need to know to understand the effects of an individual function.
I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could know types, required capabilities etc, without the user ever needing to type anything, but when the user needs it, they can find it, query it, test against it.
Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more.
WRT to inference, yes. I infer everything in EASY mode.
And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that).
I couldn't tell if you're using affine ownership, but I assume so if you don't have a GC. If they try to create an alias - they get a use after move error, and the compiler tells them they need to either COPY (auto-fix) or create a RefCount (usually auto-fix) - they pick.
There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.
Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.
Anyway those with skills and interest are welcome to join the -Ofun at https://raku.org/community
I am following Raku and Zig from afar, and they both share similarities in that both languages are "optimized for fun" in a way, so no surprize that they come together.
Zig focus on compilation speed and give developers control (even more so than C). Raku, as a Perl descendant is a giant toybox and there is no one telling you not to use them. Both have in common that they give a lot of freedom to developers, which is really enjoyable. They also have in common that they are not very mature and have a limited market share and fine with it, and a community that looks genuinely nice.
The opposite of Rust. The language has the "bondage and discipline" philosophy, kind of like ADA, the idea being that it does everything it can to stop you from making mistakes. There is a lot of value in that, but it is not particularly fun. Its community was similarly defined by rules, its code of conduct was infamous, again, it serves a purpose but to me, putting the rules forward doesn't make the community look like a fun place to be. And there is the evangelism, the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!", etc... I have never seen such attitude from the Zig community. Sure they love their language and will tell you it is the best in the world, but they will not say that you are wrong for not using it. As for Raku, they don't seem to care that no one else use their language, they just hope it will happen eventually if they continue going forward.
If you decide to try this, feel free to share your progress and struggles on IRC, ziggit, or ZSF zulip. Plenty of people would be interested in helping out.
Good luck and happy hacking!
minor correction, moar stands for metamodel on a runtime, not meta-object aware runtime
So, this linker does fast incremental linking, which is great for development iteration speed.
But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?
Research "cl:define-compiler-macro".
It has been done before.
And LTO is when the C people and the C++ people started to agree.
This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!
Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.
Compilation speed isn’t that much of a factor of language as far as I can understand. It is more related to how optimization is done and how machine code is generated.
Also obviously it is about how fast the actual implementation of the compiler/build-system is.
This has drastically changed with "recent developments".
Iteration speed is everything now, if and only if you learn from the additional iterations.
Definitely not true. Otherwise we would have really fast C++ compilers and no one would ever have implemented hacks like precompiled headers.
Isn’t go (with cgo disabled) still at least as fast to compile?
I really would like a 1.0, then I think it can actually be adopted by business.
i'm not cool and hip like hacker news devs, but I've been seeing Zig a lot, is this the new cool thing on the street? no more Rust?
Zig's been around for ~10 years. It's more low-level and lightweight than Rust. Different goals, different trade-offs. If Rust is the new C++, Zig is the new C.
> If Rust is the new C++, Zig is the new C.
thank you, this helps!
Still no 1.0 version though. So technically it's year 0.
These improvements are quite promising and I'm looking forward to giving that a spin once it is released.
Will the Windows side for 0.17.x get some compiler improvements as well or is this Linux only?
Might not make it in time for 0.17 but there is a contributor making progress on the COFF linker: https://codeberg.org/kcbanner/zig/src/branch/coff_linker_wip
I wonder how much this work being pushed forward right now is a response to the Bun drama.
None of it, we've been working on this stuff for a long time already, scroll the devlog backwards, you will find plenty of entries on that topic.
It's the opposite: people have become more receptive to communication about this work now that there's "drama" attached to it.
This post I co-authored with Andrew is from 2020. In it we announce the idea of getting rid of LLVM from the debug build pipeline and since then work has been steadily going forward, it's just not trivial to bootstrap a full compiler pipeline for all major targets, but we're finally getting there.
https://kristoff.it/blog/zig-new-relationship-llvm/
I'm very glad to see the work, thank you for all of the efforts.
There is absolutely no "Bun drama", there are just two projects with different goals and methodologies, mutually incompatible. All this thing is just a small bunch of bored, terminally-twitting people ...
In any case, I'm super glad for this milestone (and impressed!).
Some people really can’t operate without stirring unnecessary drama.
What if that’s true and what if that’s not true?
None? All of these things were in flight for a while and given Zigs anti-AI stance i think they wrote off Bun ever since the acquisition
what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.
They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md...
which applies to contributing to the Zig project.
The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/
"Anti-AI stance" is painting it with too broad of a brush. You're definitely not breaching any CoC or whatever by using AI for your Zig projects.