Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig ELF Linker Improvements Devlog

ziglang.org

Post reply on HN
Print view View original

21–30 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#21

Post by onlyrealcuzzo »

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

Re: Zig ELF Linker Improvements Devlog

#22

Post by alexboehm »

bpavuk wrote: post #5

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…

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.

Re: Zig ELF Linker Improvements Devlog

#23

Post by akazantsev »

bpavuk wrote: post #5

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…

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

Re: Zig ELF Linker Improvements Devlog

#24

Post by keithasaurus »

onlyrealcuzzo wrote: post #21

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 t…

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.

Re: Zig ELF Linker Improvements Devlog

#25

Post by dnautics »

bpavuk wrote: post #5

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…

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

Re: Zig ELF Linker Improvements Devlog

#26

Post by dnautics »

dzbarsky wrote: post #7
bcardarella wrote: post #3

I wonder how much this work being pushed forward right now is a response to the Bun drama.

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.

Re: Zig ELF Linker Improvements Devlog

#27

Post by onlyrealcuzzo »

keithasaurus wrote: post #24
onlyrealcuzzo wrote: post #21

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 t…

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.

Re: Zig ELF Linker Improvements Devlog

#28

Post by bpavuk »

akazantsev wrote: post #23
bpavuk wrote: post #5

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…

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

Re: Zig ELF Linker Improvements Devlog

#29

Post by bpavuk »

dnautics wrote: post #25
bpavuk wrote: post #5

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…

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

Re: Zig ELF Linker Improvements Devlog

#30

Post by bpavuk »

gliptic wrote: post #17
bpavuk wrote: post #5

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…

> Zig-native immediate-mode dvui?

many thanks, will look into that...
Post reply on HN