Hacker News new | past | comments | ask | show | jobs | submit login
JetBrains: $270M revenue, 405K paying users, $0 raised (twitter.com)
1168 points by matt2000 35 days ago | hide | past | web | favorite | 662 comments



I'm a big fan of the way JetBrains sells their licenses. Like a lot of software companies nowadays, they only sell licenses on a subscription basis. But with a very customer-friendly clause of where if you pay for a subscription for 12 months you get a perpetual license for the latest version of the product when you initially subscribed. And then after paying for any particular version of a product for 12 months, you also get a perpetual license for that particular version and so on and so forth.

Their FAQ page explains it a lot better than I can: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...


True; that's the only subscription model I find acceptable for software that hardly changes in meaningful ways. For example, I refuse to upgrade Git Tower to version 3 as a protest against fournova's new licensing. Up to that point, I was a loyal customer and product advocate, basically buying every upgrade anyway, but by my own choice. Instead, I'll be on version 2 "forever", despite all its flaws. It was even worse for Windows users, who bought licenses (on my advice, sometimes...) for a thing that realistically speaking never came out of beta. To have a usable product to begin with, they suddenly needed to pay for a subscription. There was zero response to my email explaining this, so there's that. Now I'm keeping my eyes open for alternatives.


I also switched from Tower when they introduced subscription pricing.

My current git setup:

- Git Fork for committing, pushing

- P4 Merge for resolving conflicts (it's not a pretty app, but the fantastic feature set more than makes up for the non-native look)

- GitUp for reordering, editing and splitting commits

- Command line for the rare things the GUIs can't do

None of those cost money and I don't understand how these awesome apps are all free. I would pay for all of them, they are much better than Tower.


Emacs is free and in my opinion Magit is far, far superior to Tower / Fork / SourceTree (used them all on mac extensively at some point; out of those, fork is pretty nice and lightweight).

I'm not an emacs user but always install it (via spacemacs) everywhere solely to host Magit.


The terminal is the best and only git client you need and it will always be free. You are doing yourself a disservice as a developer by not learning how to use your terminal


I'm not sure about that in the case of git. I used the terminal UI exclusively for a long time but it's so bizarrely designed that I've been interested in using a GUI for a while. There are a lot of reasons a dev should learn to use a terminal but making git more pleasant to use isn't necessarily one of them.

GUIs aren't super flexible but they are good at taking a common flow users go through and making it stupid simple to exercise. A lot of the usage of git should be stupid simple, with only infrequent need for complex interaction. Obviously there are some people out there for which a GUI will never be sufficient for their needs, but I'd argue it isn't the common case.


I'm typically a heavy terminal user. Git is my exception. a) the UI of git cli is just so terrible that I'd rather fill my brain with more important things, and b) for viewing what's changed, `git diff` just doesn't cut it relative to a GUI.

Sourcetree is my go to git client, but if I couldn't use sourcetree I'd be OK with pretty much any git GUI. But git CLI is reserved for particularly tricky things that GUIs just can't handle well. (And I need to look up the specific flags or commands every single time.)


Cool ! Git fork looks quite like GitX (which is unfortunately not indevelopment anymore) !


I'm a big Fork advocat and use it on a daily basis, but I fear they will charge for a new version at some point in the future.

I think that because it seems they founded a company "Fork" which inevitable will need to make money eventually.

edit: I'm of course willing to pay some bucks for great software if it's a fair pricing model.


Just yesterday I noticed a "Fork Activation" option in the Fork menu with fields for an email and a license key. I think you might be right, it won't be free for much longer.


Yep, and the 'Buy Now' link leads to https://fork.dev/buy

Not subscription based!


Seems like a fair price to me. Will propably buy it if the time comes.

Somehow I hesitate to pay subscription based models, although I understand why this model exists.


I found P4 Merge to be totally inscrutable, could you elaborate on what makes it so good?


It's a 3 way merge tool that works well with Fork. To be honest I can't say how it compares with other merge tools, I tried a few merge tools some time back and liked P4 best.


I suggest using SourceGear DiffMerge for resolving conflicts. Best 3-way merge conflict handling tool I've tried:

https://sourcegear.com/diffmerge/


Another suggestion is Beyond Compare, the 3 way merge is a pro feature though:

https://www.scootersoftware.com/


Better than Meld?


I am just replying to say that I have the exact same experience. I love Git Tower and recommended it to many people, but I haven't upgraded to version 3 and likely never will - for the exact reasons that you have lined out. I think FourNova (the company behind it) is probably missing out on quite some cash here...


I'm in the same boat, and I would rather search and find an alternative when my version 2 no longer works, than to support them again.


Tower became unusably slow for me. I switched to GitKraken and have been very pleased.


Check out Sublime Merge, from the creators of Sublime Text: https://www.sublimemerge.com


I switched to Sublime Merge from using Git Tower (their licensing was awful after v3).

Never looking back, SM is amazing.

Git Tower folks: Stop pissing off your paying loyal users. Get a hint, I want my money back because you guys never made v2 properly stable and jumped on v3 for an awful cash grab. Fuck you, kindly.

Sublime HQ is an amazing company. I would pay for their products even if they charged double. Honesty and integrity matters. You’re not selling to normal sheep, programmers are a smart bunch.


There's also Fork: https://git-fork.com/


I'm really curious - why do people want a graphical git client? The command line exposes everything, and the model is simple and intuitive.

I work in a very large monorepo, so it's not like I'm working in a git tree that isn't complicated.


> the model is simple and intuitive

I nearly spat out my drink. Git is many things but those aren't the first two words that would leap into my head.


Git model is simple.

What is complex is the hundred features and commands it provides on top of that model.


> Git model is simple.

I strongly disagree.

Let's list just basic git concepts that you're likely to encounter fairly early on: the working tree, staged commits, branches, remotes, stashes, detached heads, tags, submodules, merge conflicts, squashed commits, fast-forwards, rebasing, cherry-picking.

Some of these you could choose to ignore - rebasing and submodules - but on the whole you need at least a cursory understanding of everything on that list to get by without a git angel to get you out of trouble. I still have a person I phone when anything out of the ordinary happens and I've taught git to other people!


You are confusing the model with the features built on top of that model.


Git is a great example of worse is better philosophy.


Thats exactly wHat GUIs are good for. Make infrequenlty used features and options accessible.


But GUIs for git usually do not provide access to all the features. They implement a very small subset that is just as easy to use from cmdline.

I'm also genuinely surprised that people use GUI for git. For merge I understand, but for all other tasks cmdline is easier and faster.


The model is relatively simple, but the UI is a disaster.

Which is exactly why people want better clients than the official git cli client.


I find that it has too many magic commands built-in so no-one really gets to learn the under-side of what's actually occuring so when it eventually breaks like everything does, you have no idea what you did wrong. An example would be how the git pull command is basically a bunch of different git fetch and merge commands.


Yes, but if it didn't exist people would say git's bad because everyone copies the same alias from StackOverflow, and it should just be built-in.


Say you want to find a commit that occurred around June three years ago, and look at what the repo looked like after that commit -- without checking out any files. How do you currently do it?

For me, I just Right click -> TortoiseGit -> Show Log -> scroll -> Right-click -> Browse Repository.

How long does it take you? For me it takes < 10 seconds (I just timed myself).


Not against GUI or anything but just curious about doing it from CLI: git log | grep 'June 2017' (and remember the first 5 characters of hash) And then `got checkout <hash>`


I think you missed the part that said "without checking out any files"?


Why would checking out files matter? What exactly do you think the GUI is doing underneath the hood?


Because it messes with your work tree. See here for a longer response: https://news.ycombinator.com/item?id=21800524


git log | grep -- find the hash of the one I want. or git log > file and look at it in an editor. no need to change the tools just for this unusual action.

I understand that YMMV -- de gustibus non disputandum est -- but I have ever understood the appeal of GUI tools especially for something like git. I do use magit, but even then I do most manipulation with the command line interface


> git log | grep -- find the hash of the one I want.

This misses the point of the problem -- the point is you don't know precisely what string to grep for.

> or git log > file and look at it in an editor. no need to change the tools just for this unusual action.

