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