[LeafStorm]

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.

[jff]

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.

[staunch]

> 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.

[jff]

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.