I mean, nobody said this 1 reason should be enough to make you switch tools? I was just giving an example.

And no, it's not "unusual" just because you say so to try to dismiss the problem. I know I use Browse Repository as well as the GUI logs pretty frequently, and they're godsends compared to your solution.

And lastly: this is what your solution actually looks like:

1. Dump the entire log output into a temporary file

2. Open that temp file in your editor

3. Look through the commit messages/dates/names

4. Realize that's not quite enough to narrow down your search to a single commit (maybe you want to see the diffs or file paths or something else?)

5. Try to figure out which flags you should to pass to git log to dump all the info you need

6. Call git log again, hopefully now it dumps all the info you need

7. Open the temp file again in your editor

8. Scroll through your file containing diffs/names/whatever extra info you dumped

9. Type 'git checkout COMMIT -- file/path' once you find something

10. (Hopefully,) before you press Enter, realize you're about to trash your current copy of the file, which had some other changes

11a. Run git stash, and now suddenly messing up your staging area that you'd carefully staged changes in, and also messing up the file metadata (e.g. Make will now rebuild everything...), OR

11b. Figure out how to run git checkout-index -a -f --prefix=/destination/path/ so that you check the file out into a different directory.

12. Once you have a copy of that file, look through it, maybe examine/pull out the code you wanted (or whatever)

13. Remove the temporary file you checked out.

14. Remove the temporary file in your editor.

15. git stash pop.

And somehow you always do all the above without making a mistake, otherwise have fun reverting or recovering lost data.

With a GUI log TortoiseGit's log, you literally:

1. Click on a commit with the date you're interested in

2. Select Browse Repository

3. Double-click each file you want to examine to see the diff

4. If it's not the file you want, press Escape and click again.

Not only is the number of steps smaller, each one is also significantly faster, and less risky too. No need to mess with a single temporary file, fire up your editor manually, or risk losing anything.

Anyway, again: this was just 1 example meant to get the idea across, hopefully with the aid of your imagination to extrapolate to other scenarios. But if you're going to trash this all with "this never comes up" I don't really have the energy or interest to keep bringing up examples or try to convince anyone; you should just keep using the CLI.


I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.

Perhaps you could be faster with the GUI than on the CLI, but learning a GUI doesn't come with zero overhead: you have to understand it's terminology, how it's configuration works, what its icons and symbols mean. Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it. Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).


> I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.

I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click, but regardless, this is easy enough to settle -- just time yourself and let me know how long the steps take you on the CLI.

> Perhaps you could be faster with the GUI than on the CLI

Hence the point!

> but learning a GUI doesn't come with zero overhead:

I don't think anybody claimed this either, so it's fine.

> you have to understand it's terminology, how it's configuration works, what its icons and symbols mean.

It sounds like you haven't used TortoiseGit... at all? How often have you had to look at its manual? How many times have you had to look at the manual of git itself? Honestly, your own reply is warranted here so many times more than it was to me -- "I don't think a lot of the steps are as painful as you make them about to be."

In fact so many of the commands are so obviously self-explanatory (both in text and in icons) that you literally never need to look them up. Stuff that you would never just guess how to do in git itself. Like when you right-click a file in a commit and click "Save revision to...", which also has a floppy next to it. Is it really such a mystery what it does? Is it even remotely comparable to figuring out checkout-index (or whatever the right command is)?

And honestly: it's such a poor attempt at an argument to suggest that the minor ramp-up time of TortoiseGit is somehow not worth the perpetual git pains it saves you from that I don't even know what to say.

> Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it.

First, this is such an unnecessary strawman. If you're so worried what some GUI command does, then just use the CLI for it instead.

Second, this is completely irrelevant for read-only operations (like log, Browse Repository, etc.) which were the ones concerned here.

And third... again, it sounds like you're only saying this because you haven't used TortoiseGit, because (shockingly enough, to someone coming from the git CLI) it's not a minefield; in fact it has a number of safeguards. "Commit" creates a commit, "Revert" reverts your changes, "Checkout" checks out a commit, etc... and in fact fails if your tree is dirty, so you don't lose data. Heck, sometimes the git commands it prints end up being more correct than what you'd type on the command line. I know I've learned a fair number of random git features from TortoiseGit.

> Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo

Again, nobody said you shouldn't learn the CLI. In fact, I'll say it right here: you should definitely learn the CLI, especially for git, before moving to the GUI, or you will be confused (though even then, you'd probably be less confused than you would be if you started with the CLI itself).

> (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).

No, it's most definitely not a reason not to learn it.The discussion was never about what you learn in the first place, but what you use. You should learn the command-line regardless. And even regarding usage, it's again a strawman: nobody even suggested you should never use the CLI. The question was "why do people want a graphical git client?" and the answer was "because it makes {tasks} easier", for some tasks. If you find any tasks that don't fall in that category, just use the CLI. It's just a tool after all, not a religion.


> I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click,

I know your reply was to debasarab2 and my upstream comment did say YMMV, but in fact it is a lot faster for me (and likely debasarab2) to type 10 characters than click an icon. My working mode is simply different. We’re not saying you’re wrong, what we’re saying is it’s not universal.

If I Haase to click a button I have to move a hand off the keyboard, shift my gaze, find the mouse pointer, move it, then BT my hand back to the keyboard.

Whereas on a command line I always know where my keystrokes go, I never have to move my hands or look away from the screen, and I have >40 years of typing at computers wired into my basal ganglia. (This is despite the fact that the first computer I used, a CADR lisp machine, had a mouse and bitmap display). GUI interfaces are simply much slower for me, except in very unusual applications. I am not claiming it to be universal but it is clear the affordances of the command line are significantly lower-friction for people accustomed to them.


My hands are on the keyboard most of the time too, I'm not a particularly slow typer, and there's no way I could write a proper git checkout-index command at the speed of just a click or two.

But again: I will believe you if you measure it and report back. So far the only person who's measured anything has been me, and I have to wonder why others are so averse to it.


Yeah, if you consider my arguments to be strawmen, then using a VCS GUI for the narrow use case of tracking down diffs might save you a solid few minutes. That just feels like a drop in the bucket compared to the overall time spent developing. YMMV I guess, depending on what organization/codebase you are working on.


Probably just GitHub (the browser UI). If you want to do it offline or from the command line, I understand why you might hesitate want to check out files, but stashing in git is extremely easy.


git log, copy paste hash, git checkout

If you have a dirty wd, stash.

But, to be honest, I almost never perform that action, and when I do I use the web browser.


> git log, copy paste hash, git checkout

You remember the hash of your June commit 3 years ago??

> But, to be honest, I almost never perform that action, and when I do I use the web browser.

Web browser... for a local repo? Or do you mean you don't have a solution if your repo isn't on GitHub or you don't have an internet connection handy?

(You should also time yourself on your web interface by the way.)


> You remember the hash of your June commit 3 years ago??

...which is what the git log above is there for.

> Web browser... for a local repo? Or do you mean you don't have a solution if your repo isn't on GitHub or you don't have an internet connection handy?

Yeah, local repo. You know, git is not GitHub. :)

> (You should also time yourself on your web interface by the way.)

Just paste the hash commit in the HEAD selector or even in the URL.


> "when I do I use the web browser"

So a graphical interface then? I'm sure you can see why using a GUI for other functions is just as useful.


Try doing a merge with IntelliJ's 3-way merge UI. It's flippin' fantastic compared to roaming through the files and removing sections between >>>> and <<<<.


Command-line git allows you to specify a mergetool, many of which are capable of three way merges.


The point was convenience. I don't have to leave the IDE.


For some people Unix is the IDE.


Many people are visual. It's a lot easier to see changes, compare diffs, and generally follow the development branches through a GUI instead of through a command line.


I think the main advantage of GUIs in general is a contextual, curated explorability that is often lacking in CLI tools. The GUI is stateful, allows the user to click on things and prod it, and hopefully shows the most frequently used features for that context. This allows even complete newbies to be productive almost immediately.

For something like git, the slightly more visual representation is a benefit to many, too.

