Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

File for divorce from LLVM

github.com

Post reply on HN
Print view View original

61–70 of 167 posts

Re: File for divorce from LLVM

#61

Post by brabel »

harerazer wrote: post #22
frmdstryr wrote: post #16

So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several "tier 1" supported arches are just going to be dropped? It's your language so do whatever you want but please adjust the branding accordingly...

I mean, it’s no secret that zig is pre 1.0. I’m not sure this is on them, although it does seem like a drastic proposal.

One of the mantras for Andrew Kelly has been "do not use Zig in production" until it hits 1.0.

People know that, but it's difficult to avoid using it for real things once you've tried it and it works :D.

I haven't done that with Zig, but with Kotlin things like serialization/coroutines/kotest/KAPT (it was the same feeling: oh this stuff is "Experimental" but so cool, I can't do real Kotlin without them!!)... well yeah, I spent many hours rewriting stuff due to that, and totally acknowledge that was on me.

Re: File for divorce from LLVM

#62

Post by brabel »

WalterBright wrote: post #25

The DLang has 3 compilers: 1. gdc - based on the Gnu compiler collection back end 2. ldc - based on the LLVM back end 3. dmd - based on the x86 code generator that I wrote for Zortech/Symantec/Digital Mars They each have their pluses, minuses, and targets. But the D language each supports is the same. Overall, our users like the choice. Some even use more than one.

That's cool. Another language with multiple compilers is Common Lisp, which has a dozen or so production-ready compilers (some commercial, but most free).

That allows people to use the fastest compiler during development, and the fastest runtime (or smallest memory footprint) compiler for the final release, which is really useful.

Also, just having a language specification which all compilers adhere to ensures that the language is stable and won't just break things under you (for better or worse, there are advantages for languages like Zig that can still change anything they want in order to make the language more consistent/cleaner/more powerful). I tend to value this stability a lot more these days - it lets me put all my effort in creating real value for users instead of constantly keeping up with development tools.

Re: File for divorce from LLVM

#63

Post by hota_mazi »

Given the barrage of negative comments on the PR and here as well, it really feels like Andrew is the only person in favor of that change.

It's his language, obviously, but I strongly suspect that if this PR goes through, it will completely kill any kind of momentum that Zig has today and will most likely doom the language to obscurity.

Which would be a real shame.

Re: File for divorce from LLVM

#64

Post by Ashymad »

Hermitian909 wrote: post #59
wyldfire wrote: post #56

Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal. But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just s…

I'm reminded of a recent interview with Chris Latner about the success of Swift - he credits the success to the fact that you could start with a large objective C project and begin writing Swift without rewriting anything. Part of Rust's success is off the back of a similar compatibility with C/C++. It is difficult for me to imagine Zig succeeding without a similar capability - which is to say I hope they do not foll…

But rust absolutely does not have any C/C++ compatibilty besides arguably very good FFI. And that's where zig shines. They have a c/c++ compiler built into the zig compiler via zig cc, that's even easier to use than clang or GCC due to having the benefits of a buildscript and baked in libcs for different architectures, making crosscompilation a breeze.

In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.

This milestone is only gonna remove the c++ (and objective c/c++) compiler for now from zig cc. So while you could argue this will ostracize people rewriting their c++ codebases in zig, I don't imagine there's actually many people like that. EDIT: I just looked at the discussion and there's actually a lot of people that use the c++ capapbilities.

Re: File for divorce from LLVM

#65

Post by saagarjha »

jroesch wrote: post #58
Solvency wrote: post #52

Earlier quoted context omitted.

Just to play devils advocate..who would've thought Javascript would ever end up as blazingly fast as it has become since V8. Maybe Zigworld can do it.

As the parent comment said, and I mentioned in my reply. JavaScript was just incredibly poorly optimized/not compiled and they applied 20-30 years worth of compiler research to make it significantly faster. You also had an alliance of every hyperscaler working on the tooling for a decade plus with help from all major hardware vendors to bring the best performance out of it. One driver of LLVM was Apple and WebKit whi…

Apple, of course, dropped LLVM at some point after it didn’t meet their latency needs.

Re: File for divorce from LLVM

#66

Post by masklinn »

wyldfire wrote: post #56

Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal. But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just s…

> Just as ambitious as it was for Lattner to create LLVM, I suppose.

A big difference is there was an element of no choice to LLVM, at least in Apple’s takeover of the project: GCC didn’t want to allow / do what Apple wanted / needed out of it.

Re: File for divorce from LLVM

#70

Post by delphLonepaw »

MuffinFlavored wrote: post #24
frmdstryr wrote: post #16

So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several "tier 1" supported arches are just going to be dropped? It's your language so do whatever you want but please adjust the branding accordingly...

They're dropping LLVM by re-implementing everything it does in their own homegrown fashion?... To what benefit? Isn't this a waste of resources?

LLVM just works well on the front that clang uses, after that, llvm itself is a wild beast full of worms, which is becoming more and more painful to work with if you are a language creator/mantainer, A lot of untested paths, and hidden bugs that zig has hit before... many times.

It will NOT reimplement everything, if you read the proposal, it's in favour of changing the LLVM dependency (the libs) not dropping LLVM IR generation, this will come with performance regression since now will be up to the team to get the correct IR, and making decisions LLVM IR generation does already in LLVM

The problem is that clang is being dropped, which means, unless we have a new C++ front made in zig (a-la AroCC for C) we are gonna suffer quite a bit for projects using C++ with zig.

Post reply on HN