
Problems with the Golang runtime and toolchain - bcantrill
http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
======
rsc
At this point, I suppose I am as responsible for the code and decisions the
author is complaining about as anyone.

Different people come from different backgrounds and, based on that, find
different tools useful. Ultimately you need to use the tools that let you get
your job done most effectively, however that is defined in your particular
case.

The Plan 9 toolchain has worked and continues to work well for Go. Most
importantly, it has been something we understand completely and is quite easy
to adapt as needed. The standard ABIs and toolchains are for C, and the
decisions made there may be completely inappropriate for languages with actual
runtimes.

For example, no standard ABIs and toolchains supported segmented stacks; we
had to build that, so it was going to be incompatible from day one. If step
one had been "learn the GCC or LLVM toolchains well enough to add segmented
stacks", I'm not sure we'd have gotten to step two. (Later, for gccgo, Ian did
have to add segmented stack support to the GNU gold linker, but Ian also wrote
that linker, so he was uniquely prepared.)

As another example, Go 1.4 replaces segmented stacks with stacks that grow or
shrink, as needed, by moving. And Go 1.4's garbage collector (GC) is also
completely precise wrt stack references into the heap. These require precise
information about which words on the stack are pointers and, for the GC, which
words are initialized and live. Go 1.5 will use that same information to
introduce a concurrent (bounded pause) garbage collector. Getting the
information through to the runtime was non-trivial but possible for us to do
with the Plan 9 toolchain. If we'd built on GCC, it would have required first
threading all that stack map information through the GCC or LLVM backends and
into a form that the runtime can use efficiently. Like before, I doubt we'd
have gotten to step two. (I don't know how gccgo is going to tackle this. It's
a big undertaking. I expect gccgo will have segmented stacks and imprecise
stack scans for a while yet.)

