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

131–140 of 167 posts

Re: File for divorce from LLVM

#131

Post by flohofwoe »

duped wrote: post #129
flohofwoe wrote: post #122

Earlier quoted context omitted.

My stuff for instance: https://github.com/floooh/sokol ...inspired by: https://github.com/nothings/stb (here's how the sokol headers are integrated into a Zig project, note that there is only a build.zig which builds everything: https://github.com/floooh/kc85.zig ) But it's not so much about build systems, but requiring a separate compiler toolchain to build any C++ or ObjC dependencies (Rust needs this, Zig currentl…

I still don't see why this is a problem. Single-header dependencies are cute but blow up compile times, and most of the world needs CMake/Meson/Autotools anyways so there's not an added cost to using it for your own projects. Similarly I don't really understand why you want one toolchain for a multi-language project. It's not that useful or convenient since it's going to need to be orchestrated with a buildsystem som…

Did you try the stuff you are proposing? This is all a royal pita in real world projects which the Zig toolchain solved wonderfully.

(also it's a myth that STB style libs increase compile time, that's only true for typical C++ header-only libs with inline methods and template code)

Re: File for divorce from LLVM

#132

Post by vchuravy »

blindseer wrote: post #46

One of the main reasons Zig was interesting to me was the fact that I could drop it in as an alternative to a C/C++ compiler. On Windows, my friends have mentioned how it is easier to install Zig as a C/C++ compiler than any other alternative. If this proposal is accepted, I personally think Zig will drop to the popularity level of Hare or other extremely niche languages. Getting my colleagues to even try Zig out req…

> And dealing with bugs in LLVM is basically a no-go, I've seen this happen in the Julia ecosystem as well.

As one of the folks dealing with LLVM bugs in the Julia ecosystem.

Yes it requires a distinct skillet different from working on the higher-level Julia compiler and yes it can sometimes take ages to merge bugfixes upstream, but we actually have a rather good and productive relationship with upstream and the project would get a lot less done if we decided to get rid of LLVM.

In particular GPU support and HPC support (hello PPC) depends on it.

But this is also why we maintain the stance that people need to build Julia against our patchset/fork and will not invest time in bugs filled against Julia builds that didn't use those patches. This happens in particular with distro builds.

Re: File for divorce from LLVM

#133

Post by ComputerGuru »

Approaching this from the lens of an interested observer with experience with other projects working on non-LLVM backends for their languages, I'm just struck by the amount of hubris in the linked proposal.

If it weren't for the author, I'd have dismissed the whole thing as a low-effort GitHub issue by a Zig newbie. The underestimation of the work involved, the backhanded dismissal of all the work that has gone into LLVM, the "obviously we can do it cheaper, faster, better" confidence/machoism that exudes from each sentence or claim.. I'm disappointed.

I've had nothing but respect for Andrew's work in the past so I'm going to extend him some grace and the benefit of the doubt and say that maybe it was just written in haste or on a whim without paying attention to how it came across. But it's not something that inspires me with confidence or lends me to give the proposal itself more of a chance.

Re: File for divorce from LLVM

#134

Post by DylanSp »

qalmakka wrote: post #83
delphLonepaw wrote: post #70

Earlier quoted context omitted.

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…

> unless we have a new C++ front made in zig Writing a C++ compiler is several order of magnitude more complicated than writing a C, Java, Go or Zig compiler. There's a very good reason there are only 3 in existence despite how ubiquitous C++ is (and even then, it takes years for them to keep up with the latest standards). C++'s grammar is type 0, there's isn't even an EBNF definition of it because it's pratically im…

Out of curiosity, does Intel's icc compiler see much use? It looks like it uses LLVM these days, but its frontend presumably still needs to handle all of C++'s complexity.

Re: File for divorce from LLVM

#135

Post by rcme »

ComputerGuru wrote: post #133

Approaching this from the lens of an interested observer with experience with other projects working on non-LLVM backends for their languages, I'm just struck by the amount of hubris in the linked proposal. If it weren't for the author, I'd have dismissed the whole thing as a low-effort GitHub issue by a Zig newbie. The underestimation of the work involved, the backhanded dismissal of all the work that has gone into…

