Jetbrains products are awesome though. I used to use a heavily customized vim which was a pretty good setup, but the things a jetbrains ide can do are just much better than what my custom setup could do. I pay for a personal subscription and couldn't be happier. I will recommend everyone to atleast give their products a try. They have a free trial period.
> a jetbrains ide can do are just much better than what my custom setup could do
I get frustrated by people who insist on a complex vi/emacs setup for something Jetbrains IDEs do better out of the box. Or people who insist Sublime is good for editing their complex React project.
I mainly use vim and occasionally use Jetbrains. My setup in vim is super complex. I can tell you exactly how I feel about it:
Vim is a better text editor than anything else. By far. Unfortunately, vim is terrible at basically everything else.
The problem is, once you learn to use vim's text editing capabilities, then editing code using anything else feels like a pain. I'm not talking about variable lookups / etc. I'm talking the pure "move the cursor to a certain place and enter some text" aspect of it. If you don't know vim, then it's hard to understand how slow editing text feels without it - it's kind of like going from not knowing how to type properly to being a solid touch typer. (not that extreme, but that's what it feels like).
Unfortunately, because vim sucks at everything else, my setup has to be complex to actually get it to do the other things a good IDE does out of the box. If I could do it the other way around, I would - I'd love to be able to use vim-like editing inside of an IDE, but every vim-mode I've tried so far just doesn't work properly (except one - evil mode in Emacs - which is why I recently switched to Spacemacs, but that's another story).
> "move the cursor to a certain place and enter some text"
In vscode, I'm usually already looking at the call site of a function I want to edit. So I move the cursor into the function call and hit F12 which takes me to the function definition to edit it. Once I'm done, I hit Alt+LEFT to navigate back to where I was to continue on...
If I didn't start from a call site but I know the file I want to edit - I hit Ctrl+P, type the name of a file, hit ENTER - now I'm in the file, ready to edit it.
To jump to a function, I collapse all functions (Ctrl+K,Ctrl+0/1/2/3/4) and then scroll (or PAGE UP/DN) to find it...then use arrow keys or Ctrl+G to enter the line number. Now I'm ready to edit the function. I might have to hit Ctrl+Shift+] to expand the body of the function.
Alternatively, I Ctrl+F and type the name of the function I want to edit, pressing ENTER to find it...and I'm ready to edit the function.
You're talking about how it's easy to move to a function or a file, and then you're "ready to edit", but edanm is talking about actually doing the editing.
For example: say I jump to this function and want to fix a bug (the `search` should strip off the first two characters here, not just one). So I need to change `regex.search(s[1:], ...)` to `regex.search(s[2:], ...)`:
def compile_hg_glob(line):
pat = glob_to_re(line)
# Mercurial ignore globs are quasi-rooted at directory boundaries or the
# beginning of the pattern.
pat = '(^|/)' + pat
# Mercurial globs also have to match to the end of the pattern.
pat = pat + '$'
try:
regex = re.compile(pat)
return lambda s: regex.search(s[1:] if s.startswith('./') else s)
except:
warn("could not parse hgignore pattern '%s'" % line)
return lambda s: True
If I've just used a fancy shortcut key to jump to this function, my cursor is probably on the function name. In Vim, I'd do `cinr2:<esc>`. Seven keystrokes. I could also do `/[<cr><ctrl-a>` which is only four keystrokes, but a little more awkward to reach. If I tried to do this editing with arrow keys and backspaces I'd need 12 down keystrokes just to get to the right line.
Or suppose I'm looking at this and want to add a `,` character to the end of each of the type entries, because I forgot Python likes its commas:
In Vim I'd press `j` to get to the first entry, then `A,<esc>` to append the `,` after the first one, then `j.` to move down and repeat the action. I then press `j.` a bunch more times (which is really easy to do rapidly with your index and ring finger on Qwerty) and in 2 seconds I'm done. Vim's `.` to repeat the last action is really powerful and can save you a ton of time for small ad-hoc edit repetitions that don't warrant doing a full macro with `q`.
These kinds of things happen constantly, and when you've got Vim burned into your fingers trying to edit text without it (actually edit text, not just jumping to something) feels like typing with oven mitts on.
Or just use the mouse to point and click in the same time. With laptop mousepads it's just moving a finger. Most devs aren't writing that much code and all these Vim efficiencies are vastly overstated.
I've seen many Vim/Emacs-only devs being easily beaten in speed by others using modern IDEs that have tooling and functionality (auto formatting, refactoring, templating, etc) focused on actually getting things done.
Exactly this. I pick type, and I've never found that it feels too slow. I spend more time thinking about the change I want to make, and reading the code to plan that, than actually making the change most of the time. My typing speed wouldn't address the bottleneck. I think vim is the same. Sure you can edit the text faster, but that's not the bottleneck anyway.
Vim was never about typing efficiency. However, it is indeed the best way to navigate and edit text. This statement is very subjective because, just like any tool, it depends on the user. Chainsaw looks ugly, heavy, cumbersome and dangerous to someone who doesn't know how to use it. But with some practice it becomes an incredibly efficient tool. People make ice sculptures using chainsaws.
And I'm not talking about Vim the editor. I'm talking about Vim as an idea. Which is today implemented for pretty much every single [popular] editor and IDE in use. That fact alone is pretty illustrative of awesomeness of the idea of Vim.
And the comment about Emacs is quite disingenuous. I have never been inside a Formula One cockpit, but I can totally get "the job done" with my Camry, because it is totally more efficient for parallel parking.
I have used many IDEs, including InteliJ (which I used for about seven years). Emacs wins solely by its extensibility, no editor/IDE has ever matched its capabilities. For some people that is not an important factor, just like the efficient parallel parking might not be important for Formula One pilots. But when you can automate pretty much anything it feels very empowering and liberating.
Small example: when I'm about the create a new commit, an emacs-lisp script can figure out the current ticket I'm working on (based on currently clocked Org-mode task), generate a branch name based on the ticket description, generate part of the commit message (in the way that it is in compliance with git tool like gommit), I would just have to type the rest of the message.
That is not only more efficient, but also reduces frustration. Compare that with the workflow in any other editor and IDE - most of these steps will have to be manual. Then someone might say: oh there's actually a plugin for Editor X that does some of that stuff for Jira. But what if I join a different company that uses Pivotal Tracker instead? I can extend my emacs-lisp script. Whereas if that's an InteliJ plugin I would either have to go through daunting process of forking and modifying the plugin or submit a feature request and wait for something that may never happen.
I think where the IDE’s are really powerful is when refactoring. Need that one class renamed? File is automatically renamed too, and all references in every file that link to it (instantiations, calls, imports) are updated too.
Exactly, the code structure, navigation and intellisense features are far more useful and let you code at the same level of abstraction as the logic you're coding.
Moving a little bit faster through the text file to edit characters is rarely the issue and I certainly wouldn't give up IDE features for it.
2: select the first :, ctrl+d until all are selected, right arrow, comma
Doesn’t sound any more efficient? Plus, who writes code without an auto-formatter these days? Problem two would have been solved by the linter the moment you wrote that.
It's not just code and linting though - this kind of thing happens when you're editing YAML files, when you're editing pure text, when you're editing CSVs, when you're editing some obscure thing no one's heard of - once you have the primitives down, it's just so easy to apply it everywhere.
This is a bit frowned upon in HN, but may I just say I'm a fan. I'm not sure, but it's likely I got my way of speaking of vim as a language from you, and as you can see in my other comments, it's stuck with me :)
> In Vim I'd press `j` to get to the first entry, then `A,<esc>` to append the `,` after the first one, then `j.` to move down and repeat the action. I then press `j.` a bunch more times (which is really easy to do rapidly with your index and ring finger on Qwerty) and in 2 seconds I'm done. Vim's `.` to repeat the last action is really powerful and can save you a ton of time for small ad-hoc edit repetitions that don't warrant doing a full macro with `q`.
Eh. I'd probably do 'qqA,<esc>j0q', and then '8@q'.
That's also probably not the best example, since that's also trivial if you have an editor supporting multiple cursors.
That's hardcore, I would rarely use a macro for something like that :)
That said, I think multiple cursors are the greatest addition to text editing since, well, vim. I was an enthusiastic user of Sublime Text 1, right before I learned about vim.
Luckily, vim has multiple cursor support, which is... decent. Not great, but decent. I actually think that the only thing that makes multiple cursors more awesome, is being able to combine them with vim's commands, since multiple cursors rely on you being able to do precise things at each cursor, and vim gives you the language for it.
> That's also probably not the best example, since that's also trivial if you have an editor supporting multiple cursors.
Yeah, it's hard to come up with a decent example because I don't even think about it any more, it's just burned into my fingers. I just know how excruciating it feels to edit without Vim (I even wrote that last comment in Vim and then copied it into the browser because writing it in a text field is miserable).
I long ago created a special script (in Macos it's via something called Hammerspoon, I used to have a Windows version).
It basically gives vim-like keys anywhere you want, when holding down the caps lock key. So e.g. caps+h/j/k/l are movement keys.
It goes a lot farther than that: I have a key to delete a line, a key to select a word, a key to go up/down by 4 lines, a key to delete the last word, etc. I even mapped caps+f to jump forward 20 characters (to badly simulate using 'f [letter]' in vim).
This makes so it I never have to leave home position on the keyboard, because while holding caps I have all the movement keys I want at my disposal. It's a total lifesaver, and the only way I can effectively use a keyboard outside of vim :)
>So I move the cursor...What do you do in vim that is far easier?
The part about moving the cursor. Vim users typically don't move the cursor with the mouse but rather with the keyboard. Having to move your hands off the keyboard to reach for the mouse then back is the part that starts to feel sluggish if you get used to not doing it.
Quite the opposite actually, by the time your hand even finds the mouse the vim user will already have jumped to the desired code block and have started editing it.
Having worked alongside longtime vim users, that's almost never the case. There's often more time spent on finding out/remembering the efficient way to get to a particular piece of code. And then there are the inevitable mistakes (oh, I counted give spaces/quotes/paragraphs, but there was one more/one less; oh, I failed to account for some minor thing in my macro etc.).
In a modern IDE you have a multitude of shortcuts and a mouse, and they complement each other.
> Having worked alongside longtime vim users, that's almost never the case. There's often more time spent on finding out/remembering the efficient way to get to a particular piece of code.
Longtime vim users who didn't know how to use vim? That's... interesting.
Reading the parent comment (and being somewhat a vim user) - "move the cursor to a certain place and enter some text" - sounds mostly about the first thing you mentioned - "move the cursor".
Stock vim is mouseless, and without arrow-keys, which means relying on /? (searching) or other keys to achieve the function of arriving at text. CTRL-F never quite matches that (after you hit enter, the CTRL-F dialog is still open, and needs to be closed with ESC or by clicking away), and moving to the arrow keys/pgup/pgdown/mouse is slow.
Having said that - there are some plugins that match this behaviour - I particularly like the ones where a key (f in vimium) highlights each word with a character, allowing for one or two keypresses to jump anywhere on the screen.
I do all of the same in emacs (and vim), and because I use doom-emacs I get all this basically for free without much configuration on my end.
- Go-to-definition is `g d` (with the cursor over the function name in question)
- Project-wide file search is `SPC SPC`
- Jumping to a function is `SPC s i` and then just start typing to fuzzy-match the function name
I stick with this setup because it does pretty much everything I could want from IDEA, and does it without churning up most of the resources on my machine. And trust me, I've tried to switch to IDEA, but it's just too big and too slow, and too poor of an editor for me to actually make the switch.
Even something simple like reading code line by line (and of like me you like to move the cursor as you read the line), and your cursor reached the bottom of the screen, and you want reset the viewport where the line the cursor is on is at the middle of the viewport, is one keystroke ‘M’
The one related function that I would miss is using vimgrep and the QuickFix list to get a list of the locations where the function name appears which I can use e.g. to do a search and replace in those files (or a subset of them)
It's not so much the moving between the files - which vim is terrible at (one of the many things I had to extend in vim in order to get it to work like an IDE). But it's moving and editing within the file itself.
E.g., say you somehow got to a file, and it now has a bunch of functions in it, and you're literally looking at the line you want to edit. To get to that line, there's a bunch of different ways, but you can do this in like 3 key presses. Then, within the line, you can change anything in it really easily.
This sounds weird, so I'll try to give an example. Let's assume you have something like:
Func(self._something, self.something_else).validate, 'Validate exam foundation table')
And let's say you want to change the string that says 'Validate [...]' to say 'Change is good!!'.
To do that, once you've gotten to the line, I'd probably hit two key presses that mean "go to the first open quote in the line", then I'd hit the keys that mean "delete everything inside of the quote character", then I'd type what I want. All in all, I'd be typing these characters before actually writing what I want to write: f'ci' (so, 5 characters).
That probably looks either idiotic or daunting - but the idea of vim is that it's a language - you are literally thinking in your head "go to that quotation mark", then tell vim to do that and it does. Then you're thinking "delete everything inside of these quotations", and it does it. The distance between thinking what you want to do and doing it is almost zero - it's as close as you can get to literally telling someone exactly what to do.
If you're using a non-vim editor, you'd probably have your cursos in the begining of the line, and have to do "cmd+right" several times to skip over words in order to get to the first word of the string, then have to "shift+cmd+right" to get to the end of the string, then write what you want.
There might also be some small annoyances - the last shift+cmd+right might take you over the last quotation mark, and you'd end up selecting the closing paren as well. In vim - that doesn't happen, you're saying exactly what you want to have happen.
Or you might want to undo this change - in vim, it's always hitting "u" once, because in vim, changing the string to something else is an atomic motion. In another editor, you might have to undo a few words at a time, or maybe not - it's not always predictable. And since it's atomic in vim, it's also easy to re-apply the same action to another string - so changing another string to the same thing is a simple matter of hitting "." on it.
And of course, this is just a tiny example. It's easy to dismiss as trivial or unimportant - these are tiny savings of time, after all, and even if you add it up, I doubt the "time saved" in doing things more efficiently is worth much.
But once you know this language for telling an editor exactly what to do, then using an editor that doesn't speak that language just feels super slow - it feels like you are not able to communicate properly, and suddenly, what used to be zero gap between thinking and doing, takes a long time.
> If you're using a non-vim editor, you'd probably
Double-click the word to select it, and start typing right away.
> it's as close as you can get to literally telling someone exactly what to do.
I usually tell someone "Change the word 'validate' to 'something else'". SO i grab my mouse/trackpad, and get there in one click (or double-click).
> It's easy to dismiss as trivial or unimportant - these are tiny savings of time, after all
You should observe most of these "savings" in real life. There's rarely a time when I can't do stuff with code faster than a Vim user. Because by the time the vim user has typed the required sequence of letter, or counted which line/symbol/mark to go to, or wrote a macro correctly, I'll have finished all I needed to do using IDEs built-in capabilities and/or a mouse.
I wanted to say exactly that. I've never been a big fan of vim plugins in IDE's, even though I still prefer them over no vim bindings. The VS code or Eclipse vim bindings are 'not great' at best, for example. But CLion + vim plugin is actually very good: it uses my .vimrc, doesn't mess up undo/redo, supports things like block select in visual mode, etc. The only downside is that it interferes with some standard CLion keybindings (which is inevitable I guess), so you have to remap some things.
Out of curiosity is the plugin just called vim or what? I've been craving getting back to using vim style controls to edit text (and use CLion when working with Rust) so would be interested in at experimenting with this.
It also has two popular vim packages, surround and easymotion you can use too, which I really like.
I then customize all the IDE stuff to vim combos.... super nice.
only PITA is in some drop downs on a number of jetbrains products is that it doesn't play nice with auto hotkey, I have ALT-J and ALT-K bound to up and down arrow keys which makes for a much nicer vim experience when dealing with autocomplete drop downs ( or any drop down )
Was going to chime in to say the same, the VIM plugin in Intellij is hands-down the best vim emulation I've seen. It takes your vimrc as `.ideavimrc` and fucking works.
Been paying for Intellij for nearly a year now and I don't regret a day of it. Well okay, I do regret the one day EAP was totally broken by the VIM plugin, by besides that it has been brilliant.
Of course. I don't even know if I'm actually more productive in editing text.
I just know that subjectively, going from speaking a language with powerful concepts, to using the super crude tools available in most editors, just feels sluggish.
I highly doubt it was actually a good investment time wise to master vim, but I salary really enjoy messing with editors so it was partially for fun.
I always wonder how good and productive people who claim this are in reality. Personally I consider typing as a strong bottleneck for my productivity. I type all the day, and the less time I waste on transfering my thoughts into commands, the more time I have for focusing on the important parts. Not all typing is for textediting, but editors like vim&emacs are not limited to textediting.
The vim emulation for the IntelliJ tools worked very well for me. Used to use only vim with a complex setup. Have been using Goland, and IntelliJ for about a year now.
I actually haven't tried it (just started using PyCharm again very recently). But I gave it a go right after posting my comment.
And like almost every other emulation I've ever tried, within 1 minute, I found 5 things that didn't work correctly. And I'm not exaggerating here - I literally spent 1, maybe 2 minutes and found 5 things.
I'll have to use it for a while to find out whether it's just a few minor annoyances, or much worse than vim.
Can you briefly enumerate some of them here? I'm a casual vimmer and have plateau'd on the basic vim features that are good enough, so I'm curious what advanced commands are useful day-to-day.
Nothing really advanced, I think, although maybe one or two obscure things. Here's the problems I found and remember (I wasn't looking for anything, I was just trying some basic stuff). They all might seem trivial, but we're talking muscle memory heI'M.
1. First thing I did was to fold all the functions in the file - this is something vim does pretty badly, actually, because it doesn't know how to deal with Python syntax without lots of customization. But anyway, the command for "fold everything that can be folded, recursively" is zM. Then the command to open everything back up is zR...
Except that for some reason, this vim emulation doesn't open everything, it kept the imports at the top of the file closed.
Verdict: Probably not a big deal, just inconsistent (but maybe PyCharm's way is better?)
2. I then did a standard thing I like to do - if you want to delete a paragraph, you hit 'dip'. Works well. If you have a few lines of whitespace between paragrpahs, and you want to delete everything except one line, the command in vim is 'dvip'. This is actually somewhat obscure but I use this constantly to clean up code. Didn't work.
Verdict: obscure command that's rarely copied correctly, but I use it all the time. Annoying.
3. I then tried to change some text. Let's simplify and say that I did 'ci(' to change the contents of parenthesis. Worked well. However, I tried to undo the change. In vim, this is a single 'u' since the change command is atomic. However here, this required hitting 'u' three times.
Verdict: Ok this is really annoying. It's unpredictable and screws up my muscle memory, plus it's a very very used feature.
4. This might just be my fault - I tried to navigate my Python file using ']]' and '[['. The second one took me to the end of the file, the first did nothing - neither did what I want, which is to jump through various methods/functions. I also tried ']m' and ']d'. This one is not stock vim though (or not exactly), so it might be possible and I just don't know it.
--
I don't remember the other thing.
And btw, I totally don't mean to diss PyCharm, which is awesome in many ways. And I could be only nitpicking here - though again, finding 4/5 problems in 1 minute is not a good sign. But that's my point - emulating vim is, for whatever reason, either really hard, or not something that people spend a lot of effort on. That's why I have to rely on vim itself (or actually Spacemacs nowadays, which amazingly does have an almost completely working vim emulation.)
Agreed that it’s not perfect emulation. I took some time to find alternatives to everything it lacked for me and now I’m satisfied.
The biggest plus is when working with larger projects. The single-threaded autocomplete and jump-to-definition functionality was very slow in Vim, stalling the UI updates. Goland feels so much smoother in these cases.
Response Speed. Most emulations tend to fall behind my actual Vim command speeds, which really destroys the vim editing flow.
Occasionally emulators will not honor mode switches correctly or on the first try. So I would expect to be in insert mode after a complex set of commands but the emulator isn’t there. This is also likely due to speed issues, but maybe not.
Emulators do not do a good job of handling macros, and vim’s repeatability. The auto stuff they try to do (such as formatting, etc) precisely the reasons one would prefer an emulator, can mess up repeatability.
Many of them don’t handle certain basic commands. A lot of emulators, for example, do not handle commands like HML which shift the viewport, possibly because the IDEs do not really give them access to it, or maybe because they aren’t known well enough that they fall way down the priority list.
Everyone does, that's totally legit. However, even without editing anything, just "moving around the file" is much snappier with vim. Even when I'm reading code I'll move to certain parts of a line to better understand what's going on. Plus, you do eventually have to edit code.
If you really never did anything except read code, then I think vim wouldn't give much of an advantage. Then again, neither would any of the shortcuts that every IDE provides.
I use both emacs and Intellij, depending on the circumstances. There are some things for text editing that are just faster in emacs. For example,
- I can be somewhere, jump around to a bunch of files, copy something, and then jump back to whereever I was last actually editing quickly (the "jump back to last edit" is 2 strokes).
- I wrote a custom mode, with tabification and fontification for the query language used by the cms I work with. I expect I could do that in IntelliJ but it would take a lot more effort.
- Things like kill-rectangle and the like; some of which may have parallels in IntelliJ, but I don't know then... and decades of experience in emacs means I do know them (or how to find them) there.
I really like IntelliJ, but I also really like emacs. Which to use depends on what I'm doing.
I also really like _make_ and wrap my other commands (mvn, gradle, etc) in Makefiles. I get jokingly mocked a lot at work :)
So nobody can give the opposing view point? I use both IDEs and Text Editors depending on the language. I use jetbrains for kotlin/java, and moved from vim to vscode for javascript and any other scripting language (also switched from VS to VSCode for .net)
I find developers who try to force their tools on others annoying. I'm much more productive on scripting languages with an editor. They just feel more responsive.
Of course you can disagree with that! I have written great amounts of all sorts of projects in text editors instead of an IDE. And yes, text editors come in different flavours. VS Code/Sublime Text isn’t the same as Notepad. That being said, the person I replied didn’t make a case of VS Code in any way. The OP asked what to use instead of a text editor like Sublime Text, and the reply was simply “Just use VS Code”. That’s not an argument in any way, that’s just a statement.
I have the reverse opinion. I find jetbrain users are so eager to extract the dollar value from their IDE that they try to shoe-horn the use of every available feature into their workflow just because they exist, whereas with vim, the features I use are a laser focused toolset I have accumulated over the years based on the need to solve specific problems. Vim accommodates my desired workflow while many jetbrains users attempt to shift their workflow into webtstorm's feature-set.
That or "VSCode". It does not compare to a proper IDE. And so far my attempts at meaningful discussion regarding it not being the right tool for anything except TS just ends up in "voodoo" arguments about how it can "debug anything", etc.
I'm also a big of of their products, and pay for a persnal subscription for Rider, ReSharper, DotMemory, DotTrace and DotCover. Rider is absolutely stuffed with features, and is way more stable and performant than Visual Studio.
I also like the way your renewal gets cheaper every year, as a kind of loyalty bonus.
I honestly had no idea they were making so much revenue - very pleased to see it though!
Oh, and a special mention is deserved for Rider's git merge UI, which is by far the best I've used.
It's based on 3 window panes: you get your code on the left, theirs on the right, and the result in the middle, along with tools for accepting changes from either side, and you can edit the result pane at will too.
I've never liked the git merge UIs in VS or VS code (or other IDEs I've tried over the years) - Rider's is perfect for me.
The thing is JetBrain's IDEs use that diff tool where-ever a diff is needed, not just for git. For example, in a local history of a file (like undo history), history of a single line in code, etc.
That's just it for me. The tools have so many good features, remain stable, and keep all those features out of my way until I need them. Like Adam Savage's first order accessibility principle for his workshops, the tool I need from their IDEs is always often in arms reach, yet still out of the way.
I also enjoy DotPeek a lot more than the other .NET decompilers out there. I bought Rider, hoping the Visual Studio emulations would satisfy me (I use Visual Studio at work, but run linux at home) but sadly I have been unable to get it to work.
I thought the same when I first saw "stock" Rider - it's a very different look and feel from Visual Studio, more what you'd be used to as a Java dev with IntelliJ, or an Android dev with Android Studio. I personally found th look a bit... dated.
A while back JetBrains made Rider more themable (prior to that update, you could only really theme the editor, not the file explorer etc). After that update, it looks great with a dark theme enabled!
I'm on mobile now, but if I remember later I'll mention the name of the theme I'm using - it's pretty close to VS's dark theme.
That's one of the out-of-the-box themes, but I just checked and the theme I use is called "Visual Studio Code Dark Plus", and I use the colour scheme with the same name. You can find it as a plugin here:
https://plugins.jetbrains.com/plugin/12255-visual-studio-cod...
I always found the Edit and Continue function in Visual Studio to be flakey: often it would say it wasn't "allowed" with the type of project I was using, or it took minutes to apply changes when it did work, or it crashed while applying changes... Rider got Edit and Continue 1-2 years ago (I think), and it's been completely reliable in that time!
This is actually what triggered me to get the personal site license when it first came out a number of years ago.
JetBrains announces that IntelliJ is going Open Source.
I checkout the code, build it (~20ish minutes) inside of the downloaded bits, launch the newly compiled IDE, build the repo source again this time debugging IntelliJ from within itself. All in less than an hour, with no hiccups. Amazing.
I can't figure out how to download the IntelliJ EAP. Everything seems to direct to the standard Commercial/Community IntelliJ download page. Anybody have a link?
OTOH that means you have to upgrade quite frequently (EAP stop working) and the editor is completely broken from time to time.
Also if you take part in a prerelease EAP (before the product is 1.0) (and your feedback is constructive and valuable enough) Jetbrains might gift you a license. That's how I got my first year of PyCharm (well my first year after the EAP ended anyway).
I use Jetbrains products for everything at work. I don't know what's going to happen if I ever have to work at an Eclipse shop. Might have to turn it down, honestly.
I've been the sole Eclipse developer in a number of places where everyone used IntelliJ. At least a couple of the places had switched from Eclipse after having been worn down by that one incessant IntelliJ guy. A few developers discreetly confided that they would rather have stayed on Eclipse, and some new people followed my lead. None of the places were 'IntelliJ shops' though, any more than I know of any 'Eclipse shops'. It would be rather poor form to hard tie your projects to an IDE, so it was always fairly doable to run with your IDE of choice.
There are Eclipse shops? In 2019? Why? I mean, even IntelliJ Community (which, despite the implications of the name, can be used for everything) is a fair bit better.
Speed in large projects. IntelliJ is super slow once you have huge source/text files. E.g. WebStorm is unusable for debugging as one step over takes ~10s on a 128GB RAM machine in such cases.
I am mentioning this in the off chance you did not tried it, exclude the node_modules/vendors/build folders or other third party code that is not part of your project you are editing.
I am not experiencing this issue and I have a large project PHP and JS plus the plugins for jquery and angular , all linting on. After the project loads I don't feel any lag, I run an i5 6th gen CPU , 4cores. I might have tweaked some VM options years back (my configs and styles are at least 5-6 years old so I do not remember).
Also if you transpile all your js into a big minified file, exclude that too, right click on it and there must be an option as mark as plain text.
The last place I was at was an IntelliJ shop, but I don't think there was anything in the project layout or committed files that was specific to IntelliJ, so if they're good about not committing project files, it should be the same for Eclipse. You'd just be on your own, though.
I used PHPStorm for quite some time and was hyped that Android Studio would switch from Eclipse to a JetBrains solution, back in the days. I still don't understand how it could turn out as shitty as it is right now.
I came to say this. That $270M revenue is backed by a #1 product line. I first tried PHPStorm back in 2014 after I got tired of the wonky debugging capability in Eclipse. I still think Eclipse is a really important project in the way that JetBrains is the Google of IDEs and Eclipse is maybe the Firefox, and we need Firefoxes.
I remember there was a time when IBM really invested in it that it was miles better than anything in the Java editing space, or honestly any competitor at the time. For example, instantaneous compiling and error checking was so far ahead it took MS many years to catch up with it.
It used to be a matter of huge excitement when a new language or framework was supported by Eclipse.
But I moved away from Eclipse for a few years (I wasn’t programming then) and I’m back and suddenly it’s absolute terrible. Not just worse than browsers of the time, but possibly worse than what it was when I last used it.
Not sure what you're experiencing but I use Eclipse daily and I can't see anything remotely like what you're describing. It's clunky and sometimes slow (esp. if you run it with default memory - ALWAYS increase the memory). But it works just fine for me.
IBM getting involved in something is usually a death sentence. Initially they might inspire hope. But they'll turn everything into a horrible mess lacking those polishing touches that makes stuff nice to work with. They'll tick feature check-boxes. But the stuff will barely be usable.
You may like them more for a variety of reasons but how is photoshop less free/open than Jetbrains products. Both are commericial products that require a licease and both are on the subscription model after selling unlimited liceases for years.
Mozilla has made a commitment to privacy into its products' main differentiator, and I am 100% okay with that. The fact that FF ships with its Facebook container system turned on by default, and that it just works, is probably my favorite browser feature in quite some time.
I recently went ahead and purchased theyr3 full product line, because I figured there are several I would end up wanting to use and it was just cheaper that way. The reason I bought it though, was specifically for CLion. I figured having a full featured IDE would make it much easier to browse and understand large C or C++ projects, but sadly it seems to only support CMake projects.
This minimal cmake file should setup the ide for any project, the build will have to be ran externally though. You can setup the ide to debug external binaries as well, as long as it has source information (was built from the current project sources with debug info).
I purchased the whole product line as I think Jetbrain's product is excellent, the only complain from me is this CLion Cmake requirement, could be more versatile, and supports non-Cmake projects(or even single files without makefiles), even Geany does better than CLion as far as c/c++ is concerned. Please make CLion better for C/C++
I have used CLion, and would say JetBrains did an excellent job with making a C IDE. The issue is that C is not much of an "IDE language"; my experience has always been to just use a text editor (vim or vscode), and it seems to be the same for most C devs I know. Looking at newer languages, they seem to pair closely with IDEs; I'm still not a big IDE guy, but most use them for python, java, etc. I'm not enough of an expert to quantify the reasons behind this, but I think it's hard to build a stand-out good IDE for a language with which IDEs often aren't used or are just used as glorified text editors.
> The issue is that C is not much of an "IDE language"
This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling.
Compare to Java (set the classpath to exactly the artifacts you want and IntelliJ uses its own build system unless you explicitly tell it otherwise), Python (set up a virtualenv with exactly what you want and PyCharm handles its own builds, insofar as Python builds).
In C on Windows and Unix you have to figure out how to find and address includes and libraries in a cross platform way. CMake is probably the best bet. If they were in the position of, say, TurboC back in DOS days where they provided stdlib and you added everything else you wanted, they could do as good a job as for Java.
> This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling.
Exactly. #include "header.h". But where is it? Depends on compiler flags. Java has the same problem, but luckily has only ~2 build systems that are well-supported by IDEs.
Java doesn't really have the same problem. It has the classpath, and that's it, across all platforms. Nor do the big IDEs use ant, maven, or gradle as their internal build system, though most of them support controlling them.
Yeah, there was some improvement. But the issue for me is building a C++ app which requires Linux headers, Boost headers, and Wt, CLion seems to wants to take four cpu's for a hot trip. Even with a bunch of the code helpers turned off.
VSCode with CMake, clangd, and C++ code filter seems to work for the little I've used it so far.
Havn't quite taken the leap of faith in VIM, clangd to see if that is suitable.
One thing I've found with CLion is that you really, really want to edit the JVM settings for the IDE. By default it starts with a 2GB memory limit for the JVM, which even for small projects will severely drag down performance, e.g. my MBP would run very hot, spin the fans and the IDE would get very laggy. Increasing the JVM settings to allocate 8GB completely solved this.
It's not the editor part that uses all this RAM I suppose, but the code parser and indexer that by default includes scanning & interpreting all your dependencies (system headers, boost, other third-party frameworks). There is a clang process that has the full AST for all of your code + its dependencies in the background all the time, so you can get search, index, autocomplete, syntax check, refactor etc. that actually works compared to the half-baked solutions you get with VIM plugins (and I've tried all of them).
I guess you can switch all of that off of course, but that's what makes it an IDE and not an editor. I think the memory tradeoff is perfectly fine for this kind of application.
At the moment I am sitting here adding couple of things to a huge desktop application written in Delphi. More then a million lines for a full build (which takes 11 seconds on laptop btw). It does all that you mention with all bells and whistles of a modern IDE and consuming whopping 380MB. How's that for a change?
Apples and oranges, Delphi != C++, and on top of that I don't think you really want to make the argument that the Delphi IDE can do all the things CLion can do for C++. I fondly remember my time writing Delphi, but I'm not jaded enough about the resource requirements of modern IDE's to pretend that you can compare these environments equally.
Anyway, I don't really see the point you trying to argue here. It appears you are principally opposed to software that uses more resources than what you consider necessary, which is fine and in the case of something like CLion or VS code justified to some extent, because they are far from lightweight. But if you remove these ideological objections from the discussion, none of this actually matters all that much considering typical workstation hardware. I honestly don't mind trading 4 or 8 of the 16 GB of RAM in my laptop for all the features I get from CLion compared to the alternatives. A full compile and run of the thing I'm building can easily get by with (much) less than 2 GB. And if I would be developing something that uses up 8+ GB by itself, I probably want a beefier workstation with 32 GB or more anyway. It's just not an issue, RAM is plentiful, and it's in there to be used.
All my laptops have 32GB of RAM. And if I had no other options I probably could've been stuck with CLion. However as I've already mention CodeLite and QtCreator are multiplatform, very responsive, work just fine as an IDE and eat very little memory comparatively to CLion. I often have to test big in memory datasets so I have way better ways of wasting RAM.
No it is not fine. The only impression I get from glorified notepads consuming gigabytes of RAM is the ever increasing desire to send them to /dev/null where they belong. My opinion of course
There is absolutely no excuse for any editing product to be perceptibly slow.
A single ordinary, commodity CPU core can sort 100M of totally random ints in 5 seconds. The amount of work any editor legitimately needs to do to provide you editing support is trivial, in comparison, by any measure.
