I'd also say that many of these things are trivially fixed in other languages using tools. Most big projects have some code style guidelines which can be enforced using a linter and any good Java IDE can auto-clean imports lists for you at commit time (IntelliJ can be configured to auto-optimise imports just before commits for instance).

Making the compiler super strict about it seems like a good way to make quick changes awkward. Especially when there isn't a strong debugger you often end up commenting bits of code out or adding "return true" type statements half way down functions, and it's annoying when the compiler refuses to let you do it. This is one of the things that bugs me about javac - if it detects dead code in a function it refuses to compile. Maybe I'm weird but in my work this has caught legitimate dead code exactly zero times, but has triggered false positives due to transient debugging changes eleventy bazillion times. Luckily javac is dumb and you can trick it by just writing the code as "if (true) return;"

Both Eclipse and IntelliJ have supported cleaning up imports and running style tools on every save for years.

I have no idea why this would be a core part of any language.

It's not part of Go-the-language. It's part of the distribution of the most popular (ok, only) implementation of that language.

Not true.

It is illegal for a package to import itself, directly or indirectly, or to directly import a package without referring to any of its exported identifiers.

- https://golang.org/ref/spec

What?

I'm saying that the tooling that helps manage import paths in the way you want is not part of Go-the-language.

The language restriction against unused imports certainly is.

>These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project planning meetings. Everyone feels the need to bloviate about 2 vs 4 indents, tabs vs spaces, or which lint flags to enable/disable.

It was in one of the numerous Go talks/videos/presentations where I think it was Ken Thompson who said that he could walk around the Google cafeteria and hear Python programmers arguing all day long of how white space should work, and in Go, those discussions just don't happen. It's done. It's been decided. Move on.

It really struck a chord with me. It's amazing how smart people, given enough free time, will argue non-stop about the most irrelevant, insane things and stop themselves from being productive.

> stop themselves from being productive.

I disagree with you here. First, just because people are arguing about irrelevant insane things doesn't necessarily mean they're not productive. Second, I love those trivial arguments because at the end of "lunch" I've taken a break from the more involved thought, floated up to lighter stuff for a while, had some fun, and can now easily get back to the tasks at hand.

I bet there are equally many Go programmers at Google who argue that the "right way" imposed by the Go design team isn't that "right".

I agree with a lot of these (and would be interested in adopting a language that followed them - but one with a decent type system), but I don't think that's the Go innovation. Python had opinions about whitespace and never attracted the same level of hate.

Python's long in the tooth right now, but the first few years the whitespace thing was the source of much cursing and gnashing of teeth.

edit

More to your point, though. I would never choose a language for a project because it is strongly opinionated on such things. However, when choices lead to an opinionated language I find the feature a positive rather than negative edition....even if I find a particular decision annoying at first.

Python's whitespace has arguably produced metric tons of heated discussion on the net since Python's inception. Back in the day it was often the main thing outsiders (jwz comes to mind) rejected.

That and also, that Python has a very Go-like attitude of "do it our way, no, your way has been disabled, our way is the only way."

Arguably, that also explains its success.

I think Python's mandatory whitespace has a similar nature as Go's unused-as-an-error. They are definitely great in production code, but when I play with code, sometimes I do want to mess them up while adding and removing the parts of the code. Even though I've used Python for more than 10 years, I often feel like "I don't want to indent these lines for now. I wish there were a way to wrap them up without changing the indentation" after copying and pasting some lines.

Your editor can indent / dedent whole regions of code with just a few keystrokes. If this is not true, find another editor.

But then again, unfortunately, Python's significant whitespace makes automatic indentation hard, because there are some edge cases that an editor cannot extract the actual intention by the programmer well. For example, if there is a code as:

  for i in range(10):
      if i % 2 == 0:
          print('hello')

and I paste `print('world')` after that, there are at least three possibilities of the proper indentation of the line. It can match with `print('hello')`, or with `if`, or even with `for`.

That's because Python encodes block information solely using whitespace. So, if the indentation changes, the actual meaning of the code also changes! In fact, that's why it is called "significant". You cannot automate it, just like you cannot automate writing code.

in my editor, I press "tab" anywhere on the line with print('world') and it cycles between the three options.

If I want to move a whole block in one level, I select the block, then press control-C and '>'.

That's what I mean.

Uh, yeah, same for me, but that's the "I don't want to indent these lines for now" situation that I mentioned above... Wasn't I clear about that?

To me, regardless of the number of the key strokes needed, it's still a manual indentation that bothers me more or less while coding.

> features like formatting, no unused imports, etc.

I personally think these should be configurables turned on by default so you kind of push the new comer to write good code and build better habits but there should be an option to disable it, make it hard to find but it should be there, especially for the people like OP and other small over-the-weekend projects.

The goimports tool can be used to automagically add and remove imports to your .go source files as you work. This streamlines the casual weekend hacking use case without compromising on the benefits of disallowing unused imports.