5 ms·
Stopped reading after author considered IDE's to be a code smell. I mean honestly - they are there to make life easier and speed up writing code. 99% of the tim
by hacker_9 11y ago
Stopped reading after author considered IDE's to be a code smell. I mean honestly - they are there to make life easier and speed up writing code. 99% of the time I only have to type 2 chars + [TAB] and autocomplete completes the word for me. Now I have a descriptive word that I can read and write in less than a second. How is this bad? Coupled with contextual member browsing on typing a '.', and contextual rename refactoring, and contextual errors/warnings underlining...
The fact that Go doesn't have an official IDE is actually what stops me from going near the language.
- deleted 11y ago[deleted]
- ane 11y agoEven if it's not official the IntelliJ Go plugin is quite good. It recently added support for a debugger, and it has a lot of static analysis capabilities and refactoring. I would say it is on par with other environments for most serious languages. The Emacs go-mode and vim-go are good enough but not as great. There is a general attitude in the Go community eschewing all sorts of complexity be it in the language itself or tooling and this attitude is toxic and stupid. It will prevent Go from becoming a serious language unless this nonsense about "simplicity" is left to perpetuate. There is nothing wrong with keeping a language elegant--cue a brouhaha about generics in 1... 2... 3...---but forcing this attitude to tooling is not a wise thing to do. A significant majority of professional devs do not write their code in vim without syntax highlighting, which is what some eminent members of the Go community seem to be in favour of. They need auto-completion, refactoring (which search and replace isn't), automated deployment and testing, debugging and project support.
- adrusi 11y agoFor the state of the art vim and emacs go support, look at gocode, which runs an auto completion daemon. I don't know what you mean by "forcing this attitude on the tooling". The only thing that people tend eschew a tool for is if it's too big, like ides tend to be. Go has a plan9 heritage, and therefore a unix heritage. People like the tools to be small and designed to integrate. The reason that I like writing go is because save for C, nothing else feels as unixy, as vague as that sounds. It sounds like you ran into some hostility. If people are railing on others about their IDE usage, they're assholes, and assholes do tend to stick out. Go is opinionated, and while that tends to make for a cohesive ecosystem, it also attracts assholes unfortunately. Most go developers, though, while they aren't interested in an IDE for themselves, have no problem with someone else using one if they prefer that mode of working.
- Kurtz79 11y agoYou can have basically all the "official IDE" behavior you are listing with Vim or Emacs extensions (of the editors I know of). If you are not going near a language for the lack of an "official IDE", you are really limiting your options.
- Alphasite_ 11y agoYes, but at that point, aren't they just text based IDEs?
- Kurtz79 11y agoYes, that's my point. Why would you need an official IDE, since many advanced text-editors can offer similar functionality ?
- Alphasite_ 11y agoYes, but at that point, aren't they just text based IDEs?
- CmonDev 11y agoHe is just in love with the shiny toy: Go is good, Go doesnt have and IDE => IDE is bad. I have seen a guy on HN saying that debuggers are bad and logging debug messages is superior :). Future is here, but it is sooo unevenly distributed.
- hacker_9 11y agoThat's another good point - no official go debugger. Additionally IDE's give you breakpoints, line highlighting, contextual variable inspection and so on.
- sagichmal 11y agoFor certain classes of software development, specifically distributed systems, debuggers are bad (or, at least, effectively useless) and logging debug messages is superior (because it's the best way to rebuild a chain of causality). It's all about context. Go is a great tool for certain things. Understand the boundaries of those domains, rather than castigating the tool.
- robmccoll 11y agoIDEs can be a crutch. To me vim is genuinely faster at text navigation and manipulation to the point that none of the benefits of an IDE are worth the trade. Plus you can add many of the features you mentioned to vim quite easily but adding an accurate an useful vim-clone mode to an IDE can be difficult. Being able to select a block of code with a keyboard shortcut and then apply a complex regular expression search and replace inside that block and reformat the block in pure fast keyboard shortcuts is too powerful. Really the only time I ever end up in an IDE these days is if I need to build a GUI. Even then I usually drop back to vim for the code editing.
- Alphasite_ 11y agoRelying on the accuracy of a VIM mode implies that the best way to do with VIM does is to do exactly what VIM does, when there may be better, but less familiar ones.
- mmarx 11y ago> Stopped reading after author considered IDE's to be a code smell. That's not what the article claims, however. The author critizes languages that _require_ an IDE, not the availability of IDEs.
- ceronman 11y agoI think his point is that writing Go with a simple editor is just fine. Some languages are a pain to write without an IDE. On the other hand, I'm with you on the fact that not having a good IDE is actually a bad thing. If you want to code with a single editor, that's fine, but IDEs boost productivity a lot once you learn how to use them. Not having a proper IDE is a minus for a language in my opinion.
- melling 11y agoThere's a Go plugin for IntelliJ but I haven't used it in a while. There are plugins for vim and emacs too. Currently I use Sublime Text with a Go plugin. It has autocompletion and runs the formatter on save. I've built a couple of personal websites with Go. http://thespanishsite.com http://thespanishsite.com and http://www.h4labs.com http://www.h4labs.com (on AppEngine) I love the performance. They were in Python before. You'll notice the difference once you start to build things with lots of data like my little Swift "search engine": http://www.h4labs.com/dev/ios/swift.html http://www.h4labs.com/dev/ios/swift.html
- tomchristie 11y agoLink is "Needing an IDE should be a code smell". Nothing controversial there.
- laumars 11y agoGo does have IDE features in it's tooling though (eg gofmt). A lot of text editors use Go's official tooling and basically end up functioning a lot like a cut down IDE (eg Sublime has autocompletion, build tools, etc). There's even vim plugins to run these tools. So it's a little deceptive when some within the Go community argue that they don't need an IDE because half the time they're basically running their text editor as a lightweight IDE. As an aside note there's also LiteIDE which, at one point, was the "unofficial official" Go IDE - if you will. A de facto recommendation for anyone new to Go and fancying an IDE. I'm not sure if anyone still uses it for any serious Go development but that supported a few more features that the average Go-enabled text editors didn't at that time.
- laumars 11y agoWhy on Earth was this down voted?