[sergiotapia]

I just wish Go would let me compile and run with a flag -allowing- unused imports. I find myself wasting a lot of time hunting down unused imports or variables and commenting them out.

Maybe that'll be a non-issue the more I use Go, but so far it's a bit of a time waster.

[AYBABTME]

https://github.com/bradfitz/goimports

[jerf]

To explain to those who may not know what's going on here:

Go forbids importing modules that you then don't use in the source code. This is particularly annoying with the "fmt" module, which contains things like Printf that are useful for debugging, but you may only be using fmt.Printf for one debugging statement in the code. Consequently, if you're developing, and you're adding and removing it over and over you also have to add and remove it to and from your import list over and over, which is very annoying since it's likely to be relatively distant from your use location, and it's mandatory that all imports are listed at the top of the file. (So, you can't do what you can do in perl and say "use Data::Dumper; print Dumper($debugging_stuff);" all on one line, without even being concerned about whether Dumper may already be imported.)

goimports is a source filter that cleans out any unused modules, and tries its best to add modules that you only reference. It's pretty good. You can confuse it if you have two modules with the same last bit of the name, but the standard library doesn't have that anyhow, and for the most part you can deal with that. Since it also runs gofmt for you on save, it's also a drop-in replacement for gofmt, which you should configure your editor to run on every save even if you for some reason don't want the goimports functionality. (Seriously. Just do it. There's no excuse not to. There's no excuse to ever commit code that was not gofmt'ed.)

If you do that, the problem goes away. Typing "fmt.Printf" pulls fmt in automatically, removing the one line removes it automatically, the import list is always accurate, and it's smart enough that if it isn't the only usage it doesn't remove it.

That said, I also strongly recommend setting up automatic syntax checking by compilation (flymake in emacs, don't know what in vim, etc), so that you also avoid the "Save -> switch windows to terminal -> compile -> get smacked in face with an error that feels stupidly persnickety" psychological torture. If the errors highlight in your editor on save or something, you go through that much less. Those who lived in the C#/Java etc world have long had this... a lot of people coming from the scripting side would be advised to pick up a bit more of the helpful tools the static side has to offer.

[mediocregopher]

> flymake in emacs, don't know what in vim

https://github.com/scrooloose/syntastic for vim.

[kevrone]

It's worth mentioning that the author of this tool is Brad Fitzpatrick, one of the main contributors to the Go standard library and, in my opinion, the most "entrenched" Go developer on the team. And by that I mean he uses Go to build large and practical projects on his own (See Camlistore), so he knows what the language feels like from a perspective similar to the rest of us. He's also one of the only advocates on the team for the inclusion of generics.

[artursapek]

Exactly. I have vim handle it for me every time I save. No problemo.

[krat0sprakhar]

Can you elaborate on how you are doing this? Would love to add this to Vim. Thanks!

[rmcpherson]

Try https://github.com/fatih/vim-go. It adds seamless support for all the go tooling to vim, including go-imports.

[kevrone]

There are some instructions in the docs for this: https://godoc.org/code.google.com/p/go.tools/cmd/goimports

For sublime users, see here: http://michaelwhatcott.com/gosublime-goimports/

It's a great tool, very convenient.

[artursapek]

One of the things I love most about Go is how everything you need comes with the language, unlike many language ecosystems where you have to depend on third parties for profilers, plugins, etc.

[mattgreenrocks]

Maybe Go is trying to tell you that the "move fast and break things" methodology is not how it should be used?

[sergiotapia]

I know right? I do feel a warm fuzzy feeling when things compile and I generally feel much safer than when building things in Ruby.

[mattgreenrocks]

Me too. I don't mind working in a good C++ codebase. It feels a lot safer than working in Ruby where things suffer from bitrot due to a culture of new and shiny.

[kjs3]

When I talk to the youngsters about this exact feeling they look at me like I'm nuts. Coming from Ada/Modula-2/etc. where you put the thought in up front and if it compiled you were a long way to being "right" isn't something they get.