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

41–50 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#41

Post by mihaelm »

dnautics wrote: post #26
dzbarsky wrote: post #7

Earlier quoted context omitted.

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.

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 breaching any CoC or whatever by using AI for your Zig projects.

Re: Zig ELF Linker Improvements Devlog

#42

Post by keithasaurus »

onlyrealcuzzo wrote: post #40
keithasaurus wrote: post #37

Earlier quoted context omitted.

Yeah, concurrency in blorp doesn't allow shared mutable references, so deadlocks aren't really a concern. Otherwise it's meant to be simple-ish -- virtual threads, channels, no async/await. Pure functions allow safe parallelism naturally, so that's fairly straightforward, though the API is still incomplete, for example the "Parallel" section here: https://blorp-lang.org/docs/lists/ . It's still under heavy developmen…

Right on. 1) I want to minimize global complexity, which by definition maximizes local reasoning. 2) I want to make the vast majority of bugs simply unrepresentable - taking it past Rust, and even past Pony - WHILE allowing shared mutable memory, but without requiring a PhD to use. The goal is in EASY mode, it's barely harder to use than Ruby or Python (just the occasional pedant compiler error that has automatic opt…

I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could know types, required capabilities etc, without the user ever needing to type anything, but when the user needs it, they can find it, query it, test against it.

Re: Zig ELF Linker Improvements Devlog

#43

Post by mattgrice »

ozgrakkurt wrote: post #38
ksec wrote: post #12

Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.

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.

Re: Zig ELF Linker Improvements Devlog

#44

Post by kllrnohj »

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…

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

Re: Zig ELF Linker Improvements Devlog

#45

Post by dapperdrake »

kllrnohj wrote: post #44
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…

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

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

Re: Zig ELF Linker Improvements Devlog

#46

Post by dapperdrake »

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.

Clojure also "comes with the baggage" of learning Java libraries.

And JavaScript comes with the baggage of learning about web browsers and NodeJS's "fs" module.

Re: Zig ELF Linker Improvements Devlog

#47

Post by dapperdrake »

derefr wrote: post #10

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?

Research "cl:define-compiler-macro".

It has been done before.

And LTO is when the C people and the C++ people started to agree.

Re: Zig ELF Linker Improvements Devlog

#48

Post by dapperdrake »

ozgrakkurt wrote: post #38
ksec wrote: post #12

Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.

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.

This has drastically changed with "recent developments".

Iteration speed is everything now, if and only if you learn from the additional iterations.

Re: Zig ELF Linker Improvements Devlog

#49

Post by onlyrealcuzzo »

keithasaurus wrote: post #42
onlyrealcuzzo wrote: post #40

Earlier quoted context omitted.

Right on. 1) I want to minimize global complexity, which by definition maximizes local reasoning. 2) I want to make the vast majority of bugs simply unrepresentable - taking it past Rust, and even past Pony - WHILE allowing shared mutable memory, but without requiring a PhD to use. The goal is in EASY mode, it's barely harder to use than Ruby or Python (just the occasional pedant compiler error that has automatic opt…

I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could k…

Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more.

WRT to inference, yes. I infer everything in EASY mode.

And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that).

I couldn't tell if you're using affine ownership, but I assume so if you don't have a GC. If they try to create an alias - they get a use after move error, and the compiler tells them they need to either COPY (auto-fix) or create a RefCount (usually auto-fix) - they pick.

Re: Zig ELF Linker Improvements Devlog

#50

Post by peesem »

Ygg2 wrote: post #35
agluszak wrote: post #19

Earlier quoted context omitted.

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.

Still no 1.0 version though. So technically it's year 0.

"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.
Post reply on HN