This highlights my biggest criticism with Go (although I am a fan generally), the lack of a great IDE with powerful refactoring, debugging, test runner integration etc. These tools can be a great advantage of having a strongly typed static language. The current options are below par, hopefully jetbrains will step up and fill the void.

General response to comments: I think some people may not have seen what you can do with a good IDE and a strongly typed static language. Want to rename a function throughout the entire app and guarantee it works, no problem. How about moving a file and having all the imports changed to the new location, easy. You can't do that in ruby, but in Go/Java/C# it should be trivial with good tooling. If that does exist I would love to see it.

My OS is my IDE. For everything else, there's the go tool, which does testing and now renaming, too [1].

The debugger would be nice, and Delve is a great start it looks like -- but I can't tell for sure since it still isn't compatible with OS X.

[1]: https://groups.google.com/d/msg/golang-nuts/96hGPXYfqsM/WreO...

> My OS is my IDE...

That doesn't necessarily invalidate the parent's statement "the lack of a great IDE with powerful refactoring, debugging, test runner integration etc".

> My OS is my IDE.

That sounds like a highly coupled IDE?

The unix philosophy has been chugging along for decades now. It's hard to compare it directly to e.g. Visual Studio but it's very powerful.

And Rob Pike really loves the unix way being one of the inventors of it. It doesn't seem weird that Go would take that route.

These tools actually do exist for Go, they just aren't packaged in an IDE. The biggest problem with them is (in my opinion), a lack of documentation around the usefulness and use of these tools. Tools like gofmt allow for automated formatting, mass renaming, and import moving, for example.

One of the things I think it great about Go is how easy the developers of Go have made it for other people to tie into the Go compiler's lexical analyzer, giving it an easy API to work with and making it a core package, which is why there are so many mutant compilers built for Go. Using these, I think it would actually be very easy to write a powerful IDE for Go, it just hasn't been done yet because I think Go's target audience (systems programmers) are not all that interested in IDE's, but that is just conjecture. Right now, the closest you can get to an IDE experience is to use the faith's vim-go set of plugins for vim, which allow you to map keys for all of the basic IDE functions and even allow you to browse compilation errors and formatting errors in a seperate pane with controls to navigate to the line in files where those errors occurred. If you are not comfortable with vim, however, I do not know of any alternatives at this time.

I haven't done this myself, but I have read that you can use the gdb to debug Go code.

> because I think Go's target audience (systems programmers) are not all that interested in IDE's,

Target audience or not; it seems that most people that write about Go and state their background have a background in some scripting/dynamic language. But those are the people that write about stuff like that; they may be a vocal minority, for all I know. But Pike has written that he was surprised that relatively few from languages like C++ has made a transition.

I don't get why you're being downvoted. I write Go professionally and I've been doing all of my work in Go for 2 years. I used Sublime/vim/emacs, and I'm very productive without an IDE.

Still, there are many features of IDE's I wish we had, like extensive refactoring. I was making heavy use of those in Java.

It's very easy to write software that manipulates Go code, so I know it's just a matter of time before all those equivalent (and more!) tools get out. So much that I feel a lot more productive in Go today than I ever was in another language before. Go works really well without an IDE, but just imagine how much more you could get done with an environment that ships out of the box with comprehensive tooling for refactoring, debugging, profiling, etc.

I think it's counter productive to not acknowledge, or be dismissive, of what comprehensive IDE support can provide to your productivity in a stack. Tooling in Go is awesome, but there are gaps. Debuggers and more-than-gorename refactorings are to big bullet points in my personal list.

[edit]: OP was being downvoted when I wrote this.

Forget having an IDE, I'd be happy with a working debugger. Current debugging support through gdb is borderline unusable. :-/

Exactly. I read somewhere that Rob Pike and another core Golang contributor are working on a Go debugger.

Well, there was a certain ogle in the repos before, but it seems it's not being developed any more?

Edit: It is still being developed.

Last change was in Sept:

https://code.google.com/p/ogle/source/list

As others have said, gorename does the type-safe renaming... it's relatively new, so it's understandable that you may not have heard of it.

