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....
Zig ELF Linker Improvements Devlog
91–100 of 105 posts
Re: Zig ELF Linker Improvements Devlog
#92Earlier quoted context omitted.
They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md... which applies to contributing to the Zig project. The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/ "Anti-AI stance" is painting it with too broad of a brush. You're definitely not…
And the largest Zig projects all make use of AI assistance to build software.
tigerbeetle does not, but the others do.
Re: Zig ELF Linker Improvements Devlog
#93Earlier quoted context omitted.
what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.
They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md... which applies to contributing to the Zig project. The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/ "Anti-AI stance" is painting it with too broad of a brush. You're definitely not…
> too broad of a brush
yes, that was my point. as domeone who uses ai extensively to write zig (and someone who has made very small non-AI cobtributions to zig in the past), rejecting ai is currently a strategically good decision for core zig.
Re: Zig ELF Linker Improvements Devlog
#94So, 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?
For releases you're generally building it all at once in a merge request/deployment pipeline anyway
Re: Zig ELF Linker Improvements Devlog
#95Earlier quoted context omitted.
"technically" usually means something like "strictly", not "by a completely different metric". work takes time. zig has had a decade of work put into it.
Technically means according to a strict, often legal definition. The strict definition being we don't count developments that happened before version 1. Like when we talk about Rust, we don't mention the virtual threads or GC or the @ symbol for GC references. Even though those all happened during its development.
and when people talk about zig, they don't usually mention that zig used to have goto, casting syntax like `T(val)`, a rule that said you couldn't pass containers by value, language-level async, some truly awful syntax for what is now `try` and other operators, etc. both languages took time and work to realize that these features were not for them. very strange to deny that.
also, nitpick: they said zig has been around for ten years. this is, strictly, correct. the zig project has existed for ten years, just like how rust has existed for about 20, now. a project still exists if it is pre-1.0. nobody was talking about versions before you.
Re: Zig ELF Linker Improvements Devlog
#96Earlier quoted context omitted.
Interesting. How do you prevent data races in concurrent code? Or do you not allow shared mutable memory?
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 compelling project!
I suspect if you don't cherry-pick benchmarks, you're going to run into some performance problems with not allowing shared mutable memory - though maybe you can avoid most of that if you have some type of built-in actor pattern.
But if you're actually competitive across the board with Go & Rust/Tokio/Crossbeam - I'd love to take a deeper look, because that is NOT easy to accomplish.
I didn't see any of that from a cursory look at the language, though.
Re: Zig ELF Linker Improvements Devlog
#97Earlier quoted context omitted.
Does not help the regulator posts on HN about having rewriten known projects into Rust, and since we are on a Zig thread, Bun.
Those rewrites happen because someone was interested in making them happen (often the maintainer). The meme is that evangelists will constantly advocate to you that your project should be rewritten.
I hardly see a difference, that is how evangelism works.
Re: Zig ELF Linker Improvements Devlog
#98Re: Zig ELF Linker Improvements Devlog
#99Earlier quoted context omitted.
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”.
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.
Re: Zig ELF Linker Improvements Devlog
#100Earlier quoted context omitted.
> Definitely true when using VC++ with C++20 modules and MSBuild. Lol, sorry, but as soon as MSBuild is involved the compiler can be infinitely fast and you'd still need to be waiting for the build. Also the main problem of MSVC is the slow linker, and that isn't fixed by C++ modules. This is also the first time I'm hearing that C++ modules actually help with compilation speed in real world projects - the best I've h…
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?