I know nothing about LLVM backends, but it’s pretty common that libraries aiming to solve 100% of users problems eventually become unwieldy and slow compared to a more optimized alternative. Web Pack vs. esbuild is an example of this.

Re: File for divorce from LLVM

#136

Post by morning-coffee »

overflyer wrote: post #116

One of the its biggest features is that the Zig toolchain is vastly superior to any other and opens up new possibilities to Devs of C/C++/Obj-C. One of its biggest selling points is to be able to use build.zig inside of projects with a C/C++/Obj-C codebase and thus get around using a shit ton of build tools. If zig cc and zig c++ die I would instantly stop using the language!

(Rust user here, but admirer from afar of Zig and the principles it seems rooted in.)

My peanut gallery observation is that a very bright person named Andrew set out on a journey of hard work to come up with a new language. Along the way he (and others) solved many tough ancillary problems related to the toolchain of this new language and how it should provide a useful path for interoperability and migration from code written in other languages.

The toolchain innovations were noticed, embraced, and leveraged by users of other languages as it made their lives easier in contexts where they weren't even using the Zig language.

Now, for Andrew to make even more innovative progress on his endeavor, he needs to undo some of the toolchain innovation and remove complexity that was initially used to bootstrap his endeavor. Removing complexity (from language) is one of the admired traits of this bright person, and here they are applying that good trait again to move the whole project forward.

But 'lo! Other users of the toolchain innovation will be affected... some would say they even appear "entitled" to these innovations... as if their collective need somehow outweighs Andrew's right to direct his energies to his project in the way he decides.

This whole thing smells like a story I read once... I think it was called "The Fountainhead".

Re: File for divorce from LLVM

#137

Post by WalterBright »

mhh__ wrote: post #111
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.

Having the choice for advanced users is a plus but I think having to choose is a big negative.

Ironically, when there was only one choice that was described as a big negative. Our experience with the troika has been a clear positive.

Re: File for divorce from LLVM

#138

Post by JediPig »

Andrew even thinking about dropping LLVM, says all I need to know. Its going to become the next D language of 2020s. LLVM has decades of mistakes FIXED, and rewriting the first time, even the 6th time is always... filled with huge mistakes and security issues...HUGE.

brew uninstall zig. Thats what I did when I read it. I do not want to waste any of my time on soon to be dustbin tech.

Re: File for divorce from LLVM

#139

Post by AndyKelley »

agos wrote: post #76
audunw wrote: post #37

Earlier quoted context omitted.

Ah, the obligatory comment from Walter Bright talking about D in posts about Zig (Nothing wrong with it, just a bit funny how predictable it has become) I guess the interesting difference in approach here, is that D seems to have completely separate compilers, while it looks like the main Zig compiler will support LLVM as a backend if you have it installed? If true, I like the approach Zig is going for.

yesterday on a thread on DMD somebody quipped "Funny how WalterBright seems to comment in every single HN thread other than this one..." and I thought it was hyperbole. Next HN thread I open, I'm proven wrong

C'mon, y'all, give him a break. It's cool that we get to hang out with the creator of D here.

Re: File for divorce from LLVM

#140

Post by bjourne »

jakelazaroff wrote: post #117
bjourne wrote: post #90

Two issues here. The first is code generation and the other is bootstrapping. Ime, the optimizing passes of a compiler are easy and fun to write. You have to read research papers to understand how register allocation and ssa form works, but it's fun code to write. You just send the ir through various optimizing passes, each refining it in some way. You can write high-quality optimization passes without llvm. But then…

I think this blog post addresses the bootstrapping issue: https://ziglang.org/news/goodbye-cpp/

Suppose you are implementing a new feature, how do you test it? First you compile the bootstrapping compiler. Then you use the bootstrapping compiler to compile an unoptimized optimizing compiler. Then you use the optimizing compiler to compile an optimized optimizing compiler. If the compiler doesn't rely on llvm then there will be more code to compile which will make this procedure slower. Especially since the bootstrapping compiler probably isn't very fast (though idk if this is the case with Zig).
Post reply on HN