I'm not here to knock CLIs, there are a set of tradeoffs to be made, and CLIs win in many cases (flexibility, scriptability, being able to copy snippets you frequently use, etc). The above does tend to hold true, however.


Git is famous for being unintuitive?


Infamous, and a more accurate description might be that discussions about git are well-known for quickly descending into discussions about whether or not it's intuitive and whether or not that matters since you use it every day you'll soon get it and no longer care that much how intuitive it is anyway.


Just give thanks that you did not have to work with the likes of CVS and such.


One of the advantages is you can easily explore what changes were made and merge conflicts through the tool.


I like to drag and drop commits into an order I want when doing an interactive rebase.


That's easy with the TUI


Dragging and dropping? Or do I have to rearrange the lines using a text editor?


Rearranging a line is 3 keystrokes in vim, which I use for that particular action, since it is perfect for that, rather than my normal GUI IDE.


I wonder the opposite thing: why do people try to use git in a terminal?

Its output is so rich and complex that it's impossible to make it legible outside of a real GUI, with graphics and colors.


for a new person, it's almost impossible to get anything done with git command line


You could say that about any tool, of course you have to spend some time to understand how to use it safely and effectively.

'for a new person, it's almost impossible to get anything done with a table saw'


do people say, "a table saw is simple and intuitive"?


Well on the face of it, it's a simple tool isn't it? It's a spinning saw blade, and surface(s) against which to rest the wood being cut.

And I've never used one, but I'm sure it takes some learning, skill, and practice to get good cuts the way you need them, e.g. bang on 45deg all the way across for a 'mitred' corner joint. And it certainly needs learning, care, and attention to operate safely.

I don't mean it to be an insensitive analogy - accidents involving table saws are obviously horrendously worse than those involving git.


I haven't heard anyone say that, but after thinking about it for a second I sure as hell would. A table saw is a lot easier to use than git.


I think most folks like a graphical merge tool, such as opendiff, or at least that's what I've been able to glean.


I work on a lot of repositories, having a GUI makes it really easy to change context and getting up-to-speed quickly.


As someone else mentioned here, the graphical merge tool in IDEA is extremely powerful. Plus keyboard shortcuts to all the main Git actions. It's overall more efficient. However I always use Git IDEA + Git CLI side by side.


Switched to Fork from SourceTree, never looked back.


Thanks for your thoughts on this, Thijs! Here's Tobias, the CEO of Tower.

We want to make sure that Tower can stay a high-quality application in the long run. This means we want to constantly improve the application, add new features, fix bugs, and help users with great customer support. To be able to do that, we need a steady and reliable source of income. The thruth is: for us - a small, self-funded business - a recurring revenue model from a subscription is the only sustainable way to survive.

A model where the user gets to keep the last version after she stops paying for the product does not work for a small business. If you have a team of 1,000 employees like JetBrains, you might be be able to afford this. But not a 7-person team like ours. For two reasons:

(1) First, it doesn't provide the steady and reliable source of income that we depend on. It's the old one-time payment model of the past - which we tried and which did not pay the bills for us in the long term.

(2) Second, and maybe more importantly: very quickly, there are lots of different old versions of the product out there. People want bugfixes, documentation and support for their version, no matter if they're currently paying or if they don't anymore. With a 7-person team, we simply cannot do this. We need to focus all of our painfully limited time on _one_ version and make sure to improve that one.

Most of our users make a simple calculation: "Can Tower help me or my team save some time or prevent some mistakes?" Over the course of the next 12 (!) months, even 1 or 2 hours or a mere handful of mistakes would make this worthwhile. If so, Tower has _easily_ paid itself off.

We offer a free and fully-featured 30-day trial that will help you answer this question for yourself - without any risks or commitments.


For the customer, automatically converting long subscriptions to perpetual licenses for an old version is a major safety net (the software will not stop working if I stop paying) and it proves that the vendor is committed to improving the product enough to make upgrades compelling.

On the other hand, reasonable customers do not expect support beyond the latest version and whatever they are currently paying for: "we have fixed that in the latest version, which you should buy" is a valid and honest answer to support issues.

For a tool that can be changed with very little friction like a revision control client, the typical "calculation" about spending money is likely to be waiting for an actual troublesome situation and then get out of it with a short subscription or a 30-day trial.


To summarise, you say you're not offering perpetual licenses for old paid-for versions because you don't feel you can make clear to your customers they don't come with support.

For some reason you do expect you can sell them on this new payment model that benefits mostly you, so it's really not your communicative skills or your customers' capacity to learn that are the problem here. That really only leaves us with the financial advantage to you.


There are many comments complaining about exactly that product, you probably ought to spend a bit more time on that thread.


Try SmartGit. I don't know how it compares with Tower, but it is very powerful and easy to use. I like the way it integrates Git features into a consistent view. For example, stashes and reflog commits can be viewed and manipulated in the same log view as any other commits.

They offer both purchase and subscription models, and a free license for open source work. Runs on Mac, Windows and Linux. I've been using it for years and have always been very pleased.


Also take a look at Git Extensions. I like this product a lot. It’s open source


I switched from smartgit to fork. Fork is really nice to use and very keyboard driven. Also free.


FYI, Git Tower is made by JetBrains is made by 7 people. JetBrains is a company of 1000. Not all software scales to allow that kind of model.

Also, JetBrains can afford that model because the JDK and other software languages are changing and it's not very feasible for their users to stay on an old version for very long.

https://www.fournova.com/company

https://en.wikipedia.org/wiki/JetBrains


Same here for Adobe Creative Suite; still on version 6 (perpetual license), which I run in a Virtual Machine due to support end-of-life.


Switched to Affinity, Photo, Designer and Publisher are pretty awesome and a true replacement for Photoshop, Illustrator and InDesign. Switched 1.5 years ago, never looked back and saved a lot of money in the process. There are a few things it doesn’t have, but its impressive nonetheless. The devs are very committed to speed and anti bloat.


FWIW, I think Adobe actually adds quite a bit to Creative Cloud every year, plus they offer fonts and connections with their mobile apps and such as part of the same price. Creative Cloud today is a very different beast from CS6.

(obdisclaimer: I worked for Adobe several years ago, but have no current stake other than being on the CC photography plan)


Same boat here. I’ll concede that they do add things, but as a pretty small scale hobbyist they don’t add anything I want or need. But they expect me to pay the same full price as a pro user.

I used to buy it every couple of versions or when it went on sale, and that was good enough for my needs. No such luck anymore.


Depending on what you do use, Mac users actually have lots of great choices now. The Affinity apps, for example, are terrific.


I’ve got them!

Did a stint on Sketch as well. It’s now gone subscription, but it think it’s the more acceptable “still works but you stops getting updates” type subscription like jetbrains.

What I really want is an Affinity photo library manager like Lightroom. I’ve looked at some currently available options and not been impressed, but there were tweets to the effect that Affinity was thinking about it.


I believe its the current objective to produce a lightroom alternative.


Best I’ve found is “considering it,” but fingers crossed! Seems like the next obvious step after vector illustration, photo editing, and desktop publishing


And I think all the plans come with cloud storage which syncs across devices.

I fought the subscription plan for LR, but realized I usually updated yearly and had this complicated file management system for my photos. For $120/year I have the latest LR versions on all my devices and only have to worry about true backup.

I do keep an eye out for a LR replacement, but I haven't found anything that comes close to LRs file management.


Intuit Quickooks is same way. Hasn’t substantively changed in 20 years but they stop you from importing new data if you don’t update to latest every 3 years. They need some real competition.


Switched to GnuCash and didn't look back. The UI is uglier, but at least it works correctly with double entry bookkeeping.


There’s Sage 50 if you want desktop, but even desktop QB is on life support and everyone’s going online.


> They need some real competition.

Have you tried Xero? I haven’t, but if you have, I’d be curious to hear your take on it.


We run our company on Xero, it's pretty good!


I upgraded to version 3 but feel like they haven't made a product improvement since, despite the new subscription model. Staging of chunks still remains the killer feature to keep me with it but I'd be happy to switch (pay) if anything else came along.


It’s interesting to see quite a few others in here had the same struggle with upgrading to tower 3 as I had a year (or 2?) ago. Then I moved to vscode with it’s git integration and that works just as good.