The toolchain is quirky and flawed in many ways. Some people don't like typing
shift so much in assembly files. Some people don't like the center dot hack
(glad the author didn't find the Unicode slash!). Those are really cosmetic
details, and if you stop there, you miss the point, which is that it's a small
toolchain that we can keep in our heads and make arbitrary changes to, quickly
and easily. Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly
I'd probably have left the project years ago.

The linker in particular is a piece of code in transition. The author is 100%
right that it's not great code. But it does work well, and it is being put to
production use at many companies as you read this. The code to produce ELF
object files and dynamically linked binaries in particular is new, is my
fault, and was quite difficult to fit into the original structure. The linker
is overdue to be replaced. The new linker is in the Go tree in src/cmd/link,
but it's unfinished.

Using a standard linker instead doesn't work well for a managed language. The
Go runtime needs to know where all the pointers are in the data and bss
segments, and a standard linker won't put that information together for you.
The Go linker does that. The Go linker also writes out runtime information for
unwinding stacks during GC and translating program counters to file:line for
use in stack dumps. Again, this is all much easier to do with a toolchain that
we control entirely than having to build into existing ones. (I am not aware
of any way to get file:line information through an existing linker except in
DWARF tables, which is overkill. And then there's OS X and Windows, where you
_really_ have no control over the toolchain.)

The calls to throw everything away and start over are at best hyperbolic.
Certainly there is room for improvement, but the custom toolchain is one of
the key reasons we've accomplished so much in so little time. I think the
author doesn't fully appreciate all the reasons that C tools don't work well
for languages that do so much more than C. Most other managed languages are
doing JIT compilation and don't go through standard linkers either.

~~~
justin66
Thank you for posting that. It was never a mystery why the project started
with the Plan 9 C compiler (if you're Ken Thompson, of course you'll use Ken
Thompson's compiler) but the detail on the evolution of the thing is
interesting.

It is a bit embarrassing that our self-moderation here did not cause your
comment to rise a little higher toward the top.

------
georgemcbay
He could have made the couple of points he made worth making without all of
the douchebaggery. Also can't tell if he's just trolling with all the stuff
about Unix vs Plan9 and calling Rob Pike out as an amateur or if he's just
woefully unaware of the history of both Unix and Plan9. In either case the
first paragraph is illuminating as to whether any of this matters to you:

"In the process of working on getting cgo to work on illumos, I learned that
golang is trash. I should mention that I have no real opinion on the language
itself; I’m not a languages person (C will do, thanks), and that’s not the
part of the system I have experience with anyway. Rather, the runtime and
toolchain are the parts on which I wish to comment."

For anyone not working in the internals of the golang compiler/runtime, as
long as the language is good and the tools produce the proper output when
given the proper input, who cares whether they offend someone who writes only
in C (and keep in mind I say this as someone who wrote code in C/C++ for
almost 15 years, and still has a very soft spot in my heart for C... but not
C++, fuck C++).

There seems to be a separating line between people who love and hate Go (well,
one of a few such lines) which involves the Go team's convention of making
stuff that should be scary for most programmers look and feel scary (see:
unsafe package, some of the stuff in cgo, etc). IMO, they take the right
approach (keep the easy stuff easy, make the hard stuff possible, and warn of
landmines [both explicitly and implicitly] early rather than later) but some
subset of people seem to get offended by these choices and lose sight of
everything else Go offers.

~~~
f2f
he's just rage quitting on his last day of work. see the next post on that
site, where pike is called a "world-class jackass" and Plan 9 "a colossal
failure".

referring to anything Plan 9 as "colossal" is a new one, i admit :)

~~~
MetaCosm
Hey, as going out rage quit rants go -- I honestly enjoyed it... it had a
spark. I don't agree with (most of) what he thinks, but at least he did it
with some style. Hope he enjoys the potato farming life, or whatever the heck
he does next.

------
SixSigma
> The real toolchains everyone else uses were not invented at Lucent nor
> Google

Plan 9 is not a product of Lucent. It is a product of Bell-Labs. Lucent killed
Bell-Labs. Calling it a Lucent product is akin to the worst insult to us you
could come up with, unless you said it was GNU-like.

Plan9 C is a product of Thompson, Pike & Ritchie, you can't get more C than
that, whatever your standards committee thinks.

> Without the benefit of decades of lessons learned running Unix in production

I'm not sure what the author of the rant thinks the people _who invented Unix_
were doing all those years.

~~~
coldtea
> _I 'm not sure what the author of the rant thinks the people who invented
> Unix were doing all those years._

I'm not sure what you think they're doing, but they were not running Unix in
production.

I've read an interview with Ken Thompson taken around the nineties, and he
mentioned they were using Windows desktop machines. And true to the words he
had Windows on the monitor on his desk.

And of course they were doing academic and researchy stuff. Not running Unix
in production.

~~~
davecheney
What horse pucky. The first Unix systems were used by Bell Labs' patent
department to process patent applications. It was this first customer of the
Unix group that sponsored the development of Unix for many of its formative
years.

~~~
coldtea
> _The first Unix systems were used by Bell Labs ' patent department to
> process patent applications. It was this first customer of the Unix group
> that sponsored the development of Unix for many of its formative years._

That's the seventies. Or at best early eighties.

We're talking about the last 30 years.

Not to mention that whatever customers Bell Labs had, doesn't translate that
Richie, Pike and co were running Unix in production or cared about those
systems and those customers themselves...

They had moved on to other researchy stuff...

~~~
SixSigma
POP was written in 1999

The last Unix release with people from the the Lab was UnixWare 7.1 (1999),
the last from AT&T in 2001.

Anything else _is not Unix_.

We know Rob wrote Utah 2000 in that year.

That's 15 years ago.

------
infogulch
I agree with the author's main point that the golang toolchain has a bad case
of NIH syndrome, and many of the specific problems he mentions have already
been Solved™ in other tools for some time. But there are reasons to have full
control of your entire toolchain, one of which is not having to deal with
getting patches merged upstream (in any of the dependencies). Another is
having the toolchain easily deployable on a multitude of platforms including
windows and plan9. The solutions he mentions are heavily reliant on specifics
of the unix environment, and most such projects would not welcome platform-
neutralization. (If your windows toolchain deployment includes "install MinGW
and use Cygwin", it's no longer "easily deployable" there.)

~~~
trhway
>I agree with the author's main point that the golang toolchain has a bad case
of NIH syndrome,

the blog seems to be from a Sun old-timer who pretty typically suffers from
... err ... enjoys this superiority style complex of "we have already invented
everything, why stupid word chooses to go its stupid way instead of that great
way we think it should go". This complex (and, as a major result of it,
refusal to accept reality) is one of the major things while Sun went down.
(hi! to Sun guys. Have you seen the abomination what FB did to our nice
offices in MPK!? :)

~~~
Jabbles
I hear they have a Sun sign there, to remind employees what happens to
companies that stop trying. Or perhaps that's another office - or maybe just
rumour.

~~~
ropiku
It's on the back of the sign in front of the campus:
[http://www.businessinsider.com/why-suns-logo-is-on-the-
back-...](http://www.businessinsider.com/why-suns-logo-is-on-the-back-of-
facebooks-sign-2014-12)

------
wtf_is_up
This guy seems to have a vendetta against Pike & Co:

> Unsurprisingly, Plan9 is a colossal failure, and one look at the golang
> toolchain will satisfy even the casual observer as to why; it was clearly
> written by people who wasted the last 30 years. There are plenty of other
> problems with Mr. Pike and his language runtime, but I’ve covered those
> elsewhere.

From
[http://dtrace.org/blogs/wesolows/2014/12/29/fin/](http://dtrace.org/blogs/wesolows/2014/12/29/fin/)

~~~
coldtea
What vendetta? Besides Plan9, which was decent for what it attempted, those
are more or less true statements. Golang doesn't have anything that show it
kept up with 30 years of advances in computing/PL design.

------
lbarrow
The author sums up his attitude in one of the first sentences: "I’m not a
languages person (C will do, thanks)".

Go is not C, and it's not going to be like C. It's not really reasonable to
expect it to have the same toolchain conventions as C. I'm not saying the
choices to Go authors have made are necessarily good, but I don't dislike them
_only_ because they're different from C.

~~~
coldtea
> _Go is not C, and it 's not going to be like C._

And yet, it's not much above C -- and in some cases, it's less.

------
mwsherman
So much ad hominem – arguing of motives for designs and decisions. It makes
for an odd contrast of technical opinions and unsupported speculation.

------
tobz
Ignoring the rhetoric for a second, are there examples of these design
decisions being asked about and being dismissed or flat-out not answered?

Most of us have seen the back and forth over generics in Go, including Rob
Pike's own blog? post about why Go doesn't have them. With that said, though,
I feel like I've also seen a lot of internals-related discussions with good
discourse from all sides.

Whatever the existing design is or isn't, it doesn't seem fair to go off on
such a rampage unless there's some sort of documented example that they are
actively trying to avoid simplifying things and really are seeking to fulfill
all of the things the author wrote. So... is there any evidence of that?

~~~
vorador
This is only remotely related, but the golang maintainers have refused to
include support for the (insecure, but used on some legacy systems) ECB
encryption mode, because it's insecure:
[http://code.google.com/p/go/issues/detail?id=5597](http://code.google.com/p/go/issues/detail?id=5597)
.

~~~
pa7ch
Although they don't have an ECB func, You can trivially implement it from
their AES library. I imagine the thinking goes something like, if you don't
know enough to write a couple lines to implement ECB, you probably shouldn't
be using it. It really doesn't take a deep understanding of crypto understand
ECB.

ECB is the simplest AES mode, you just encrypt each block of your message
using the same key. Here is an image of a penguin encrypted with AES-
ECB:[http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.j...](http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg)

Do you see the problem?

~~~
georgemcbay
Yeah, this. Didn't realize people actually saw this as an issue worthy of
worrying about.

The Matasano Crypto Challenges I did way back when were in Go and the ones
involving ECB were just done as for loops over the standard library AES
Decrypt/Encrypt methods, something like this:

    
    
      for i := 0; i < blockCount; i++ {
        start := i * blockLength
        end := start + blockLength
        aes.Decrypt(decryptBuffer, input[start:end])
        output = append(output, decryptBuffer) 
      }

~~~
richm44
The fact you can still see the penguin is the least of ECBs problems. If you
can do an adaptive chosen plain text attack then you can easily retrieve the
key when ECB is used.

------
roncohen_
The headline "Golang is trash" is very misleading. The author has nothing to
say about Go the language, but spends a lot of time on the toolchain - which
is arguably not part of the language at all.

In any case, it's not surprising that much of the `C` toolchain was ditched.
There are few things more frustrating than trying to compile and link
complicated C programs across platforms (the only thing that comes to mind are
C++ programs).

------
davecheney
Wait til Keith discovers Go passes arguments on the stack, totally ignoring
SPARC's register windows.

------
mwcampbell
I think it's sometimes good to ignore what has come before and start fresh, if
you have the resources to throw at that, as the Go team at Google apparently
does. Platforms and toolchains accumulate cruft over time; I guess the Go team
decided it was time to simplify by, for instance, using their own link editor.
I think that in an ideal world, they'd forego dynamic linking entirely; Plan 9
doesn't have it, after all.

The things wesolows pointed out about the Go asm dialect do seem weird,
though. And what's with the Unicode dot character?

~~~
bcantrill
The problem, honestly, is that they _didn 't_ start from scratch: they used a
bunch of their Plan 9 tooling to jumpstart it. While I don't quite share
Keith's invective, I _do_ have a lot of questions that haven't really been
answered about why it was done this way. In particular (and a point that Keith
only makes in passing), the fact that the Go runtime directly encodes the
system call table is a very peculiar design decision that makes the system
much, much less portable. And lest anyone point to the many ports: it has been
ported to other systems only with great frustration -- which is part of what
you're seeing in Keith's rant here...

------
the_real_bto
Expectations are really important. I tend towards higher level languages
(Python, JavaScript, toyed with Haskell), but I can empathize with the
author's frustration of using a tool that breaks his assumptions.

Software is complicated business, and making new things that work similar to
old things is a reasonable (and often successful) way to deal with the
complexity. However, if it isn't close enough to the original, it might cause
more problems, as it did for the author when he was using this not quite real
assembly language.

I really hope that some knowledgeable HNers will weigh in on this, it is
fascinating to read about.

------
hawkice
> Writing in normal (that is, adult) assembly language is not fraught at all.

The author identifies as someone who enjoys C programming (so I do not doubt
their sincerity here), but for those of us using languages with memory safety,
I think this may not apply. Particularly when I consider security, I cannot
help but worry about any C/assembly I write.

------
Khao
In other news "This hammer is trash because it doesn't screw in nails
properly!"

I'm not interested in compilers, I hate writing code in low level languages, I
cannot for the life of me understand assembly and Go works extremely well for
what I want to do. I've used PHP/C#/Javascript my whole life and I'm more
concerned about writing software than writing code. I don't want to nitpick on
the tiny details of a running software with memory registers, cpu cycles,
cache miss, etc unless there is an obvious bug or performance issue I need to
fix. Those things should be abstracted away from me as a developer and go is a
great compiled language that looks and feels like an interpreted language from
a developer point of view.

------
pierre_massat
Seems down:
[http://webcache.googleusercontent.com/search?q=cache:6M3QrOv...](http://webcache.googleusercontent.com/search?q=cache:6M3QrOvuh1gJ:dtrace.org/blogs/wesolows/2014/12/29/golang-
is-trash/)

------
dang
This post was briefly killed by user flags. It's not hard to see why: its
deliberately outrageous linkbait title violated the HN guidelines. Please
don't do that again.

The post itself is substantive [1], so we've unkilled it and attempted to give
it a neutral title.

1\. Edit: though dismayingly not free of the same drama-mongering. Hopefully
the HN thread will stay substantive in response.

~~~
colin_mccabe
I think this post _is_ linkbait. The author's title is "Golang is trash," but
the post doesn't discuss anything about Golang. Golang is a programming
language, and the author admits that he has "no real opinion on the language
itself" (his words). This blog post discusses some pretty esoteric details
about a particular toolchain, which is not even the only production-ready
toolchain available for Golang at the moment, as the author freely
acknowledges. If there were a blog post titled "Lisp is trash," that proceeded
to talk about obscure implementation details of a certain version of CMUCL, I
think it would be flagkilled-- and this should be too.

I also feel like there are some factual errors. He chides the Go developers
for "arrogantly ignoring" existing tools for linking code. But the gccgo
integration was done by Ian Lance Taylor, who is on the Go team at Google. I
believe Rob Pike is on record as saying that he wanted multiple
implementations of Go to increase the robustness of the language.

I would appreciate a good critical look at the Golang runtime and toolchain.
How does its performance stack up, how fast does it compile, etc. But this
ain't it. This is a guy complaining that he doesn't like the naming of
registers in machine-generated binary files. I will literally never need to
care about any of this. I don't even need to know this to make use of assembly
language in my Go programs, since I can use the C library integration for
that.

~~~
dang
I probably should have been clearer. By "substantive" I meant substantive
enough not to be flag-killed. In most such cases we typically replace the
title with a more neutral one and, if the thread goes flamewar, penalize it.
It's rare for a controversial post about programming to get killed outright,
unless it's obvious junk.

------
jevgeni
echo `curl [http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-
trash/](http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/) |
html2text | wc -w` words of seething envy

~~~
jevgeni
Oh wow, didn't know PS crowd so strong on HN.

~~~
jevgeni
Ha, joke's on you: I've learned NOTHING!

------
gaalze
how does go compile so quickly?
[http://stackoverflow.com/questions/2976630/why-does-go-
compi...](http://stackoverflow.com/questions/2976630/why-does-go-compile-so-
quickly)

because they fucking forgot incremental compilation
[http://en.wikipedia.org/wiki/Incremental_compiler](http://en.wikipedia.org/wiki/Incremental_compiler)

~~~
infogulch
Wait, it's fast _because_ they didn't include incremental compilation?

~~~
gaalze
It's fast because of dependency analysis. They forgot about something called
incremental compilation.

This is what they should have spent their 20% on:
[https://gcc.gnu.org/wiki/IncrementalCompiler](https://gcc.gnu.org/wiki/IncrementalCompiler)

~~~
btilly
Actually they do have incremental compilation at the package level. Use go
install and you'll get it. Use go build and you throw away intermediate build
artifacts so you don't get it. This is all documented.

In practice compilation times are not a pain point for golang.

~~~
infogulch
Even better, `go get ./...` installs all dependent packages.

------
bkeroack
"Golang is trash" is the first line of this article, and yet somehow it makes
HN front page.

~~~
coldtea
Articles are supposed to be technically correct.

Is there any rule about also having to be tactful if they fulfill the first
criterion?

