Since they only mention dropping support for C++, Objective-C, and Objective-C++, I assume this means C is still supported?
yeah, but not using Clang
File for divorce from LLVM
71–80 of 167 posts
Re: File for divorce from LLVM
#72Some of this reasoning is just wild. 1. "We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs." They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone's random side project. To think otherwi…
Long time compiler hacker/engineer and compiler/programming language PhD here all great points. Worth saying out loud that many reasons why this stuff is slow is not due to bad code, its due to the fact that many of the best algorithms are in higher complexity classes and just scale poorly with program/translation unit size. For example when I was working on `rustc` a big challenge was heavy reliance on inlining and…
> I feel like Go already went through a whole saga of this where the community started with "LLVM and SSA are bad and slow"
I've been a contributor since the Go compiler was a tree-based C program and I've never heard anyone say that. What they said (and it's in the Go FAQ page) is: "At the beginning of the project we considered using LLVM for gc but decided it was too large and slow to meet our performance goals." [1]
If you're building a language with the explicit goal to make it compile fast, it's objectively true that starting out with LLVM is not the best approach. You'll get incredible runtime performance of the generated code since the early days, but NOT fast compilation. The Go makers choose a different tradeoff.
> and they end up building their own SSA IR
They switched to a SSA IR because it was a good idea to begin with, after an initial phase with the tree-base prototype. I've also never heard anyone argue that "SSA is bad", despite what you claim. The first compiler was tree-based because they reused a simple tree-based C compiler from plan9.
> building their own SSA IR and spending a bunch of time trying to bring compilation time closer to what it was before as it made everything much slower
The new compiler was ported to Go (machine-rewritten from C) and that's the main reason it was ~2x slower than the old compiler. It's not due to the switch to a SSA-IR.
Re: File for divorce from LLVM
#73Every time I hear about LLVM, it turns into a rant. Clearly there is a problem there that needs to be fixed. Maybe the LLVM project team should address those issues.
The "problem" with the LLVM project is its massive success, coupled with its incredibly difficult problem domain. Turns out it's actually really hard to write modular compiler infrastructure that serves as the optimizer and code generator for N different arbitrary programming languages. The fact that it works in this capacity at all, and still manages to be competitive with GCC in its original use-case (being a C/C++…
Btw, is there a good learning pathway for LLVM/MLIR for folks w/o compiler background? I come mostly from HW but is super interested in the topic due to work-related stuff. Since your day job is LLVM related maybe you can give great advice.
Re: File for divorce from LLVM
#74Earlier quoted context omitted.
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…
> 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.
well, you can: i have done this, with Rust. but yes, it’s more the type of thing that well-resourced companies do rather than solo devs, because even with Bindgen and the like Rust really wants the atomic codegen unit to be the “library”, not C’s notion of a “compilation unit”. still, C FFI compatibility is exactly why porting from C to rust incrementally is feasible while C to, say Java, is probably a bigger leap.
Re: File for divorce from LLVM
#75The correct time to build something without LLVM was years ago, but taking the C++ functionality out now will probably be the end of Zig. I'm surprised they didn't announce a plan to write their own C++ compiler in Zig instead of phasing it out.
Just writing a parser for C++ is a gargantuan project. I'm not even sure if an individual can write a C++ compiler if they started on their 18th birthday. There may not be enough hours left in their life to write a functioning compiler.
Sean Baxter is doing a decent job with his Circle compiler, so I hear. https://www.circle-lang.org/
Re: File for divorce from LLVM
#76The 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.
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
Re: File for divorce from LLVM
#77Every time I hear about LLVM, it turns into a rant. Clearly there is a problem there that needs to be fixed. Maybe the LLVM project team should address those issues.
It's not obvious that "LLVM, but not incredibly frustrating" is a thing which can exist. I don't think it's likely, but it's possible that in a few decades the widespread view will be that the very concept of LLVM was a mistake, and a universal compiler backend is just a trap which makes it easy to bootstrap a language but inevitably causes massive problems down the road. LLVM does have plenty of incidental problems…
MLIR is "LLVM done better", in fact by the same person. It fixes many of unforced LLVM problems, for example LLVM's inability to parallelize code generation.
Re: File for divorce from LLVM
#78The correct time to build something without LLVM was years ago, but taking the C++ functionality out now will probably be the end of Zig. I'm surprised they didn't announce a plan to write their own C++ compiler in Zig instead of phasing it out.
Just writing a parser for C++ is a gargantuan project. I'm not even sure if an individual can write a C++ compiler if they started on their 18th birthday. There may not be enough hours left in their life to write a functioning compiler.
Check the history of Circle, not only did Sean Baxter implement a full C++ compiler frontend, it has lots of extensions from all C++ wannabe replacements and a Rust like borrow checker.
Re: File for divorce from LLVM
#79Every time I hear about LLVM, it turns into a rant. Clearly there is a problem there that needs to be fixed. Maybe the LLVM project team should address those issues.
The "problem" with the LLVM project is its massive success, coupled with its incredibly difficult problem domain. Turns out it's actually really hard to write modular compiler infrastructure that serves as the optimizer and code generator for N different arbitrary programming languages. The fact that it works in this capacity at all, and still manages to be competitive with GCC in its original use-case (being a C/C++…
When clang came about, GCC was already renamed into GNU Compiler Collection.
Re: File for divorce from LLVM
#80Given 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.
Unless they sort out the issues related to use-after-free, the value preposition is hardly any better than using C and C++, with the memory corruption tooling there is around from the last 30 years.