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 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 <-> 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
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'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.
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?
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 still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.
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.
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
dvui?
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
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).
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.
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?
thank you, this helps!
Will the Windows side for 0.17.x get some compiler improvements as well or is this Linux only?
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/
In any case, I'm super glad for this milestone (and impressed!).
What if that’s true and what if that’s not true?