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

51–60 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#51

Post by Ygg2 »

peesem wrote: post #50
Ygg2 wrote: post #35

Earlier quoted context omitted.

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.

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.

Re: Zig ELF Linker Improvements Devlog

#52

Post by Mawr »

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

Re: Zig ELF Linker Improvements Devlog

#53

Post by spease »

Mawr wrote: post #52
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, 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…

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

Re: Zig ELF Linker Improvements Devlog

#54

Post by spease »

GuB-42 wrote: post #32
librasteve wrote: post #13

There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization. Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization han…

I am following Raku and Zig from afar, and they both share similarities in that both languages are "optimized for fun" in a way, so no surprize that they come together. Zig focus on compilation speed and give developers control (even more so than C). Raku, as a Perl descendant is a giant toybox and there is no one telling you not to use them. Both have in common that they give a lot of freedom to developers, which is…

> the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!"

This is more of a meme than reality at this point.

Re: Zig ELF Linker Improvements Devlog

#55

Post by vips7L »

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 a terribly verbose language.

Re: Zig ELF Linker Improvements Devlog

#56

Post by vips7L »

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

Re: Zig ELF Linker Improvements Devlog

#57

Post by donpdonp »

c0rruptbytes wrote: post #20
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.

> If Rust is the new C++, Zig is the new C. thank you, this helps!

I used to think Zig was the new C, but its different enough to be its own category, imho. For an actually "new" C, try https://c3-lang.org/.

Re: Zig ELF Linker Improvements Devlog

#58

Post by demilicious »

eddythompson80 wrote: post #34
bpavuk wrote: post #28

Earlier quoted context omitted.

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

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

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

Re: Zig ELF Linker Improvements Devlog

#59

Post by keithasaurus »

onlyrealcuzzo wrote: post #49
keithasaurus wrote: post #42

Earlier quoted context omitted.

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

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place mutation -- `var` really means "re-bindable" to a new value; and then under the hood we'll mutate in place where we can.

Re: Zig ELF Linker Improvements Devlog

#60

Post by keithasaurus »

onlyrealcuzzo wrote: post #49
keithasaurus wrote: post #42

Earlier quoted context omitted.

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

How is compiling to zig? I considered doing it but chose C instead because of how much zig is still changing. I've considered using it's C compiler for targeting multiple platforms locally.
Post reply on HN