1. 32
    Golang is Trash go rant dtrace.org

  2. 26

    The title definitely reflects some emotion, but it should be understood that this came from the author’s intense frustrations porting cgo to illumos. (As a disclaimer: I’m the one who put the author up to this – though it would be incorrect to blame his retirement[1] on this work.) Having dealt with the underbelly of Go in the past (on the initial Go port to illumos), I can understand the wellspring of this frustration: there is much in the Go implementation that leaves one asking “but… why?!” I also do think that there’s a bit of an attitude of smugness from the Go implementers that tends to exacerbate these frustrations – and I think that’s part of what Keith’s reacting to here. Which is not an attempt to apologize for the more vitriolic bits, but merely to explain where they’re coming from.

    [1] http://dtrace.org/blogs/wesolows/2014/12/29/fin/

    1. 14

      I think I’m missing something. I’ve written some go. The fact that there are comments about assembly program being hard somewhere in the go source has never bothered me. I’m having a hard relating these complaints back to something I’d care about.

      1. 20

        I think I’m missing something.

        The author really doesn’t seem to like Rob Pike.

        1. 11

          This is really the only thing I came away from the article with. Can’t shake the feeling that the author is reading into the things Rob said with some heavy bias.

          1. 16

            The more I read his other posts, the more I think I should edit the above comment to read “the author has a burning hatred of Rob Pike”.

            the psuedointellectual arrogance of Rob Pike

            World-class jackass Rob Pike

            There are plenty of other problems with Mr. Pike


        2. 16

          Have you ever debugged a problem that was actually caused by a bug in your compiler? I have. It is, I can assure you, Not Fun (well, it’s kind of fun as an intellectual endeavour - but when your business depends on it, not so much).

          The quality of the implementation is, IMO, one of the few nonobvious things that should be a showstopper when choosing a language. If the syntax is unpleasant, you can put up with that. If the libraries are bad, you can write your own. But if the language implementation is buggy, if the compiler is broken, then you’re screwed - and by the time you find this out, it’s probably too late. If the language implementation is… not buggy, so far as you can tell, but the code looks shoddy, then that’s one of the biggest red flags I can think of.

          (I have not looked at the go source and have no particular interest in the language, but as a general rule when choosing languages, yes this kind of thing absolutely does matter, assuming the author’s assessment is accurate)

          1. 17

            That’s fair, but the complaints here don’t seem to be about quality. Rather, “Rob Pike has opinions not consistent with the GNU toolchain” I have as much concern about toolchain quality as anyone, but it will be hard to convince me that the Plan9 toolchain is low quality because it’s simple.

            1. 5

              In my reading his point isn’t that it is simple. His point is that it is flawed, without good reason.

            2. 3

              It would be a fair criticism if there was a problem with bugs in the Go compiler, but it’s actually very reliable. In fact I’d have to say the Go toolchain is exceptionally good from a user perspective all round.

            3. 8

              The criticism seems to do with the Plan 9-derived assembler syntax that is not compatible with existing tools. I don’t think that is justifies calling Golang or the compiler trash. The Plan 9 compiler is very mature and reliable code.

            4. 6

              Despite all this, he did port go to illumos, which is great because ilumos is an awesome OS.

              Farming is great fun, I hope he enjoys it.

              1. 4

                Golang is a language. If you don’t like the tools then fine, but this post is titled poorly. It alludes to the idea that the language itself is trash, when the author is actually just complaining about how the tools aren’t as mature as C’s tools - which should be obvious given how new the language and it’s tools are.

                I think that they have intentionally decided to build the tooling themselves because their goal is for the entire tool-chain self-hosted on code written in Go. Although it is not written in Go at the moment, porting it is on the roadmap. I feel like having relyied on something like GCC could have resulted in a lot of additional effort in terms of supporting the currenty existing ecosystem to a purely Go tool-chain while considering reasonable backwards compatibility.

                This is why I would suggest that the current implementation is potentially reasonable and not a result of poor decision making.

                1. 1

                  I’ve tried learning Go a few times, but always get put off by how… quirky it is. I can’t say I’m too surprised it’s quirky all the way down.