JetBrains: $270M revenue, 405K paying users, $0 raised (twitter.com)

Every single HN post about either Emacs, IntelliJ, Vim, VSCode, or Atom always gets riddled with disingenuous comments of people who liked one thing more than other things. Things they either haven't tried or had some cursory experience with them.

These tools are very individual [just like toothbrushes], for someone Emacs offers something that IntelliJ or VSCode can't, for others - nothing is better than Vim.

To truly achieve mastery, one has to try and learn them all and choose a tool that works well for the situation or the one they like (for objective and subjective reasons). Some might say: "that's a waste of time", try saying that to musicians. Go tell James Hetfield of Metallica that he shouldn't be trying all sorts of different guitars because Gibson is hands-down the best.

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.

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.

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 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.

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.

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.

Its not perfect but its good enough for moving around and copy/paste.

I occationally go back to emacs to macro some data into different formats.

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.

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.

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.

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

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:

    result = result | {
        'a': TYPES_ALL
        'e': TYPES_FILE_REAL
        'x': TYPES_FILE_SYMLINK
        'c': TYPES_DIR_REAL
        'y': TYPES_DIR_SYMLINK
        'f': TYPES_FILE
        'd': TYPES_DIR
        'r': TYPES_REAL
        's': TYPES_SYMLINK
    }[c.lower()]

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.

- 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.

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)

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 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.

Unfortunately, the last time I used IntelliiJ it came with its own JDK8. Is that still the case, I wonder?

I thrive when learning new skills and being "uncomfortable" and out of my element.

It's probably because I'm picking at rust for fun in my personal time that I don't want to deal with the uncomfortable parts. In my own time I coast and comfortably stroll through new problem spaces rather than get to that "my brain hurts" part that's all too familiar.

If rust + intellij was a work requirement I probably would just pick it up and discover that my brain can handle perfectly, two sets of bindings the way people claim to be able to do qwerty and Dvorak interchangeably.

It’s like the difference between someone who can navigate the highway system with interstate signs & atlases alone vs someone who is unable to navigate at all without a GPS system.

Even if the GPS system experiences no downtime, they still lack skills that make the driving lower quality, like anticipating changes or adjusting for weather.

Coders heavily reliant on IDE tools simply understand the ramifications of what they are writing less well, because they haven’t invested in the mental map of the code and mistakenly believe they can safely offload many parts of that cognitive requirement to an IDE.

Worst of all, they believe that code shipped this way is somehow reinforcing evidence that the IDE was a value additive tool, which is the wrong counterfactual for comparison. You have to consider the value lost from what better solution could otherwise have been shipped for lower cost using a different set of tools.

Multiple "sources-roots", multiple-projects in the same workspace. Also, you can install pip install external libs in source development mode and debug them, etc. Short of "project imports" that I miss from Eclipse, I'm not sure what you may be referring to.

I used to use IntelliJ Ultimate, and had to wait a while before getting new features announced for PhpStorm, for example.

I now just use PhpStorm for PHP and GoLand for Go, instead of attempting to use IntelliJ for all languages. I spend less time configuring IntelliJ for each language and get updates on release day.

JetBrains has an "everything" licence that I was able to migrate to from IntelliJ Ultimate.

There are indeed plenty of features that are specific to each IDE/Language that aren't in the IDEA-equivalent plugins.

https://pavelfatin.com/typing-with-pleasure/

That said, before I pulled the trigger and purchased a Rider license, I tried running VS without ReSharper. While it certainly was definitely faster, more responsive and used less memory, I still didn't find it as snappy as Rider. It also still had my laptop fans whining, and occasionaly became completely unresponsive.

It's a real shame - Visual Studio is without doubt an excellent IDE, but performance and reliability issues have plagued it since forever. I really wish a serious effort would be made to address these.