6 ms·

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 incremen

by bpavuk 4mo ago

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.

gliptic 4mo ago
> Zig-native immediate-mode dvui?
- bpavuk 4mo ago
  many thanks, will look into that...
alexboehm 4mo ago
It's already sort of possible. https://codeberg.org/fellowtraveler/flux 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.
- lukaslalinsky 4mo ago
  I've tried building your project, but hit problems due to dependency hash mismatches. Do you have a screenshot somewhere?
akazantsev 4mo ago
> 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.
- bpavuk 4mo ago
  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
  - eddythompson80 4mo ago
    > 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?
    - demilicious 4mo ago
      I have quite literally never had to do Java interop in my Kotlin work. Do you have an example? In contrast, your statement about F# strikes me as mostly true - albeit my interop was always the other way around (consuming F# code from C#).
      - pjmlp 4mo ago
        Calling Koltin co-routines directly from Java code, as an example. There is a reason Android team has Java friendly guidelines.
- dapperdrake 4mo ago
dnautics 4mo ago
idk, making @cImport just "@import" is an improvement imo.
- bpavuk 4mo ago
  `@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
  - dnautics 4mo ago
    i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?
kllrnohj 4mo ago
> 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.
- dapperdrake 4mo ago
  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).
- vips7L 4mo ago
  Go is a terribly verbose language.
- bpavuk 4mo ago
  > 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
  - kllrnohj 4mo ago
    > no. GC pauses turn any serious systems work into hell. did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter > this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?
Mawr 4mo ago
> 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.
- spease 4mo ago
  > 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.
  - tovej 4mo ago
    No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good. And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.
- bpavuk 4mo ago
  > 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

by bpavuk 4mo ago

gliptic 4mo ago

> Zig-native immediate-mode dvui?

bpavuk 4mo ago
many thanks, will look into that...

alexboehm 4mo ago

It's already sort of possible. https://codeberg.org/fellowtraveler/flux 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.

lukaslalinsky 4mo ago
I've tried building your project, but hit problems due to dependency hash mismatches. Do you have a screenshot somewhere?

akazantsev 4mo ago

> 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.

bpavuk 4mo ago
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
- eddythompson80 4mo ago
  > 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?
  - demilicious 4mo ago
    I have quite literally never had to do Java interop in my Kotlin work. Do you have an example? In contrast, your statement about F# strikes me as mostly true - albeit my interop was always the other way around (consuming F# code from C#).
    - pjmlp 4mo ago
      Calling Koltin co-routines directly from Java code, as an example. There is a reason Android team has Java friendly guidelines.
dapperdrake 4mo ago

dnautics 4mo ago

idk, making @cImport just "@import" is an improvement imo.

bpavuk 4mo ago
`@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
- dnautics 4mo ago
  i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?

kllrnohj 4mo ago

> 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.

dapperdrake 4mo ago
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).
vips7L 4mo ago
Go is a terribly verbose language.
bpavuk 4mo ago
> 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
- kllrnohj 4mo ago
  > no. GC pauses turn any serious systems work into hell. did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter > this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?

Mawr 4mo ago

> 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.

spease 4mo ago
> 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.
- tovej 4mo ago
  No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good. And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.
bpavuk 4mo ago
> 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