I switched from SourceTree to Fork, which is awesome for me. Check it out.


>But with a very customer-friendly clause of where if you pay for a subscription for 12 months you get a perpetual license for the latest version of the product when you initially subscribed. And then after paying for any particular version of a product for 12 months, you also get a perpetual license for that particular version and so on and so forth

This came about due to a decent amount of consumer backlash, if I recall correctly. They used to sell standalone perpetual licenses which included a period of updates.


When you say it like that, it doesn't sound amazing, but you can also phrase it as:

"JetBrains listened to their customers, took feedback on board, and made meaningful changes that addressed the concerns."

In a perfect world, that would the minimum expected behaviour, but in the world we live in, it's kind of surprising when it happens.


Or.. JetBrains went ahead with a disliked move, then took a half-step back. There's still a half-step in the wrong direction remaining, on top of showing that they would have been willing to go the whole way if they could have gotten away with it.


"JetBrains listened to their customers..."

Yes, you can make something sound positive when you leave out material facts. They knew an expiring license would be much less popular than a non-expiring one before they did it. So, just saying they listened to their customers leaves out the very important detail that they ignored their customers the first time around.


You can frame it whatever you want. Fact is, if not the pushback JetBrains would be worse than Adobe


It wasn't amazing. There was a lot of unneccessary effort to change their mind.


Still commendable given how common it is these days for companies to get consumer backlash and just continue to do the same thing while comically trying to publicly convince the customer base that the new model is somehow better for them when any rational person can see it isn't.

Also useful as a guide to show the customer they should go ahead and voice their displeasure when these situations arise, preferably before the product is so entrenched in the given market that they can "pull an Adobe" in this situation ("Don't like the new terms? Fuck you, pay us").


Oh, absolutely. I think they handled this particular change quite gracefully. It's a compromise.


A huge part of the backslash actually happened here on HN when they originally proposed the pure (like Adobe and 90% of other companies) SaaS model.

  So Jetbrains model is an improvement over most other companies but it is not as consumer friendly as the old licensing model.

  I would love to have the old model back(buy now with 12 months of updates) but that ship has sailed.


Sure, it came about due to backlash - but they still listened to their customer base and made changes, quite publicly admitting they had pushed the subscription model too far.

Honestly I’m quite happy with it as a compromise, especially with the All Products Pack - I save money every year than when I used to buy upgrades for IntelliJ and ReSharper stand-alone, and JetBrains has incentive to keep pumping out new features to keep me from deciding to utilize my fallback license.


Google must play InteliJ for the Android Studio License use, right?

I wonder how big is that part of the revenue.


I think android studio uses the community (open source) version of IntelliJ Idea, so it should not be a big part of Jetbrains revenue.


Given that Kotlin now also is first class development language for Android, I think Jetbrains gets plenty of revenue from Android


I don't think Jetbrains gets any money directly by the usage of Kotlin on Android, as Kotlin too is open source, and works very well in IntelliJ Community (also open-source). In fact, I don't think IntelliJ ultimate has any extra Kotlin features.


No, but IntelliJ ultimate has more features than Android Studio given there are JetBrains developed plugins that aren’t available in the CE platform.

Guice support, for example. You can live without it, but if you are working on a larger Android codebase and utilize it then it may be useful.


IntelliJ Ultimate has a lot of extra features, yes, but I don't recall any of them being related to Kotlin, or Android, so I don't think the parent comment claiming kotlin usage will result in extra revenue is relevant.


Regardless, I’m sure they are getting money.


> They used to sell standalone perpetual licenses which included a period of updates.

I'm missing something. What's the difference between that and what they're doing now? You pay $X, you get a perpetual licence and updates for a limited period.


Your perpetual license is for the oldest version available during your subscription period, not the newest.

Old model: Pay $X.XX and get one year of updates.

New model: Pay $X.XX (spread over 12 months) and you can use all new versions UNTIL the subscription ends. At which point, unless you renew, you have to DOWNGRADE to the one year old version.

Let's face it, downgrading such an import tool is not something developers will be comfortable with (especially since JB products occasionally have show-stopping bugs).

Having said that, I'll admit to liking their products (and support). But the model is not as generous as everyone seems to think.


IIRC, the price of 2 year subscription is still cheaper than the 1-year update of the old model. They even offered subscription discount when they were transitioning, so the out-of-pocket is still cheaper than the old model.


So that was the original plan but I believe they changed to the “more reasonable” one after the backlash (so you get the current version + 1 year of updates)


The original plan was that you'd lose access completely. The "more reasonable" one was the 1yr downgrade.


In addition to what michaf mentioned, what we have now is not what they originally proposed.

https://blog.jetbrains.com/blog/2015/09/18/final-update-on-t... - the perpetual license fallback did not exist under the original proposals and only happened due to backlash.


Why does this matter? Yes, their original plan was pure SaaS. But they listened to criticism and changed it once they realized that there was backlash from the community. If anything, that should be admired not criticized.


> Why does this matter? Yes, their original plan was pure SaaS. But they listened to criticism and changed it once they realized that there was backlash from the community. If anything, that should be admired not criticized.

It's useful context. Yes, it's good that they listened to their customer base - and I've not criticised the current subscription model.

But I still think it's relevant and on-topic to point out that the previous model was more generous and they tried to do full-SaaS when reading the parent comment in isolation sort of suggests they did this out of the goodness of their hearts (and entirely unprompted).


It's matter, because even in this thread you have people prizing jetbrains for beign better than Adobe SaaS, but in reality jetbrains would go even futher than any big predatory corporation out there to vendor lock you into their set of tools.

If you have an option, stick with open tools with strong community support. Just observation: with commercial tools you don't have full control of your own work, nuff said


Now the perpetual licensed version always lags 12 months behind in updates, i.e. you do not have a perpetual license for the past 12 months worth of updates at the time your subscription runs out.


This is incorrect. Lots of people believe this but it just isn't true.

When your one-year subscription expires you actually have a perpetual license for the first version that was available when you signed up. NOT for the last one available when the contract ended.

In other words, when your one year subscription is up, you have to downgrade to a one year-old (possibly buggy) version.

For more mature toolchains like C or Java, this seems reasonable. For ones that undergo massive updates each version (WebStorm, AppCode) it's a non-starter.

EDIT: on second read, this may have been what the parent poster was trying to say. I'm leaving this comment as-is though because there seems to be a TON of confusion about this point.


The OP said:

> you get a perpetual license for the latest version of the product when you initially subscribed

Which is correct, and is the same thing you described.


On second read, you might be right so I amended my comment... In my defense, OP's comment is ambiguously worded. What you actually get is a permanent license to the oldest release available during your subscription. OP also says:

>... after paying for any particular version of a product for 12 months, you also get a perpetual license for that particular version and so on and so forth."

Also kind of unclear. And judging by the comments here, many many people misunderstand this. I think it's a general expectation that you'd get access to most up-to-date version of the product when your subscription ends. Not the version from the day your subscription started.

Think about it. If there's a bad bug or regression in the old "perpetual" version you aren't entitled to the subsequent bug fixes. Bug fixes which you've been "using" for the past year. It's kind of a hard thing to swallow.


You get the latest version you subbed to. So if you subbed last in 2018, you get that version. If resubbing j. 2019, the 2019 version. Also every year the price goes down, so you pay less and less.


That's misleading. Each year has multiple point releases. You don't get the latest point release.

My PHPStorm subscription expires in less than a week. In order to continue using it (without re-subbing), I have to downgrade from 2019.3 (current release) to 2018.3 (the release available on the date I subbed). Software that is one year old.

Similarly, the JetBrains site says my WebStorm subscription expires in around 10 months. At which point I have to downgrade to 2019.2 if I don't re-sub. Today's current version is 2019.3.

>Also every year the price goes down, so you pay less and less

That part is true and it's certainly commendable that they do that.


I recently renewed my PHPStorm subscription (again). Not because there are hot features released in the past year which I'd miss.

Rather, I thing it is right thing to do - to pay some recurring cost for the software we use and to let the developers of that software to make their buck.

We are too accustomed to get everything for free at the expense of someone else.


