Hacker News Reader

Comment by arcticbull | Hacker News Reader

Go's compiler toolchain is an overvalued monstrosity, a relic from the 70's only Rob Pike could get away with resurrecting. Imagine walking into your day job and saying to solve today's problem you're going to blow the dust off your old floppy disks and see what they've got in store.

It's like Tesla deciding that before they built a car, they'd have to pave a new highway from SF to LA. Someone's already done the paving, focus on what you bring to the table.

LLVM is clearly the future. Yes, it could be improved, but of course all the effort that went into resurrecting the geriatric Go compiler didn't go into improving LLVM. It went into re-implementing assemblers for various architectures as though that wasn't a solved problem 100 times over.

As for package management and vendoring, both are great, and should be table stakes, so credit where due on that one.

View on HN

And yet it works, it's fast, it's reliable. I've tried to build clang and it aint pretty.

Something something shipped is better than perfect.

IMHO I'm quite glad they didn't drag the bloat of LLVM into the fray.

Besides, one of Go's explicit goals was to not be bound to any one implementation. The language has been carefully documented to ensure that anyone could reimplement it without having to understand nuances of a specific toolchain.

If you want to compile Go using LLVM, everything you need is there to make it happen. In fact, someone has already done a lot of the leg work for you[1]. And if GCC is more your thing[2]...

[1] https://tinygo.org

[2] https://golang.org/doc/install/gccgo

I think this is too facile. Go was conceived as suitable for systems programming tasks, like web browsers, databases, and operating systems. But Google's own web browsers, databases, and OSes do not use Go.

It was also conceived as suitable for web servers, crawlers, and indexers; there it has been successful inside and outside Google.

Why didn't it catch on for browsers, databases, OSes - while Rust did? I think it must be the GC primarily, but the lack of an advanced optimizing compiler is part of the story.

I'm not sure where the idea Go hasn't caught on for databases comes from.

* https://awesome-go.com/#database

* https://github.com/rust-unofficial/awesome-rust#database

Rust was invented specifically to write a web browser, so that is a bit of an unfair comparison, but I would suggest that Go's lack of seamless inter-op with C is its biggest limiting factor in integrating into existing browser codebases as well as greenfield GUI applications. Additionally, Go's runtime is not well suited to OS development.

I doubt the lack of an advanced optimizing compiler ever crosses anyone's mind as by the time that might become an issue they have already ruled out Go for its many other limitations.

They would have shipped Go years sooner if they didn't waste their time re-building all the basic plumbing of a compiler suite. To leverage LLVM would have been to implement a basic front-end just like LLGo did. They'd have received instant access to an optimizing mid-end, optimizing back-ends and all the architectures that LLVM supports today and will ever support in the future. Any optimizations they'd made to LLVM would have made all LLVM clients better off. Instead, they chose to buff up 9c.

Is LLVM bigger? Yep. Slower? Probably. Is that because it's some wildly inefficient monstrosity? Nope. It does a lot more, with a lot more flexibly, and it does it a lot better than the Go toolchain. One day when Pike & Co get around to implementing all the optimization that LLVM has, it'll be just as big, and just as slow, mark my words.

Perhaps Pike & Co will stop short of implementing every optimization that LLVM has.

Why? Your users are the ones with the weak computers, developers usually have the beefiest machines. Why optimize for the developer, who'll build it a few hundred times, as compared to the end-user who will run it continuously for days/weeks/months/years on end? Just disable the expensive passes in a debug build, like "cargo check", "cargo build" and "cargo build --release".

Performance of Google software on Google servers doesn't seem like as serious an issue.

You're misinformed.

Russ Cox took the time to explain why LLVM wasn't chosen: https://news.ycombinator.com/item?id=8817990

I'm not sure that refutes my statement. All the post indicates is they didn't know LLVM. They also didn't try to learn LLVM, or hire someone who did know LLVM. I think that's what I'm suggesting.

Which is perfectly fine explanation. I mean, it is their programming language, not yours, they can do anything they want.

And while Go compiler may not be perfect, it works well enough.

Indeed but that doesn't make it a good decision, and it certainly doesn't make it "undervalued technology" -- and that's what we're discussing here, isn't it?

Well, I concur with the points from the article, since while I don't like Golang as a language I really like its tooling (BTW I am really craving for a more powerful language that compiles to Golang. And specially I like the focus in Golang to produce truly static binaries (they're not even linked with libc!).

And while Golang may not be the fastest language out there, it is fast enough for most use cases. I mean, Python is fast enough for most use cases, and Python is one or two orders of magnitude slower than Golang.

So yeah, I think their compiler decisions are fine. They may or may not be the best decisions, however the article is not talking about the compiler part of Golang, so yeah it can still talk about "undervalued technology".

What specifically about LLVM do you think makes it better than golangs compiler toolchain?

Its optimizations.

Not rewriting all the assemblers, linkers and optimization passes of which decades worth of PhDs went into LLVM. It was a total and utter waste of time re-doing all that. Any work that went into buffing up 9c is never going to make it back to the community, whereas anything that goes into LLVM makes the whole world a little bit faster, immediately. And they could have started there.

Ditto for gccgo - it still is a thing but they had to have their own everything and make gccgo a secondary implementation that lags behind mainstream. NIH maybe.

Not depending on LLVM was a good choice, given compilation speed, not depending on C++ and we don't need a compiler monoculture.

> ...compilation speed

It's faster because it does less, and it doesn't do it as well. You can always make LLVM faster by reducing the kinds and number of passes performed for debug builds, for instance, "cargo check".

Further, developers have much better machines than customers, and taking more time to release something smaller is almost always better.

> ...not depending on C++

I hate C++, but I could care less that LLVM was written in it. I don't refuse to use MySQL because it happens to be written in C++. The Go compiler could still be written in Go, and targeted at LLVM IR code, just as the Rust compiler is written in Rust.

> ...and we don't need a compiler monoculture

And we don't have one either way. There's GCC and LLVM. A boutique one-off compiler is in no danger of toppling the GCC/LLVM status quo.

Reply on news.ycombinator.com