This was highly unexpected - as they had said they were exploring golang when I had asked their support last time.
Jetbrains has yet to let me down - They got me covered for Java, C++, PHP and JS/TS and now they have a golang IDE - I will definitely be learning go with a lot more enthusiasm.
If you are using VS Code for TS, and you think that's awesome...give Webstorm a try. It's a whole another level.
While it's a paid IDE and that might not go well with a lot of people...it's one of the best software I've paid for (and something I use daily).
> If you are using VS Code for TS, and you think that's awesome...give Webstorm a try. It's a whole another level.
Actually it isn't. Webstorm is a memory hog. While there is a notable latency with VSCode, it doesn't feel like my computer is crashing each time I use it. Jetbrains products are great for Java,Python and PHP dev. Just not for Javascript development. Furthermore, VSCode obvious advantage is that it is written in JS, making it easier to develop custom plugins without the need of for complex Java SDK.
Being a memory hog and being a much better IDE are orthogonal to one another. Get more memory. It is so much better for Javascript development than the alternatives it is worth it.
If a program is unresponsive, while other memory-hungry programs aren't, the program is likely a CPU hog.
Try turning off some of the inspections.
Also, Webstorm being a Java program, you can control its memory consumption in the startup flags file, vm.options IIRC. Try giving it less memory. Or, if the settings are apparently way lower that the specs of your machine, consider giving it more memory.
I tried a JetBrains IDE for Python, but it seemed like a resource hog with little benefit. In particular, I'm curious to find out how this IDE will compare to go-vim.
I agree that this is a useful feature. I just wish I could decouple it from a bloated editor. `gocode`, for example, is a static analysis daemon for Go which is editor agnostic.
Good to know, but my criticisms of the IDEA apps are that they tend to be resource hogs. Perhaps this isn't the case for IDEAVim. Further, my main draw to vim is that I can use it right in my terminal--I don't like having to switch back and forth between my terminal (tmux) keybindings and those of my native OS. It's not for lack of effort either--I keep trying the new GUI hotness, but it never lasts long for the aforementioned reason.
This was from an old version of an IRC project.. basically, the main script sets up a $APP_CONFIG variable, which is the hash parsed version of a yaml config file. The files being included, which were plugins, could (and in reality, can) read this variable.
In short: If you run a Ruby program that sets up global variables, other ruby files required after that point can access those variables, even though Rubymine seems to think otherwise. This is documented in the program output linked to that bug report.
How prevalent is this practice? Is it considered a good, or at least acceptable, practice?
I suppose the developers mostly fix issues that affect many people, and affect reasonably written, idiomatic code. Name resolution in a highly dynamic language like Ruby is somehow tricky, and may be resource-hungry, especially in corner cases that you described.
It's unreasonable to have a configuration dictionary?
..Whatever. I love how both of you focused on the one example and completely ignored the two others. Have another one - Mako syntax highlighting in Pycharm has been broken for over a year now. https://youtrack.jetbrains.com/issue/PY-17932
I've been using VSCode for TS (nothing else though). Do you mind elaborating on why Webstorm is on a different level? Genuinely curious. I really like VSCode, but I have my complaints (mainly, it's a little slow on my MBA)
If performance is your only complaint, know that webstorm will probably be worse.
I LOVE the tooling in webstorm, but the it just eats up all my ram and pegs out the CPU on my 2011 MBP. And if it's trying to index a large project, I just take a break because it renders my machine almost unusable.
It's difficult to explain the benefits of Webstorm. It's really the combination of many small things that add up to a great experience. For example, being able to download+save an NPM module by clicking on the warning next to the "require()", built in code coverage reports, CSS refactoring, fixing imports automatically when you move a file.
... One time I tried to do "setX(y);" in one of my programs, and it warned me that I probably didn't mean to do that. Amazing.
If you have less than 8GB of RAM though, you probably don't want to use it for large projects.
While I appreciate contributions to the Go ecosystem, I have to say I don't get it when it comes to these types of IDEs. For me one of the great things about Go (coming from Java) is I don't need some fancy complex IDE. I just fire up vim with vim-go and I'm good. I was drawn to Go for the simplicity that it offers, sometimes in exchange for being a bit wordy, but that's a fair trade off for me. Using something heavier than vim or VS Code seems like overkill.
Is this filling a need that I'm just not aware of or is it a case of doing something just because they can?
It is a need you are not aware of. Maybe you can do everything in vim-go that you can do in IDEs but many people, including me, don’t want to learn vim and feel/are more productive in IDEs, especially as the code size grows. JetBrains only decided to offer the Go IDE after they saw the Go plug-in (that works in their other IDEs) take off. The demand is there.
Even knowing vim well (or rather emacs more so) I still prefer an IDE. The improvements to workflow are just something that I can't get out of emacs/vim, and for big projects those improvements are a necessity IMO.
That makes sense. Have you tried something like Visual Studio Code? To me that seems to be the half-way point between something like vim and a full blown IDE
I've switched from ruby-vim-linux back to java-ide-windows 2 years ago, while of course being a `downgrade` in a certain sense, having Intellij was A BLESSING, the VIM mode is very good and although of course I had to change some stuff in my workflow, I was surprised by how good and smooth the tool is and that I didn't feel "held back". I would consider using Intellij IDEs for other languages even if they're not "IDE oriented", there's no comparison between it and any other IDE I've used before(I make sure to point out to colleagues on Eclipse that they're cavemen to me and that my tool is like the sharpest fancy-Cook-knife and theirs is an old-blind-bread-knife and it's a piece of trash). Seriously, I consider it one of the best pieces of software I've seen and I plan on studying it's program design and code someday.
Answering your question, well, that's what they do, they have a lot skin in the `editor` and `developer tool` game and also a lot of stuff to build on top, so it's not a surprise they want to 'serve' a lot of languages. I don't know about Go specifically but I'd guess even if not 'filling a need' I'd think possible that they are capable of discovering ways of smoothing out the experience or something, which is valuable.
I felt the same way about IDEs in general, until I started using more features of CIDER (and Paredit) within Emacs for Clojure development. So many CIDER features I didn't expect to find helpful, turned out to be invaluable, and I later discovered that they're pretty much basic features of more full-featured IDEs like Jetbrains makes. So that really sold me on IDEs in general. That said, we're still using Clojure, and CIDER (plus Paredit) is still the best IDE (and path of least friction) for it, so I'm still using that.
I used vim for golang development for the past few years, however I recently switched jobs to a company with a large golang codebase and I struggled to navigate it efficiently with vim so yesterday I setup IntelliJ (with the vim plugin). It instantly made it easier for me to grasp the codebase. This might indicate that I had some gaps in my knowledge with vim, but either way I'm more productive now.
You can map keys in vim to jump to definition, view the underlying type, see implementera of a function. It's still nicer to me to be able to use a more visual IDE, but those things help. I think code completion like in Visual Studio Code makes things a lot nicer. I'm glad there is competition out there.
I fully agree with you. This new product seems to be bringing in Java paradigm to Go. In Java it is natural to have tons of scaffolding generated with IDEs which I think is unnecessary in Go.
But as you say maybe there is a demand for such product specially for people coming from Java background.
Wow, I did not expect that.
I'm currently using VS Code for Go and I'm pretty happy with it. Definitively gonna try this out because I'm pretty much using JetBrains for everything else and never got disappointed by them yet.
I started using Intellij's plugin for Go development but the debugger just didn't work (well... it worked once per OS boot)
VSCode's debugger worked well in the early stages of Go which why my team and I switched to it and sticked with it. VSCode is pretty awesome and, we believe, better than Intellij's unofficial plugin.
> If you are doing Go and not using it, you should!
That's a very assertive statement to make about something that's completely preferential.
For what it's worth, I tried VSC but really didn't like it. Partly because the whole Electron thing made it run like crap on modest hardware with lots of other stuff running. And partly because I didn't much like the defaults (font sizes, layout, etc). The latter could all be "fixed" to my preferences but IntelliJ and Sublime Text - both with their respective Go plugins - were already better aligned to my workflow so I saw little point wasting time on yet another "text editor with knobs on".
I understand why making a different IDE for every language is good for business, but I hate having to jump around to a different program for every different language I use, especially when pretty much all the IntelliJ derivatives are the same but with different plugins using the same plugin architecture. It seems redundant.
I'd try the plugins then. I like the separate IDEs because they tend to optimize workflows for the language in question without any extra JVM-configuration cruft, but the plugins really do replicate 99% of the functionality. For the other 1% (or if the plugin is lagging behind some killer feature release for a week or two) fall back on the separate IDE.
I definitely don't need that 1% usually, a long long time ago I thought I read they were massively (like months) behind the plugins, so it's good to know that's not the case.
I think there were a few releases where the lag was bigger, particularly in the early days of PyCharm. My take is as the IDEs have matured it's shrunk considerably.
after using vim and emacs for so long and occasionally eclipse this looks like a step backward. I routinely have two or three different language files open and can work on them simply by switching buffers. It saves a lot of time and clicking. I like some of JetBrains products but having to buy three different editors to do the same work I can do now is a bit of a turn off.
Agreed, it has pushed me back to using sublime/vim and scripts for my projects.
Also Eclipse gets a lot of hate, but when I was in college it handled our AUV source code with Python, Java, and C++ all in one project so nicely. I don't really know another IDE can that can handle that situation as well.
> I don't really know another IDE can that can handle that situation as well.
Eclipse gets even more hate and some of it is deserved. They had a few bad releases. But the newest neon release has addressed most of the mistakes they made. Eclipse has wonderful code completion for C++ even gcc on windows with custom libraries. And there are language plugins for Go, Python, Lua and many others that work quite well.
Nice to see that the IDE ecosystem is growing even more. I find it very useful as it shows very different features and use cases for other Go developers. Congrats on launching it.
I can't wait to try this out. I was recently pushed into a project that might possibly be implemented easier in go (a terminal application with a UI and an HTTP interface). I was fighting the other day to get Go working in one of my JetBrains IDEs and it doesn't want to work. I'll have to give this a 'go' (pardon the pun).
What does Gogland mean?
This is a codename and not the final product name. Our inspiration was the name of an island in the Gulf of Finland, not very far from Kotlin.
I did a bit of Go with the plugin and it was already pleasant. I guess one feature I'd like in dev mode would be transparent management of unused variables that the compiler don't like. As a web developer I may be accustomed to quick "code & try".
A bit off-topic but Jetbrains seems to be in a design-spree those days, with new flat & grey UI elements, which is not really a positive change.
I'm glad they released it for the sake of Go awareness. I love webstorm.
But the Go experience inside Atom is already exceptional. Navigate to definition, auto formatting, auto manage imports, debugging and breakpoints, automatic running of tests, and near-PERFECT code completion.
If Gogland offers anything over that, it'd have to be pretty awesome for me to switch, because JetBrains tools tend to be heavy.
Right now, I'm using Webstorm with the Golang plugin on a 2012 13" MacBook Pro with 16GB RAM. What's so heavy about Jetbrains tools? For me, it's quite a bit more responsive than VisualStudio 2015 on a 2016 Dell Laptop with 16GB RAM and a much newer processor. (Both laptops have SATA3 SSDs.)
I love webstorm. It is so slow on my 2013 13" core i5 MacBook Pro, compared to Atom. This week I think it froze twice. Its well worth it to get code completion and navigation, and debugging in javascript. Atom is pretty peppy for Go development so I would hesitate to use something different, all features being equal. Atom is slow to load, and dies on large files. So not without flaws. Typing and searching and all the Go features are fast.
It's a cost/benefit - I tend to favor the benefits of the JetBrains stuff (I do a lot of Java, so it's nearly a necessity). The only time I dislike their products is if I'm trying to maximize battery life.
The last time I tried Atom it completely locked up and had to be force killed if you opened any large files with it. That kind of made it a non starter for me because I consider that to be a baseline requirement for any editor.
I'm hoping that Jetbrains brings the Golang IntelliJ plugin in house. It currently has 400 issues, including one where you can't exclude the vendor directory from `go test`
I use PHPStorm because I have to to write safe PHP, not because I want to. I don't have that same problem with Go. 99% of the time if it compiles, it will run. I don't get the draw of a full fledged "Go IDE"
I'm sure you get something like flycheck out of the box, but what makes me use IntelliJ for Java is:
- navigating around the code: jump to interface, jump to implementations, jump to definition, etc. This sucks in Emacs even using etags.
- refactoring: highlight code, press a hotkey, now it's a function or a variable and all repeats have been replaced with references to it
Seeing a choice between Emacs and IntelliJ for Go, the decision comes down to how likely am I to use those two features. I don't do much Go, but the appeal of having that functionality is pretty significant. I would definitely try Gogland based on my experience with Java et al.
You wouldn't use etags for navigating go code in Emacs. You would use go-mode.
Emacs doesn't implement navigating and refactoring go code in elisp, as it does for other languages. For go, there are editor-independent tools, like go-guru, which are used not only by Emacs, but also for vi, vscode and multitude of others. Or just from command line. I would consider golang to be the last language, that needs an Idea-based IDE.
So does go-guru allow you to navigate code in emacs or not?
Being able to navigate the code (and refactor it, really) in the same place you are viewing it is a big win for me. At least in the other languages I care about.
> So does go-guru allow you to navigate code in emacs or not?
Yes (or at least, go-mode in total does): C-c C-j to go to a definition (annoyingly, not the stand M-. every single other language mode uses, why go-mode why), M-, to return up &c. Also, with projectile, searching an entire project (not just source) for strings & regexps is incredibly easy.
I'm not 100% certain, but there's a strong possibility that emacs invented code navigation.
I don't use emacs but I would be surprised if those weren't supported. Vim-go, VS.Code both offer those features through community plugins. I would not be surprised if JetBrains were using the same code services used by those plugins.
> How does this compare to what everyone with Emacs gets?
I'm gonna sound snarky, but not everyone wants to use an ancient editor. I could just as well make a case for vim. I use vim over emacs, but I'd choose a nice IDE over either. Beyond that, if you're well versed in the JetBrains ecosystem, it makes perfect sense to keep on using it.
It's a weird definition of "ancient" that includes editors for relatively new languages that have more features for those languages than IDEs dedicated to the language, right?
But I'm really just wondering how good this IDE's tooling is, comparatively.
The overall experience of using emacs is very dated. Again, for those who are not users of emacs it presents a deep burden. There is no barrier to entry in using a simple text editor, and a modern IDE brings that simplicity with additional niceties. Given a choice, I would use a simple editor with syntax highlighting over emacs.
Dunno why this is being downvoted. If your issue with IDEs are keyboard short-cuts, I guarantee you'll find a vim plugin, and if your contention is shortcuts in general then I'd really love to buy you a beer and hear your thoughts on other programming matters.
This was my first thought. I'm very new to Golang (and may never really adopt it), but i've been incredibly impressed with the tooling available in Emacs. I love Jetbrains, but I didn't see anything here that would pull me away from Emacs.
Of course, for anyone who hasn't sunk years of their life into learning Emacs, this looks like a fantastic IDE.
For me, I don't want to use. I am using both IntelliJ and VS Code. Now I stick with VS Code as it is exceptional well.
Gobland is just a commercialized version of IntelliJ for Go. I guess the next move is IntelliJ will remove Go plugin to force users using commercialized version.
I'm not a fan of JetBrains products, since they are slow, hog memory, and seem to encourage people to structure their code poorly. I do like the idea of using an editor called "Go-Gland" though.
Every place I have worked, that has made extensive use of JetBrains' IDEs, has had the worst structured code I've ever worked with. JetBrains makes finding classes and methods fairly easy within the IDE, so developers tend to hobble along on that crutch and don't take any time to think "Does it make logical sense for my code to go here?" before ramming their authentication code into the same library as the their customer notification code.
When you don't rely on an IDE, you tend to think about your code's organization more, since you have to work with that organization every day. When your IDE hides that organization from you, people's laziness kicks in, and you end up with code whose maintainability suffers outside of the IDE.
Ever worked in microsoft land? I swear developers have forgotten that folders exist and everything is organized flatly into "projects" instead, with terrible consequences on compilation times.
Yes. I worked at Microsoft on their Windows 2000 team, back in the day.
I believe Visual Studio suffers from the same issues as JetBrains' IDEs do, and also encourages similar poor programming practices. No argument from me in that regard.
Ooh! I seem to have touched upon a sensitive nerve here. By all means, naysayers, please demonstrate how I'm wrong about JetBrains being slow or a memory hog.
I'm not sure if this applies anywhere else, but in the U.K., this name has fairly extreme racist connotations. I don't think it's appropriate to explain further, but I hope they change the name.
Edit: I guess not very wide reaching connotations then!
This is a codename and not the final product name. Our inspiration was the name of an island in the Gulf of Finland, not very far from Kotlin. Send us your name ideas and suggestions!"
So a.) it's not final and b.) it has nothing to do with racism, there are lots of words that sound offensive, funny etc. in many languages, please don't think the whole word needs to be vary of our customs, it's at best elitist and at worst the "PC police".
If you feel so strongly about it, you can suggest a new name, but I am saying that they shouldn't have to change it. BTW everybody's fine with 'git' as well, why not this?
Setting aside the fact that it's a codename for an EAP product named after an island in a non English-speaking country, Gog could just as well be from Gog and Magog.
As a matter of fact, I don't even know what you're referencing: 'wog'?
Is a small province town called Guayaramerin in Bolivia this is a very offensive name for the Suarez family. I would change the name to avoid offending people.
So basically just the existing Go plugin (give or take a feature or two) shoved into a standalone editor which, knowing Jetbrains, is sure to be flust with new bugs for the foreseeable future..
They'll probably start that way, but will add more features closer to a 1.0 release.
Every one of their IDEs starts simple and then develops to one of the best in the industry, I don't see why this should be any different with Go.
Best in the industry? I wouldn't go that far. Considering how slow JetBrains tends to be with fixing bugs (I logged a few against PyCharm in 2011 that still haven't been fixed, which is why I don't use it anymore), how unstable their environment can become when debugging, and how they refuse to address Dvorak key-mapping issues in macOS, I think the furthest I'd be willing to go is that JetBrains makes some IDEs.
It also mentions formatting similar to 'go fmt'. So it is not integrating Go tools natively. Seems to be useful for people who love more mouse clicks than keyboard. Go's excellent tooling, suitable for automated and fast workflows will not be utilized here.
I use Intellij IDEA all the time for Java and I also learned a few keyboard shortcuts along the way. So no need to think for me.
I still think Go is far more keyboard/CLI oriented as compared to Java. From their description it looks like they are shoving some Go stuff on to a Java IDE. It is still good for people craving a Go IDE in Java mold.
I'm very disappointed in that decision. It should use the native `go fmt` tool. On some code bases, we use CI to ensure that `go fmt` was ran on checked in code. If there is even a slight difference between IntelliJ's implementation and `go fmt` then it will cause CI to fail.
There are technical reasons for not doing that. Most important one being that it can do formatting on the fly and not have your cursor jump around when formatting. So your experience will actually be a whole lot better than any other editor.
And if they say that it's going to be on par with gofmt it will be on par with gofmt. Do consider that they might actually know what they are doing.
Jetbrains has yet to let me down - They got me covered for Java, C++, PHP and JS/TS and now they have a golang IDE - I will definitely be learning go with a lot more enthusiasm.
If you are using VS Code for TS, and you think that's awesome...give Webstorm a try. It's a whole another level.
While it's a paid IDE and that might not go well with a lot of people...it's one of the best software I've paid for (and something I use daily).