> For ones that undergo massive updates each version (WebStorm, AppCode) it's a non-starter

At least you should still be able to open up old projects.

If you use Adobe Creative Cloud, and you stop paying, do you lose access to all your data?


Plus in all honesty, lots of Adobe software behaves like a virus by installing these always running updaters. I haven't had Flash in my laptop for sometime and the web has evolved to a point that it was never an issue, but the CC updater ended up saying I needed to install the latest update to Flash.

I have already tried Pixelmator and the Affinity suite, but after that shady behavior plus the monthly fee, I ended up uninstalling anything Adobe based and just switched completely to Affinity Design and Photo. The only thing I'm missing is when somebody sends me an .ai file in a certain format, but if they export with SVG or with PDF support, zero issues there.


I'm amazed you think that way. It's a huge step down, and incredibly customer hostile. I stopped giving JetBrains money when they switched. If there's no perpetual licence, I'm not buying.

In the old world, you bought the latest version, got upgrades for a year - sometimes more, then got a discount on upgrading come a newer version. At any time you stopped paying you kept the latest software, in sync with everyone else. You'd slowly move out of step.

In JetBrain's fabulous con you pay a sub for the latest, and if you decide to stop paying - almost certainly having paid markedly more during the duration of your sub than under the old model - you get shunted to an older version, instantly putting you at least a year out of step with everyone else.


This is a terrible terrible business model despite good intentions. Let me explain... Vast majority of developers who can pay are living in corporate world where you need to approve expenses each time charge is made. Subscription model is especially bad in that world because PO approvals for subscriptions are usually very hard, at least requiring additional justifications + process barriers. Most folks would just rather not do it or find alternatives. I've seen this first hand even when folks are very fond of product.

A far better licencing model is to have one time charge and free upgrades for a year followed by nagging that can be turned off. This would have exact same effect but much easier to have purchase orders pass throughs in big company rule books.

JetBrains have far more potential than $270M. One of the easiest thing they can do is to allow users in same companies to form user groups on their website. They can then approach those companies to buy site licenses with list of all these supportive users at those companies. They can then evangelize to users within same companies who are not yet using their products. This would make sure their subscription churn is lowered due to individual developers.


I understand the business reason for the licensing model so I don't really hold it against them, but after a couple years of 'Oh, you want fixes for these bugs we introduced recently? You'll have to buy another 12 months' where they constantly kept breaking new things when landing important fixes, I got fed up with the treadmill and just stopped using their products (in my case, ReSharper and dotTrace). I'd get problems like "having ReSharper for C# installed breaks VC++ compiles" (yes, really) and very often they'd just close the bugs outright or tell me the fix was only in the upcoming paid version with its own new bugs.

I feel like this is the downside to the subscription license model - if you want to use the product at all you have to keep paying unless the version you've currently got is somehow perfect. And in the case of JetBrains products I've used, it is not. I wish companies like this offered something like an LTS branch where I could pay (subscription even!) for a version that just actually works instead of constantly having to put up with new features/bugs just to get fixes for workflow issues.


That's my experience also. It's like their model almost incentivizes them to introduce regressions.


Honestly, I don't really have a problem with subscriptions generally if it's a product that I use regularly. (Modulo "reasonable" pricing of course.) Where I have an issue is when I need a product I rarely use any longer to open an existing file or do some once in a blue moon task.

At some point, software stops working with OS upgrades etc. anyway and I can deal with that. But I don't want to pay a subscription for something I use a couple times of year and don't need the latest version of.


You also get loyalty discounts on your subscription!

After year three even their "everything" licence feels affordable for a working dev. (€649 for the first year, €389 by year three: https://www.jetbrains.com/store/#commercial?billing=yearly )

I wish more companies did this.


Their "everything" commercial license is €249 for y1, €199 for y2 and €149 for y3+ as an individual: https://www.jetbrains.com/store/#personal?billing=yearly

The organizational license is only needed if your employer is paying for you or compensating you for the license cost: https://sales.jetbrains.com/hc/en-gb/articles/207241075-What...


Considering the hassle involved in switching employers, then licenses, I’d much rather just use my personal license anyway.


If I remember correctly when they first announced they were moving to a subscription based model a few years ago years ago there was a backlash from customers and they listened to customer complaints and modified the model to be what it is today. Another plus to them in my book for doing that.


Same here. I wish everyone company with a subscription based licensing model did it this way. It should be noted though, when Jetbrains initially decided to move to this type of licensing, it was a bit different and they got a lot of backlash from existing users (including myself), but credit to them for listening and amending it to something better for customers.

I've been a happy customer and Resharper user for many years and it makes my life much better, so it's great to see the company doing well.


Totally agree. I thought Adobe's offer would be just as good until I cancelled early and got bit in the arse. I basically paid more money to cancel than what I would have paid if I left the sub open, and of course I lost access once I did cancel. Total asshole design there.

I go back to JetBrains and now I basically have to use their IDE because my company does, and it's not very easy to get the same kind of experience with Java with Vim or Emacs.

I'm using CLion to help me learn C++ because it knows C++ better than I do (and on a Mac I'm not using Xcode for writing C++, only building it). For £10-£20 a month, that is discounted every 12 months, with full ownership of the last version you had... it's great. They seem to handle it a lot better than Sketch as well, who will force you to find the download page for old versions. IntelliJ just seems to give you what your license allows.

I'd still go back to emacs in a pinch but I'm not proficient enough with C++ or Java and those ecosystems to know how to set my environment up.

JetBrains seem to have a pretty fair and solid strategy and it must be doing well enough for them to expand their IDE-base so far.


I'm curious about the counterfactual here. If they had a VC on their board, they may have been "gently guided" towards a pure subscription model since SaaS valuations are much higher.

But, it sounds like a pure switch to SaaS would have alienated customers and perhaps would have forced more users to seek alternatives, and we might not have seen the business as this scale today.

Wonder if this was the optimal move at the time.


As others have mentioned, the fallback license is for the point releases you have paid 12 months for, not the most recent release during your subscription (which is what your comment suggests).

It’s also worth noting that the requirement is 12 consecutive months. You can’t have any breaks so you need to be actively subscribed to take advantage of this.

It’s not the best solution (I am a fan of pay for a year (prepaid or monthly) and you get 12 months of updates where you keep all of them), but it’s a good compromise in the era of SaaS. And a compromise I’m willing to make for their IDEs.


That didn't happen by what they tried to push. This happened because there was lots of developers threatening to walk over a pure subscription model.


That's still the good thing. Can change the narrative to "developer tools company listens to its customers and gives them a fair deal". The effect is amoral, even if the cause is moral.


Oh, I remember that pushback. Glorious days of outrage culture when it wasn't abused yet and the consumer power was strong


The thing I like is that their stuff makes it easier to develop and is reasonably priced.

If your company won’t pay for it you can buy a personal subscription cheaply.


Also the core of their main product, IntelliJ IDEA, is open source. And it's actually pretty usable for Java and Scala development for example, which is my interest in it.

The Ultimate version comes with bells and whistles, but truth be told I'm only paying for it because of how happy I am with it.


Interesting... the problem with this model is that investors / the market value SaaS revenue way higher than revenue from perpetual licenses, for a variety of reasons. Although I guess that doesn't matter when you're not raising or public :)


I was using their RubyMine editor for a few years and really liked it but then I switched jobs and ended up using vscodium and found it did basically everything I needed but was free.


I think Sketch does this and I agree, it's the way it should be.


That's an absolutely brilliant pricing model. I love it.


I agree with many of the other posters: JetBrains has succeeded because their products are generally awesome, and I am a happy personal subscriber. People should especially remember what the Java IDE landscape looked like when they first came out with IntelliJ: using IntelliJ after using NetBeans or Eclipse was like using Google for the first time after being familiar with AltaVista - it was just a night and day better product.

Still, I wonder if they could have been successful without funding if they were a US or Western European company. Especially in the early days, I'm sure the much lower salaries in Prague allowed them to be more competitive with a lower burn rate. My point is I think their VC-less success would have been much more difficult in a place with higher salaries and cost-of-living.


