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...
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.
Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.
Kotlin also has its own features that differ from the way the JVM or Java has decided to develop them. For example: coroutines vs virtual threads or Kotlin “value” classes and Java value classes. The semantics don’t match and Kotlin stops becoming simply a “better Java”.
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
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.
`@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
> Zig, Rust, and the likes are only viable in niches where C is viable
Pretty much correct, yes.
> 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.
Fundamentally impossible. C/Zig/Rust have 100% performance as a top goal, which has to be traded off with something else and that's always realistically going to be programmer work/effort/time.
You can't have a house built 100% fast but also 100% cheap and with 100% quality. At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
> once this linker and incremental compilation on other targets land,
In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
Beyond being low level, Zig is still pretty memory unsafe and has you make choices about each allocation, making it unappealing as an applications language. Zig and Python are completely different worlds.
> At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
then how does Zig achieve ~90%?
> In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
sub-100ms rebuild is actually more important as the project grows. when you iterate, you think differently. picking different colors or fonts or whatnot becomes much cheaper, so you are more willing to try
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.
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.
lol … fwiw we are as bemused by the situation as anyone (well, I am, I can’t really speak for anyone else). My take is that Raku (née perl6) got the worst of all worlds … divided the perl community, was 15 years in the making, got dragged into the reputational suction as the unreconstructed perl Titanic sank. All the same, it’s a wonderful reimagining of all the great things of perl from all the community RFPs and the genius of Larry and Damian and co and fixes most of the negatives and is now there and steadily improving and what’s not to like!
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.
thanks! I have done a bit of work on Raku + Polars (ie the Pandas rewrite in Rust). This has been hampered by Rust lack of a binary FFI - so it has ended up running into unsafe keyhole surgery territory. My current feel is that we would need to move down to Apache Arrow and build a bunch of FFI / MOARMVM level scaffolding to keep it fast. Maybe take a look at COW at the same time.
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?
FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like:
32743 lines; 0.953s
...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.
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.
I don’t think either zig or rust can replace C, no matter how much this kind of work. They will of course improve its own language. The only language that can replace C is a language is as simple as C. None of them are simple language.
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.
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.
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!).
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).
> Didn't Go already do that?
no. GC pauses turn any serious systems work into hell.
> Yes, and it will still only be useful [...]
this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui
3 replies →
Go is a terribly verbose language.
> 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.
Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.
Kotlin also has its own features that differ from the way the JVM or Java has decided to develop them. For example: coroutines vs virtual threads or Kotlin “value” classes and Java value classes. The semantics don’t match and Kotlin stops becoming simply a “better Java”.
1 reply →
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
3 replies →
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.
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.
I've tried building your project, but hit problems due to dependency hash mismatches. Do you have a screenshot somewhere?
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
1 reply →
> Zig-native immediate-mode
dvui?
many thanks, will look into that...
> Zig, Rust, and the likes are only viable in niches where C is viable
Pretty much correct, yes.
> 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.
Fundamentally impossible. C/Zig/Rust have 100% performance as a top goal, which has to be traded off with something else and that's always realistically going to be programmer work/effort/time.
You can't have a house built 100% fast but also 100% cheap and with 100% quality. At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
> once this linker and incremental compilation on other targets land,
In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
Beyond being low level, Zig is still pretty memory unsafe and has you make choices about each allocation, making it unappealing as an applications language. Zig and Python are completely different worlds.
> At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.
then how does Zig achieve ~90%?
> In any case, why would a better linker and faster compile times of all things achieve this supposed goal?
sub-100ms rebuild is actually more important as the project grows. when you iterate, you think differently. picking different colors or fonts or whatnot becomes much cheaper, so you are more willing to try
> You can't have a house built 100% fast but also 100% cheap and with 100% quality.
That’s essentially what technological development does, is make those tradeoffs more favorable.
1 reply →
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.
9 replies →
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.
lol … fwiw we are as bemused by the situation as anyone (well, I am, I can’t really speak for anyone else). My take is that Raku (née perl6) got the worst of all worlds … divided the perl community, was 15 years in the making, got dragged into the reputational suction as the unreconstructed perl Titanic sank. All the same, it’s a wonderful reimagining of all the great things of perl from all the community RFPs and the genius of Larry and Damian and co and fixes most of the negatives and is now there and steadily improving and what’s not to like!
> the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!"
This is more of a meme than reality at this point.
2 replies →
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!
thanks! I have done a bit of work on Raku + Polars (ie the Pandas rewrite in Rust). This has been hampered by Rust lack of a binary FFI - so it has ended up running into unsafe keyhole surgery territory. My current feel is that we would need to move down to Apache Arrow and build a bunch of FFI / MOARMVM level scaffolding to keep it fast. Maybe take a look at COW at the same time.
Is any of that already lying around in Zig?
minor correction, moar stands for metamodel on a runtime, not meta-object aware runtime
red face … thanks for the correction … I guess I should have looked at https://moarvm.org
Is there a design dock or explanation about how it can do incremental linking?
It's evaded other linkers in the past: gcc, llvm, mold etc....
This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!
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.
Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.
Everyone forgets D. It’s probably the fastest to compile, even faster than Go
Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...
FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like:
...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.
2 replies →
Isn’t go (with cgo disabled) still at least as fast to compile?
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.
Definitely not true. Otherwise we would have really fast C++ compilers and no one would ever have implemented hacks like precompiled headers.
3 replies →
This has drastically changed with "recent developments".
Iteration speed is everything now, if and only if you learn from the additional iterations.
I don’t think either zig or rust can replace C, no matter how much this kind of work. They will of course improve its own language. The only language that can replace C is a language is as simple as C. None of them are simple language.
I really would like a 1.0, then I think it can actually be adopted by business.
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'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?
It's a hard-to-dislike language in the niche of systems programming.
The author is strongly biased and opinionated on his architectural and design choices, and those choices resonate with many.
I don't like the @ all over the place and the approach to slurping source as structs for libraries.
I would faster get back to Modula-2 or Object Pascal.
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!
1 reply →
Still no 1.0 version though. So technically it's year 0.
2 replies →
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.
4 replies →