3 ms·
I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basica
by dvirsky 13y ago
I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basically mean: a rich editor, stable code completion, jump-to-declaration etc; and tight debugger integration.
Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short:
1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever.
2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build.
3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own.
4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day.
The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :)
Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.
- TylerE 13y agoJust curious, but what issues did you have with GoSublime builds? It's using the `go` tool under the covers.
- dvirsky 13y agoA few are just UX quirks - ctrl+b tries to build from the current package, not the project root, leaving you tabbing to main.go for each recompile, which is annoying; cursor "runs away" from the prompt not affecting anything. but mostly, the output is buffered. I wrote a toy MapReduce framework that yielded tons of output. It crashed Sublime because it buffered the entire output into the console instead of printing it into some sort of FIFO buffer like IntelliJ or Eclipse do. Again, running from a terminal is ok, but the whole point of an IDE is to save you from fiddling with lots of windows and terminals.
- Ziomislaw 13y agovim + a bit of tweaking , ie. completion plugin [1] (probably there is an emacs mode too - which has all of the above) [1]: https://github.com/nsf/gocode https://github.com/nsf/gocode
- dvirsky 13y agoI tried the recommended vim plugin. it was okay, nowhere near as powerful as intellij's plugin - and still didn't solve my gdb issue.
- papaf 13y agoAlthough it is not as shiny as modern IDEs it is worth making the effort to use emacs - and I say this as a vi user :-) Whenever a new language comes out it is usually supported by emacs and vim (go has the support files in the source tree). Learning emacs is a small but frustrating investment in time that pays off over the years. Of your points, it has a rich editor and tight debugger integration. Jump to declaration is a pain but possible using exhuberant etags [1]. You may even prefer using ack [2]. Emacs does code completion but I've never been bothered to get it working. [1] https://groups.google.com/forum/#!searchin/golang-nuts/emacs https://groups.google.com/forum/#!searchin/golang-nuts/emacs [2] http://www.emacswiki.org/emacs/Ack http://www.emacswiki.org/emacs/Ack