>I'm sure the much lower salaries in Prague allowed them to be more competitive with a lower burn rate

It's a russian company with the most people (especially engineers) in St. Petersburg. It's only technically registered in Prague. They have only 50 people there. And around a thousand people distributed across Russia (St. Petersburg, Moscow, Novosibirsk), Munich, Boston and brand new office in Amsterdam.


Prague is mostly sales. Although, some engineers wanted to live there so they do. SPb is the main engineering office. Munich is somewhat smaller, but has more high profile employees. Moscow is like 20 people who need to live in Moscow.


[flagged]


Please don't take HN threads into nationalistic flamewar.

https://news.ycombinator.com/newsguidelines.html


That Cold War mentality is getting old already. The world has a lot more to gain if we drop the "my approach is superior" in the process. Russia and China is not filled with demons, and much of the same things they are being acused of can be said of the US, from severe human rights violations in Guantanamo, migrant populations and pretty much being involved in almost every war out there while destabilizing countries that do not follow Washington's views in the process.

But there is no way I'll let all of those issues start affecting me with an anti-American attitude, and all the same I won't be having an anti-Russian or anti-Chinese attitude. First, I don't have anything to gain. I think China is making the best price/value phones out there at the moment, Russia has JetBrains and some good tools like Yandex for Domains which is free, and the US, well Google/Android/Apple you name it.

In a way it is like the console wars. Instead of going with Nintendo against Sega, just get both consoles and be happy.


> Russia and China is not filled with demons

Russia and China's citizens are not demons or angels, their moral character, I'm sure, is comparable to anywhere else. But... the governments of those countries wield absolute power over those people. The moral character of the people is irrelevant.


[flagged]


Which products do you buy that come from a country that doesn't marginalize some group?


While they may employ engineers mostly in Russia I think the company is incorporated in Prague (EU) and the CEO and head office are there which limits the ability of the Russian government to tell them what to do.


Why is that? And, alternatively, who would you trust?


Russia is a malevolent authoritarian regime. Russian companies (like Chinese companies) have no power to resist the dictates of their authoritarian governments. I don't trust anyone completely, but democratic countries where government authority is checked/constrained by the people and competing forces are far more trustworthy.


At least some of Jetbrains' offerings are open source. If you have security concerns, you may be able to alleviate some of them by your own examination.

I'd also encourage you to consider separating your concerns about the Russian government and individuals living in Russia, just as you might other governments and their citizenry.


> At least some of Jetbrains' offerings are open source. If you have security concerns, you may be able to alleviate some of them by your own examination.

Good points

> I'd also encourage you to consider separating your concerns about the Russian government and individuals living in Russia, just as you might other governments and their citizenry.

I do separate them, in a moral sense. But in a practical sense, Russian companies can't really be separated from their authoritarian government. What can they do to resist? There are no checks and balances. To be fair, Jetbrains was probably even around before Russia even started to settle definitively into its current authoritarian predicament. But thanks to the Putin regime, how on earth can they be trusted?


In a practical sense, how could JetBrains' software compromise security? People don't generally deploy build artifacts built from IDEs. And I suppose you could turn on a network monitoring tool to see if JetBrains software is broadcasting anything.


Access to developer workstations (and all their permissions) is desirable on its own, even if you aren't modifying the specific projects they are working on.

Telemetry features (on by default) can/could be used to obfuscate nefarious network chatter.


> I'd also encourage you to consider separating your concerns about the Russian government and individuals living in Russia, just as you might other governments and their citizenry.

That's a big ask, because the Russian government's relationship with its citizenry is very different from the relationship of a free country's government with its citizens. Namely, I am confident that there is substantially zero risk that my country might compel me through extra-legal channels to modify my work product to target a foreign adversary. If they did, I would have many avenues to resist them, including the courts and the free press. But we know that this is not the case in Russia, being that they have neither rule of law nor a truly independent media. And we know that the head of that country is at best a violent and evil man, and so is an entity to be feared by those whose interests are misaligned with his.

So, as much as we might want to, it's not quite possible to separate the risks imposed by the Russian government from individual Russian people.


> And we know that the head of that country is at best a violent and evil man, and so is an entity to be feared by those whose interests are misaligned with his.

I’m not quite sure which country you were talking about?

While I agree with your general point, it just occurred to me that that could be applied to both leaders. It’s the country and the structure of that country that is different (e.g. leaders will change, vs not).


I hate Trump as much as the next guy, but he has not annexed any provinces of Canada or Mexico, nor has he ordered the assassination of journalists or opposition party members. Maybe he would in a different timeline, where the U.S.'s rule of law was as frail as Russia's is. Maybe, although I happen to believe he is not quite that bad. Fortunately we don't live in that timeline, in any case. How evil the guy at the top is matters more to the degree his acts are unconstrained by the rest of the system.


> but he has not annexed any provinces of Canada or Mexico

But he already expressed intention to get Greenland, no?

Yet something tells me that if, say, Mr. Obama did present Point Roberts ( https://www.google.ca/maps/place/Point+Roberts,+WA+98281,+US... ) to Canada (as Khrouschev did with Crimea) then nothing would stop Mr. Trump to take it back.


The US has annexed parts of Mexico before : https://en.wikipedia.org/wiki/Mexican_Cession. Also, accusations about Putin ordering the 'assassination of journalists or opposition party members' are not proven beyond reasonable doubt. Read about the long history of western anti-Russian sentiment and propaganda here : https://en.wikipedia.org/wiki/Anti-Russian_sentiment


> The US has annexed parts of Mexico before

Whataboutism. And, yeah, that was super bad. So, for that matter, was the whole colonial era. But none of those guys are still the leaders of nuclear-capable nation states, so they're a little less relevant than Putin to our prospects going forward.

> are not proven beyond reasonable doubt.

This is not a court of law. My standard for "observing events as likely true on internet comment threads" falls somewhere below "beyond a shadow of a reasonable doubt" and somewhere above "preponderance of evidence." But I'd say for these cases we're way closer to the former than the latter.

> Wikipedia link.

On the other hand, Russian nationalists and apologists of Russian politics are sometimes criticised for using allegations of "Russophobia" as a form of propaganda to counter criticism of Russia.[14][15]


> Whataboutism

The argument here is that USA cannot claim moral high ground when USA is actively committing the same act. Blindly claiming whataboutism without even attempting to refute this argument and is, therefore, a form of intellectual dishonesty.

> This is not a court of law, so that's kind of irrelevant.

It is important to make reasonable arguments in defense of your claims even outside courts of law.

> On the other hand, Russian nationalists and apologists of Russian politics are sometimes criticised for using allegations of "Russophobia" as a form of propaganda to counter criticism of Russia.

This is neither here nor there. This whole argument is inconclusive.


> The argument here is that USA cannot claim moral high ground when USA is actively committing the same act.

I guess I just don't consider an annexation from the 1840s to be "active" the same way I think of one from the 2010s.

> Reasonable arguments outside court

Sure. And I think most reasonable external observers agree that Putin has likely ordered the assassination of at least several of his critics.

Bendingo 35 days ago [flagged]

> zero risk that my country might compel me through extra-legal channels to modify my work product

I assume therefore, that you must not be Australian [1]

[1] https://www.schneier.com/blog/archives/2018/12/new_australia...?


How quickly you forgot Edward Snowden.


Right. I refuse to use Russian software on my computer made in China!


McCarthy must be smiling reading this.


Which is a pretty strong vote for building your company somewhere with lower salaries and lower cost of living.

There are a LOT of great engineers in places other than SV, Austin, Boston, etc.


I'd say it's a strong vote for building an actual product people want, which SV startups seem to struggle with.


This has been the bet of the company I work for: Contract Engineers in GDL, Mex. Paying 1/3rd the price of SV payments and still getting awesome talent, while being able to provide very competitive benefits for the region.


>remember what the Java IDE landscape looked like when they first came out with IntelliJ: using IntelliJ after using NetBeans or Eclipse was like using Google for the first time after being familiar with AltaVista

You're skipping over several commercial Java IDEs available when IntelliJ first came out: Most notably, Borland JBuilder, which was an excellent product. Symantec had Visual Cafe as well, which was not really in the same league as JBuilder, but still had some magic.

IMHO, JetBrains succeeded by having a product as good as JBuilder (and revving it so it got better quickly) and not cratering as a company the way Borland did.


IntelliJ was much faster than JBuilder. This is what I remember most, IntelliJ was as fast as using Visual Studio.

I liked JBuilder, but VisualCafe was a nightmare. But IntelliJ was much more responsive and much cheaper.


> Most notably, Borland JBuilder, which was an excellent product.

I switched from JBuilder to IntelliJ in 2002 I think.

JBuilder was good but on oh so expensive, if you wanted the full-featured version! IIRC it was 5 or 10 times the price of IntelliJ.

What blew me away when I tried IntelliJ for the first time, in comparison to JBuilder, was the refactoring tools. For the first time I felt I could safely rename classes and methods and move classes without manually searching my codebase.


I'm an outsider fan. I've attempted to use IntelliJ on multiple occasions, but it just can't really compete with Eclipse as far as my requirements are concerned. But the competition from and innovation in IntelliJ has no doubt made Eclipse better (and modern Eclipse is kind of awesome and just keeps getting better).


I switched from Eclipse to Intellij only three years ago because it actually used to be pretty good but just fell behind too much. Gradle & Spring Boot were the reason I gave up on Eclipse. I just couldn't get a project imported correctly without running into a lot of bugs. So, when a new project came up I just switched over and started using Intellij.

Before that, for doing vanilla maven + Java projects Eclipse was awesome and generally running circles around intellij in terms of performance, which is still something that is off by order of magnitudes in Intellij and something I miss a lot.

Intellij users are always surprised when I bring that up and say it is fine on their machine. And then I point out that 5-20 seconds to run a unit test after a 1 letter code change is obscenely slow compared to Eclipse because it finishes incremental compilation a few ms after you lift your finger and is ready to run your test. Intellij attempted to integrate the Eclipse incremental compiler but it is not used by default and generally not that well integrated. Their compilation strategy depends on a lot of caching, which is hard and frequently gets in an inconsistent state (i.e. your IDE lies to you about things compiling or not compiling), which is why people routinely rebuild their whole project, or worse invalidate caches and restart (a top level menu option because it needs to be).


There are, despite the often very aggressive IntelliJ proponents, many areas where Eclipse beats IntelliJ, and incremental compilation is indeed one of the most important. It is also possibly the most important feature in a Java IDE. Ctrl+s and you know the whole codebase is compiled. Go to another file and any code change is available in the code completion (like new or changed methods signatures). Any errors from the change you just saved is shown immediately from across the entire codebase.

I just can't live without a core thing like this missing, and compounded with a number of other things that Eclipse does better, I stay on Eclipse. Unfortunately many younger developers think IntelliJ is all there is.


When's the last time you checked out IntelliJ? It does incremental compilation these days, plus auto-save-and-compile whenever you switch tabs (not just when you save the current tab, which bit me many times in Eclipse; though I haven't used Eclipse in at least four years now), so code completion is immediately updated. I'm pretty sure this has been the case for a few years now.