Moving a file doesn't really make any sense in Go. Files are not units of code that you'd move... I presume you mean moving an exported type from one package to another. I don't believe that gorename can do that right now, but it seems like it would be pretty easy to add to gorename.

> The current options are below par, hopefully jetbrains will step up and fill the void.

There's a third-party plugin that's come a long way (https://github.com/go-lang-plugin-org/go-lang-idea-plugin).

You can vote on having an official plugin here: https://youtrack.jetbrains.com/issue/IDEABKL-5938

Go has really good tools. oracle, godoc, go test, go fix, imports , built in memory profiler, built in cpu profiler, full auto complete and error highlighting in multiple text editors (sublime, emacs, vim) and an automatic code formatter.

I don't think you understand how you are meant to use the tools if you think they need to be in an ide to be useful.

A suggestion: I think your statement would be much better received if you phrased it positively, rather than negatively. "Go is great; here's how I use it" is much more helpful than "Go is great; you're doing it wrong".

I agree, but I must accept the consequences of my actions to be truly free from guilt.

I have no objection to your editing your comment to include a summary of how you put the go pieces together. Redemption is so much better than guilt ;-)

Disagree, there's no difference. A -> B·C <==> A -> ¬(¬B+¬C).

Not a logical difference, yes. But there is a different connotation.

Absolutely. There's an included parser that I could use to do big refactoring of a precision and scale I haven't seen available in any IDE.

Would I rather write a single purpose code formatter like go fmt, or write the equivalent non portable plugin for eclipse or visual studio.

In my mind the answer is very clear.

Wait- doesn't LiteIDE do those things? (I realize current GDB support isn't great, but thats not LiteIDEs fault).

LiteIDE is what i'm using right now, but it's really alpha quality (which is not a blame, we all have to be there one day).

It doesn't even do auto-completion properly, so i wouldn't make it do more complicated stuff such as refactoring through multiple files.

You might have it configured incorrectly? I have been using the auto-complete without issues for years.

Most ruby developers I know write code using VIM. Of course everybody uses his plugins and '.vimrc' file, but I don't see why an IDE is necessary.

The integrations you're asking can be done easily by glutting the tools you need e.g.: tmuxinator + guard + rspec + vim gives you all that and more...

Most Java developers I know write code using Intellij. I used to use VIM for Ruby development and tricked it out with many features to speed up my development. Having said that, Intellij is so much easier to use for Java than tricked out VIM is for Ruby.

Visual Studio with ReSharper is also great (when working with C# code). It really makes you develop code faster. I suppose CodeRush works equally well.

> General response to comments: I think some people may not have seen what you can do with a good IDE and a strongly typed static language.

Personally I'm not sceptical towards IDEs because I don't see the use in them. I'm sceptical towards IDEs because they are so integrated. In Go's case, if they want all the functionality of a modern IDE (at least eventually), I'm guessing they will realize it by putting a bunch of already existing tools (like a debugger, renamer, formatter, etc.) together. I guess this means that all the tools could be used individually, but also as more of a whole. And also this "whole" can be adjusted on a per need basis. Go might be opinionated about the formatting of Go code, but should there be an IDE that is opinionated about the kind of editor one uses to code Go in? (Maybe this isn't inherent to IDEs, but it seems to be what happens.) Rob Pike might prefer to use the Acme editor, others might prefer Emacs or Vim (and not just "emacs keybindings").

I think a lot of people are sceptical against combination of small tools since you tend to end up having to learn how to combine them, which may or may not be easy. There is nothing stopping Google from developing an IDE that internally uses a lot of small tools (refactoring parser etc) and also makes the same tools availible as separate things from the command line. I still think the visual feedback from a good IDE is worthwile and the user interface is usually much easier to work with.

> Personally I'm not sceptical towards IDEs because I don't see the use in them. I'm sceptical towards IDEs because they are so integrated.

This is like saying you're skeptical of ATM's because they are machines.

.gitignore ignores "foo" and "bar". Should I trust the rest of the project? Is this a convention?

I for one endorse the ban of that terrible form of "meta syntax".

The real question is if it can debug itself.