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

61–70 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#61

Post by pjmlp »

vips7L wrote: post #56
akazantsev wrote: post #23

Earlier quoted context omitted.

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

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.

Re: Zig ELF Linker Improvements Devlog

#62

Post by pjmlp »

demilicious wrote: post #58
eddythompson80 wrote: post #34

Earlier quoted context omitted.

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

Calling Koltin co-routines directly from Java code, as an example.

There is a reason Android team has Java friendly guidelines.

Re: Zig ELF Linker Improvements Devlog

#63

Post by pjmlp »

spease wrote: post #54
GuB-42 wrote: post #32

Earlier quoted context omitted.

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.

Does not help the regulator posts on HN about having rewriten known projects into Rust, and since we are on a Zig thread, Bun.

Re: Zig ELF Linker Improvements Devlog

#64

Post by pjmlp »

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.

Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...

Re: Zig ELF Linker Improvements Devlog

#65

Post by pjmlp »

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.

That hack is because of C.

Definitely true when using VC++ with C++20 modules and MSBuild.

It also helps not compiling everything from source as many UNIX folks do.

Re: Zig ELF Linker Improvements Devlog

#67

Post by lukaslalinsky »

alexboehm wrote: post #22
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.

I've tried building your project, but hit problems due to dependency hash mismatches. Do you have a screenshot somewhere?

Re: Zig ELF Linker Improvements Devlog

#68

Post by bpavuk »

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…

> Didn't Go already do that?

no. GC pauses turn any serious systems work into hell.

> Yes, and it will still only be useful [...]

this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

Re: Zig ELF Linker Improvements Devlog

#69

Post by bpavuk »

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…

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

then how does Zig achieve ~90%?

> In any case, why would a better linker and faster compile times of all things achieve this supposed goal?

sub-100ms rebuild is actually more important as the project grows. when you iterate, you think differently. picking different colors or fonts or whatnot becomes much cheaper, so you are more willing to try

Re: Zig ELF Linker Improvements Devlog

#70

Post by flohofwoe »

pjmlp wrote: post #64
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.

Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...

FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like:

    32743 lines; 0.953s
...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.
Post reply on HN