Hacker News Reader

Comment by pbohun | Hacker News Reader

There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything.

Edit: I explained my position better below.

View on HN

People are correct I didn't explain my position.

LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.

Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.

How many languages are using LLVM as its backend vs Go's?

Go never advertised, designed for, nor supported external usage of their backend.

As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.

You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.

It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.

> As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.

I don't think that's true. Zig have a cross-compiler (that also compiles C and C++) based on LLVM. I believe LLVM (unlike gcc) is inherently a cross-compiler, and it's mostly just shipping header files for every platform that `zig cc` is adding.

I do not have enough knowledge to say anything bad about LLVM. As an "amateur" compiler writer, it did confuse me a bit though.

What I will say is that it seem popular to start with LLVM and then move away from it. Zig is doign that. Rust is heading in the direction perhaps with Cranelift. It feels that, if LLVM had completely nailed its mission, these kinds of projects would be less common.

It is also notable that the Dragonegg project to bring GCC languages to LLVM died but we have multiple projects porting Rust to GCC.

Even Clang can cross-compile from one compiler binary - whats missing is bundling the "platform SDK" for all targets like Zig does.

Yes. I also written a compiler and I also complained about LLVM.

LLVM is

  - Slow to compile
  - Breaks compilers/doesn't have a stable ABI
  - Optimizes poorly (at least, worse than GCC)

Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that

Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say

> LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

I suggest you ask around to see what the consensus is for which compiler is actually mature. Hint: for all its warts, nobody is writing a seriously optimized language in any of the options you listed besides LLVM.

Chris Lattner is definitely a genius engineer at innovation, implementation and delivery but long-term, robust, maintenable software-design doesn't appear to be in his capability set.

The latter is definitely a defining capability of Anders Hejlsberg. (C#/Typescript designer)

> Everything Chris Lattner has done has been a "successful mess".

I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean".

Why is it wrong?

LLVM is great.

Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today.

Swift is a fun language to write, hence, why they shoehorned it in, in the first place.

Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.

Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.

He had 0 to do with the TPU.

I was hired around Google around the same time, but not nearly as famous :)

AFAICouldT it was a "hire first, figure out what to do later", and it ended up being Swift for TensorFlow. That went ~nowhere, and he left within 2 years.

That's fine and doesn't reflect on him, in general, that's Google for ya. At least that era of Google.

Ahh, thanks for the info. Yeah, I heard Google was a bit messy from colleagues who went there.

You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.

Mojo and Modular have millions of users?

You can answer that question yourself.

You're right, looks like they don't, in fact, have millions of users.

Sick burn my man. Hope you check out Mojo lang vs arguing about rounding errors. I’m still unclear why I’m supposed to steer clear of Lattner which was what we were discussing.

Not sure what you're even talking about. You said something I was curious about since I thought you knew something about it I didn't but then you told me to look it up myself, for some reason, and I did. I don't know how you construed that as a "sick burn" or that you're "supposed to steer clear of Lattner," both of which I never said or implied.

It is all not important and I'm moving on as I'm sure you are as well. I assume good faith so I'm thinking we talked past each other a bit plus I was grouchy at one point (I apologize).

Here's the nut from the relevant comment: "There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything."

I can't support a take like this (the commenter's, not yours) it is not helpful or informative. That original comment was edited too, or added onto. On the face of it, the sentiment that Swift and Mojo and LLVM are these awful abominations is beyond the pale for me from an engineering standpoint. I think there are some FOSS feelings in play that stir up strongly held ideologies.

That's why there's nothing that comes close to LLVM and MLIR, right?

If he's such a horrible engineer then we should have lots of LLVM replacements, right?

QBE is a tiny project, but I think illustrates a better intermediate language design. https://c9x.me/compile/

Except performance isn't great and it covers far fewer platforms. It aims for 70% performance but the few benchmarks I've seen show more like 30-50% performance.

It's a cool project and I'd consider it for a toy language but it's far from an LLVM replacement.

Many compilers including my own uses C89

You'll still need a C compiler...

I never heard of hardware without one

Avoiding interacting with LLVM as a user doesn't mean you've created something equivalent to LLVM.

And if the C compiler you use is clang then you're still literally making use of LLVM.

IIRC, the Inmos Transputer shipped without a C compiler, and while third party products (including a port of GCC) did come later, it was Occam-only for quite some time.

I don't know what point you're trying to make but your question was what's an alternative to llvm. People writing compilers always used C89 or a version of it (C11 allows an easier atomic implementation). There's a lot more C89 compilers than backends that llvm supports. When I was writing arduino code clang/llvm couldn't generate the AVR code for the board. The default toolchain was gcc with an AVR backend. IIRC it had optimizations and was the only reasonable compiler I could use. There's nothing wrong using C as your backend

> There's nothing wrong using C as your backend

I didn't say there was. Saying use C instead of LLVM is fine for a language designer.

But that doesn't make it a replacement for LLVM as a piece of infrastructure. C compilers still need an optimizing backend like LLVM.

The conversation is about whether or not LLVM is a shit piece of engineering, not whether you should target C or IR as a language designer. Avoiding using LLVM directly isn't a replacement lol.

You could say "GCC" is a replacement which at least isn't completely false, but GCC's backend is far more annoying to use for different languages.

You don't really need to deal with gcc backend. Most languages are expressible in C89. It'll obviously be less readable since generated lines look nothing like source lines but C89 beats llvm in most cases, especially if the C compiler supports assembly. I stuck to using intrinsics only because I heard of compilers producing worse code when it hits asm blocks since it can't understand it as well as intrinsics. I took out llvm last time it broke my compiler because it didn't add any value

So what you're saying is that C source code is the (only) stable LLVM ABI ;)

Haha, yes

Reply on news.ycombinator.com