Hacker News Reader

Comment by bane | Hacker News Reader

Curious about all the Go dislikes. From the kind of things that get posted here I'd have assumed it to be almost universally liked. Anybody can provide reasons?

View on HN

Type system without even basic generics (even though the standard library needed them), never mind higher-level type constructs. Clunky special-casing of error-handling and concurrency, because the type system is not powerful enough to handle these in elegant ways. C-like simplicity but garbage collection makes it unsuitable for systems programming.

I think the popularity comes from a number of googlers using HN and upvoting related stories. A lot of go fans seem to be people for whom it's their second language after python (or possibly their fourth language after python, java and c++ - the only languages that google employees are allowed to use, AIUI). So they see a language that's more expressive than java, less crazy than C++, safer and more performant than python, and think it's the best thing since sliced bread.

There are some good things in go. An opinionated formatter that ships with the language is a great idea. Static duck typing is an interesting idea, though IMO less useful than either alternative - it means you can't do the equivalent of newtype, which is something you use all the time when coding in a properly typesafe language because it lets you catch so many errors. If you look at the scala community, there's a syntax for doing this... and almost everyone's agreed it's a bad idea. The concurrency model is... worth pursuit and I'm glad someone's trying it, though ultimately I think it will prove less practical than e.g. Erlang-style approaches.

It's not the worst language ever. But it utterly fails to live up to the hype. I've yet to find anyone who likes it having previously done a serious project in Haskell/Scala/F#/OCaml.

For me, it just feels like instead of taking efforts to carefully design the language, they just picked the first thing that worked and froze it. And while I really like some features of the type system (such as interfaces, lambda/function types, multiple return values, and the "type switch"), the lack of overloading and generics does have some pretty serious effects on readability (especially when you have compiler-supported functions that do overloading and generics, but don't allow it in userland).

It also seems like the way they resolved a lot of issues in the surrounding tooling was to not decide. For example: how many spaces should we use? Screw it, we'll use hard tabs! How should we handle dependency loading and package management? Screw it, we'll hard-code the URL to our dependencies in the source code! How to handle dependency versions? Screw it, we won't!

It's not a horrible language (like shellscript), but I think they wasted a lot of opportunity to make something better.

A lot of the things you're claiming the Go designers chose off-hand one afternoon are really things they've liked and been doing for decades. Take a look at the Limbo programming language and you'll see a more primitive version of Go; it was written by a lot of the same people. Before Limbo, there was Plan 9's C dialect and its associated libraries, which have some similar elements. Before Plan 9, of course, these guys were creating Unix. Many elements of Go are the evolved preferences/decisions from people with decades of Unix development, such as:

> For example: how many spaces should we use? Screw it, we'll use hard tabs!

The only sane choice, and one that, again, goes back decades for these guys. You use one indent character per level of indentation. Boom. If you don't like seeing 8-wide tabs, fix your fucking editor. If you're worried about lining up all your code in perfect multi-line arrangements, maybe rethink your life.

> How should we handle dependency loading and package management? Screw it, we'll hard-code the URL to our dependencies in the source code! How to handle dependency versions? Screw it, we won't!

They should have never done the URL thing; it was a cute demo, but people took it as some sort of commandment to write code that way. If you want a real, stable set of dependencies with control over which version gets used, you should do what C and C++ programmers have done for decades and include the appropriate dependency source code in your distribution. Brad Fitzpatrick (core Go author) does that for Camlistore: https://github.com/bradfitz/camlistore/tree/master/third_par... and I do it for my own projects, if they're more than a quick test.

> If you're worried about lining up all your code in perfect multi-line arrangements, maybe rethink your life.

But...`go fmt` does this for you :-)

    type Magic struct {
    	CastingCost string
    	Id          int
    }

Even though I'm not really a fan of the choice myself.

Yep... although if you look at that, it's just lining up based on tabs. I like gofmt because it barely ends up changing my code--I already write it pretty much like that! I was talking more about when people want to do things like this:

  func someFunc(arg1 string,
                arg2 string,
                arg3 int,
                ) bool
  {

and get very angry when the arguments don't line up perfectly under each other using just tabs. And, presumably, that Go won't let you put that { on the next line like that.

When I tell these people I often use an editor with variable-width fonts, it damn near gives them an aneurysm.

I've not been impressed with Go. The type system is painful and weak, and some of the choices with the way packaging are performed seem poorly thought out. It's not a terrible language, but I don't think it's a good language either. Rust on the other hand, now that has some potential as a systems language.

Reply on news.ycombinator.com