Zig ELF Linker Improvements Devlog • Hacker News Board

Re: Zig ELF Linker Improvements Devlog

#101

Post by keithasaurus » Mon, Jun 01, 2026, 3:28 AM UTC

onlyrealcuzzo wrote: post #96

keithasaurus wrote: post #89

Earlier quoted context omitted.

Yeah, no shared mutable memory; coordination is done via channels.

Awesome. If you want some feedback, I'd recommend putting some concurrent benchmarks on your home page (and if you have some already - I'd clearly separate them). When I originally scanned it, I just assumed this was another predominately sequential language with no good concurrency story. If you're actually competitive with Rust/Tokio/Crossbeam and Go on the most common concurrent patterns, then you've got a really…

Still incomplete there. But yeah performance should be decent. Not aiming for parity either rust or go entirely but in the same ball park is the expectation.

Re: Zig ELF Linker Improvements Devlog

#102

Post by [deleted] » Mon, Jun 01, 2026, 5:15 AM UTC

jstimpfle wrote: post #100

pjmlp wrote: post #74

Earlier quoted context omitted.

Follow engineering principles and actually test it. The company behind Cadifra UML Editor is quite happy with their migration, the owner keeps posting about their modules experience on Reddit C++. Microsoft also has CppCon talks on the matter. All my C++ hobby projects use modules, as I only care about VC++.

What is the compile and link perfomance that you get then? Numbers on table... I know that even with MSVC, single file rebuild+link of C code at about 100 KLOC/second should be well possible. You keep posting about obscure products like whatever UML Editor that noone cares about, why would I listen to what they say, and why do you not even link anything to look up?

[deleted]

Re: Zig ELF Linker Improvements Devlog

#103

Post by pjmlp » Mon, Jun 01, 2026, 5:21 AM UTC

vips7L wrote: post #99

pjmlp wrote: post #61

Earlier quoted context omitted.

That is the curse of guest languages, see C and C++ as well. That is why I always say keep with the platform, and why despite my endless rants on C, I keep myself up-to-date in regards to it. Eventually they always diverge.

It'll be interesting long term to see where they go with Kotlin. WRT value classes they'll probably introduce something like @JvmValue like the did with @JvmRecord when data classes diverged from Java records.

They behave as if JVM was only relevant to bootstrap Kotlin ecosystem, especially since they became Google's darling on Android, and doubled down on Kotlin Multiplatform.

From all guest languages on the JVM, the Kotlin community is the one I rather avoid, as many behave thankless to the platform that actually makes their toy possible in first place.

Clojure, Groovy and even Scala, focus primarily on being nice with Java and having a symbiotic relationship.

Koltin folks are like "we're replacing Java, ahaha stupid language".

Well where is the Kotlin Virtual Machine, other than Android userspace, which nonetheless requires Java support to benefit from Maven Central ecosystem?

Certainly driven by Android folks, I would say.

Re: Zig ELF Linker Improvements Devlog

#104

Post by pjmlp » Mon, Jun 01, 2026, 5:34 AM UTC

jstimpfle wrote: post #100

pjmlp wrote: post #74

Earlier quoted context omitted.

Follow engineering principles and actually test it. The company behind Cadifra UML Editor is quite happy with their migration, the owner keeps posting about their modules experience on Reddit C++. Microsoft also has CppCon talks on the matter. All my C++ hobby projects use modules, as I only care about VC++.

What is the compile and link perfomance that you get then? Numbers on table... I know that even with MSVC, single file rebuild+link of C code at about 100 KLOC/second should be well possible. You keep posting about obscure products like whatever UML Editor that noone cares about, why would I listen to what they say, and why do you not even link anything to look up?

An obscure application with paying customers, something foreign to many HNers.

Well, somewhere down in one of those blog posts,

https://abuehl.github.io

https://devblogs.microsoft.com/cppblog/integrating-c-header-...

Re: Zig ELF Linker Improvements Devlog

#105

Post by ozgrakkurt » Sat, Jun 06, 2026, 7:57 PM UTC

mattgrice wrote: post #43

ozgrakkurt wrote: post #38

Earlier quoted context omitted.

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.

You can write code that compiles slow in pretty much any language.

You can maybe even do it in C if you are generating code using scripts or abusing macros.

On the other hand, you can write sane C++ (without stdlib) and clang or gcc is able to compile it extremely fast. Because clang and gcc are really fast.

You can write a rust program without dependencies and it would be extremely hard to make it compile slow unless you are abousing generics or procedural macros. But you can write a 100 line webserver using some framework like axum and it will compile really slow. This is not because Rust is slow to compile or rust compiler being slow.

On the other hand you can write a zig file with a single test and compiling it using Release mode takes 3+ seconds on a modern computer because Zig compiler is extremely slow when using LLVM backend. This is also obviosly not because Zig is a slow language to compile since their own backend (non LLVM) has super fast compilation.