Yesterday, sorry to say but still off by magnitudes. These things are measured in ms on the eclipse side and in whole seconds on the Intellij side. On a good day it's less than 5 seconds in Intellij. I developed in Eclipse before I switched a few years ago and while it was a bit finicky with gradle, maven support was pretty solid. I never had issues where Eclipse compilation state was wrong for more than a few hundred ms. Basically if it says it compiles it means it compiled without errors, class files exist and when you run something it jumps straight to forking the process with no delay. In Intellij, it takes seconds at best; sometimes closer to 30-60 seconds.

Given that performance is a recurring topic in the Intellij release notes I conclude that they know they still have issues there and they are slowly looking for ways to make things faster. This is not a solved problem.

Part of this is the Kotlin compiler; part of this is indexing; part of this is simply caching logic.

I recently worked on the Elasticsearch code base in intellij. Fast is not a word I would use to describe that. It's a big code base and it clearly was struggling with it. I know some Elastic developers that still use Eclipse basically for this reason.


What is it about your requirements that means that IntelliJ can't compete with Eclipse?


I'm a contractor working on many projects. Using Eclipse, I can keep my entire universe of all projects I have deployed (about 30 of them), as well as their dependent libraries, as well as every open source project I use and contribute to, open at all times.

I almost never close a project and I never open a project. It's just all there. If I need to use or modify a piece of code, written by me or someone else, it's all accessible to me at all times with a single keystroke.

No project switching. Close to no context switching. IntelliJ doesn't even come close to this kind of power.


I'm like the parent ... Eclipse provides an omniscient view of all my work with instant incremental compilation across all my projects, spanning PHP, JavaScript, Python, Java, Groovy, Kotlin, and more. Run with enough memory it just becomes like another part of my brain.

When I use IntelliJ I feel like I'm using a nice tool with a lot of sweet superficial features but lacking the comprehensiveness and the underlying grunt of Eclipse. It's like driving a Maserati (IntelliJ) vs a SUV (Eclipse). Yeah, I can drive around town pretty quick in a Maserati but for getting real heavy duty work done, it's an SUV every time.


Really interesting description, thanks. How does current Eclipse compare to Netbeans? I currently use vim and VSCode, but in my Java years (10 years ago) I remember moving from Eclipse to Netbeans mainly for the form builder and because of performance.


It's bean so long since I used NetBeans that I can't make a good comparison unfortunately. I do know it never surpassed eclipse for me but some of the reasons for that were probably circumstantial at the time (eg: whole team was using eclipse, etc).


You can import projects in all those languages in a single Intellij window and use language plugins right?


I believe you're seeing a conceptual mismatch between workspace and project from how Eclipse and IntelliJ model working.

Try creating an empty project in IntelliJ and then add each of your Eclipse projects as a module to the IntelliJ empty project.


Yeah, tried that. Multiple times. IntelliJ just doesn't handle it performance wise, and it feels awkward because IntelliJ just isn't designed as well for working on multiple projects simultaneously. It's probably great for people working on a single project with some dependencies (modules). IntelliJ really wants you to open a project, work on it, then you close it and open the next project. That doesn't fit me.

Doesn't mean IntelliJ is bad, it's just a bit limited in that regard.

My dozens of projects are not a single project with "modules". I have a universe of code in multitudes of interrelated projects, closed source and open source. I want to refactor openly, not having to care how I'm moving code between projects. Eclipse works perfectly for this. IntelliJ does not.


If the project share code that you want to refactor, then in Intellij's terminology they are modules, not projects

Import each one individually as a new module in a root project, and everything will be hunky dory.

A "module" in this case is just an atomic closure of some sort.

I've got plenty of Intellij projects with >50 modules, each of which are their own git repository, just fine.


You kind of described the exact problem there. You have "plenty of projects with >50 modules". I don't have "plenty of workspaces", just one that contains all my "plenty of projects", almost all of which then depend in some way on a tree of hierarchies also within that workspace.

There are no islands. There's now switching between anything. It's just all my code and dependencies, always open and accessible and instantly available.

Creating a new project in Eclipse then requires no importing of modules on my part, I just create a new project, it's in my workspace and voila—it's now an integral part of my universe of code.


IntelliJ really wants you to open a project, work on it, then you close it and open the next project. That doesn't fit me.

This does not match my experience at all, fwiw. I keep all manner of projects open simultaneously.


I think it’s interesting that this issue was exactly why I switched away from Eclipse years ago. The performance was atrocious.

I guess that pushed them to improve ;)


Yeah, "modern Eclipse" is a very different beast from "several years ago Eclipse", that also goes for performance.

As I said in a parent, I'm very certain the competition from IntelliJ got them off their asses :).


I'm an IJ user and I do this; however I remember eclipse was much better about knowing that you have a dependency also in the workspace and using that when you "go to definition" instead of going to the compiled version.


being able to organize things into separate projects in Eclipse, in the same window, is very nice


That's possible with intelliJ as well (at least in the pro version)


Eclipse project = IntelliJ module

Eclipse workspace = IntelliJ project


There is a single Eclipse plugin that keeps me married to that IDE: log4e (http://log4e.de). It makes it a breeze to add logging statements to your code. One click puts start/end statements on all methods. One click lets you log a particular variable. And all the statements are templatized, making it dead simple to ensure your logging adheres to your company's logging standards. I WISH this plugin (or something comparable) was available for IntelliJ or even NetBeans. I'd drop Eclipse in a heartbeat.


You might be on to something but their product philosophy just seems to be.. different. Compare TeamCity to Bamboo; it's in a different league. Maybe that does come down to the extra human resources they can throw at stuff.

Their products are/were ambitious in an MVP environment.


Some TeamCity details are a bit odd, for example you are not allowed to run a development server and a production server with one license. Instead you should get an evaluation license, that is only valid two months at a time.

Conditional build steps have been requested by users for years and even though it's the most requested feature, nothing has happened for years.

But it's still way way ahead of the alternatives.


>But it's still way way ahead of the alternatives

Like Jenkins, Bamboo, TFS, VSTeam, TravisCI, CircleCI, GitLabCI, UrbanCode?

Maybe it's just me, but the CI/CD space is pretty crowded these days, and Jenkins is still #1 for a reason. I don't find myself fighting TeamCity as much these days but there's alot if things I wish it could do better.


In fairness I have only tried Jenkins, CruiseControl and Azure DevOps. What sets TeamCity apart is the use of Kotlin. You do have to invest a fair amount of time to get the most of it, but when you do the return is great.

Putting together a pipeline in Azure DevOps with tons of YAML is not a great experience.

As far as Jenkins is concerned I think that it's biggest selling point is that it's free.


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.

What do you do in vim that is far easier?


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:

    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()]
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 switched to vscode recently from emacs and was embarrassed about how much more productive I was, almost immediately.


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.


1: ctrl-f, 2:, esc

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.


Did you read what I just wrote? Those commands are not specific to any language.


Sorry, I was referring to the second part (about the linter.)

Obviously the first part is language-neutral, and is exactly why I think multiple cursors is one of the greatest inventions in text editing! :)


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 :)


I guess even easier would be to go to the visual mode, then selecting all the lines and append the commas all at once :)

<c-v>8j$A,<esc>


Isn't `$` is redundant


Not in visual mode.


For your second example, I'd do :2,8s/$/,/<enter>


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


Before a vim'er finishes typing yet another command to find that one specific text, a mouse user will have already clicked where needed :)


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’


All that can be done in vim.

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 always found Jetbrains + vim plugin to be unparalleled. A good friend swears by spacemacs but that’s a different ballgame.


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.


IdeaVim

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.


I use jetbrains and "emacs" key bindings.

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.


my friend had a good sticker on his laptop. “typing is not the bottleneck”

you may be more productive editing code in vim but when it comes to engineering text editing is not the most important thing to be solving for


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.


> within 1 minute, I found 5 things that didn't work correctly

It would be useful to say what these 5 things are.


I don’t know about 5, but some issues I face are:

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.


> editing code using anything else feels like a pain

What if I told you I read way more code than I edit?


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 :)


> I also really like _make_ and wrap my other commands (mvn, gradle, etc) in Makefiles. I get jokingly mocked a lot at work :)

I do this as well. I put my scripts in a make file. E.g. to ssh into a machine X, I write a Makefile with .PHONY rule "X" so I simply run "make X".


I believe that’s a shortcut in intelli-j products. It’s like cmd+[ for last viewed location and cmd+shift+[ for last edit location


Hello! I use Sublime for my complex React project. What should I be using instead?


I don't know what OP uses but I use VS code and it's pretty good for a free editor.


OP is litereally ranting about people using text editors for tasks that IDEs excell at, and you are suggesting another text editor.


VSCode is way closer to IDE than text editor on that spectrum


By that definition Emacs is also an ide just in a kit you spend a few hours putting together.


VS code qualifies as an IDE for React. Just not a very good one.

Most things can be solved with plugins though.


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.


VSCode has out-of-the-box support for JS and TS including autocomplete, visual debugging and variable definition lookup. VSCode is an IDE.


VSCode markets itself as a text editor, but really it's an IDE, especially if you're using TypeScript.


VScode calls itself a Code Editor, not text editor


WebStorm is the JetBrains tool for JS development.


WebStorm is where it's at.


VSCode is good for a free editor. But the difference between VSCode/Sublime and Webstorm is night and day.


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.


Presumably they value aspects of their environment over the features that jetbrains provides.

The complexity is usually overstated and a sunk cost besides.


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.


doesn't most three-way merge software have that UI? like kdiff3, meld, sublime merge, p4merge, vimdiff et al. (even think jetbrains products have it)


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.


Jetbrains merge UI is like `git mergetool --tool=meld` (which you can use with x-tunneling on servers)

Personally, I prefer vscode/atom style merging, but to each his own


> Rider is absolutely stuffed with features

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.


The IntelliJ dark theme is called Darcula. Nice pun.


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


DotPeek is a gem. I don’t need it often but when I do, I’m super glad it exists (and it’s free!)


does Rider have Edit and Continue now? That's the one selling point that keeps me on Visual Studio.


It does, and it's great!

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!


The community edition is Apache licensed, https://github.com/JetBrains/intellij-community it has no trial period, you own it forever.


You can build it from source also - I did it several years ago, easy enough.


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 love JetBrains so damn much it hurts.


If you are a student or faculty, you can use their products for free - https://www.jetbrains.com/student/


Also free for open source projects: https://www.jetbrains.com/opensource/ I've applied and got one in the past. Can recommend!


You can also just search for their EAP programs and get them for free that way too.


This is a great tip! I had no idea. Free beta (alpha?) builds:

https://www.jetbrains.com/resources/eap/


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

  cmake_minimum_required(VERSION 3.0)
  project(prog)

  include_directories(.)
  file(GLOB_RECURSE sources *.h *.cpp *.c *.hpp)

  add_executable(prog main.c)

variables might have to be tweaked a bit.


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 also tried their CLion and was somewhat disappointed. Slow in places, sometime stalls, bugs here and there. Ended up using CodeLite and Qt designer


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.


If you haven't tried it recently, I'd give it another try. They've had significant speed improvements with 2019.3, whereas 2019.2 was very slow


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.


An editor that needs (even) 2GB to be blindingly fast is a failure.


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.


That's fine, because it's an IDE and a new dev machine tends to have more than 16gb of 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


Some machines, and some people, have other uses for RAM than the text editor.


Sorry but I have other uses for RAM then to feed sloppy environments.


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.


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.


Any place which has internal tooling tightly coupled to Eclipse, and isn't willing to or has not gotten to develop the same for IntelliJ.


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.


It happens also in own projects that are just huge, without any 3rd party libs.


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.


this sounds like a good candidate for issue report. Would you mind collecting performance snapshot and sending it to JetBrains?


Because of Eclipse RCP or EMF legacy?


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 would turn such a role down - not because they use Eclipse, but they are a single IDE 'shop'.

The development process should not be tied to the IDE!


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.


Man why you gotta do Firefox dirty like that?

Firefox is absolutely the best browser IMO. Unlike Eclipse, which is acceptable but doesn’t hold a candle to JetBrains.


> Unlike Eclipse, which is acceptable

That's a nice way of saying it's a trash fire.


What happened to Eclipse?

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.


Really? Is it that bad? I haven’t tried it in a long time but I imagined that if I opened it up it would be pretty good. Got to try it now.


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.


Funny, the two things you mention (instantaneous compiling and error checking) are still better in Eclipse.


Eclipse is gimp Jetbrains is photoshop.


Photoshop is much less free/open than Jetbrains products are.


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.


IDEA CE is opensource, many plugins are opensource as well.


> Both are commericial products that require a licease

There are community versions of some of their IDEs, which are fully FLOSS, unlike Photoshop.


I thought Eclipse was pretty good... obviously not a 1-to-1 comparison...


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.


Let me blow your mind: ideaVim[1] is an official extension that enables vim like behaviour inside JetBrain editors - you can have best of both worlds!

[1] - https://github.com/JetBrains/ideavim


I think IntelliJ is an exceptionally good software.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: