JetBrains: $270M revenue, 405K paying users, $0 raised
twitter.com
twitter.com
Their FAQ page explains it a lot better than I can: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
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.
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").
I wonder how big is that part of the revenue.
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.
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.
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.
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).
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
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.
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.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.
"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.
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.
Have you tried Xero? I haven’t, but if you have, I’d be curious to hear your take on it.
(obdisclaimer: I worked for Adobe several years ago, but have no current stake other than being on the CC photography plan)
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.
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.
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.
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.
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.
I work in a very large monorepo, so it's not like I'm working in a git tree that isn't complicated.
'for a new person, it's almost impossible to get anything done with a table saw'
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 nearly spat out my drink. Git is many things but those aren't the first two words that would leap into my head.
Which is exactly why people want better clients than the official git cli client.
What is complex is the hundred features and commands it provides on top of that model.
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.
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!
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).
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.
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.)
...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.
So a graphical interface then? I'm sure you can see why using a GUI for other functions is just as useful.
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
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.
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 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 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.
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.
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 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.
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.
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.
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.
Not subscription based!
Somehow I hesitate to pay subscription based models, although I understand why this model exists.
I'm not an emacs user but always install it (via spacemacs) everywhere solely to host Magit.
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.
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.)
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.
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.
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.
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.
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.
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.
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...
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.
If your company won’t pay for it you can buy a personal subscription cheaply.
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.
> 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.
>... 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.
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.
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.
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?
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 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.
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.
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.
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.
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.
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.
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.
Eclipse workspace = IntelliJ project
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.
Try creating an empty project in IntelliJ and then add each of your Eclipse projects as a module to the IntelliJ empty project.
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.
This does not match my experience at all, fwiw. I keep all manner of projects open simultaneously.
I guess that pushed them to improve ;)
As I said in a parent, I'm very certain the competition from IntelliJ got them off their asses :).
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.
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.
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.
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).
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.
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.
Their products are/were ambitious in an MVP environment.
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.
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.
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.
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.
There are a LOT of great engineers in places other than SV, Austin, Boston, etc.
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.
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 liked JBuilder, but VisualCafe was a nightmare. But IntelliJ was much more responsive and much cheaper.
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!
A while back JetBrains made Rider more themable (prior to that update, you could only really theme the editor, not the file explorer etc). After that update, it looks great with a dark theme enabled!
I'm on mobile now, but if I remember later I'll mention the name of the theme I'm using - it's pretty close to VS's dark theme.
That's 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.
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.
Personally, I prefer vscode/atom style merging, but to each his own
I always found the Edit and Continue function in Visual Studio to be flakey: often it would say it wasn't "allowed" with the type of project I was using, or it took minutes to apply changes when it did work, or it crashed while applying changes... Rider got Edit and Continue 1-2 years ago (I think), and it's been completely reliable in that time!
This 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.
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.
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.
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.
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.
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.
cmake_minimum_required(VERSION 3.0)
project(prog)
include_directories(.)
file(GLOB_RECURSE sources *.h *.cpp *.c *.hpp)
add_executable(prog main.c)
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).
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.
Firefox is absolutely the best browser IMO. Unlike Eclipse, which is acceptable but doesn’t hold a candle to JetBrains.
That's a nice way of saying it's a trash fire.
There are community versions of some of their IDEs, which are fully FLOSS, unlike Photoshop.
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.
Also if you transpile all your js into a big minified file, exclude that too, right click on it and there must be an option as mark as plain text.
The development process should not be tied to the IDE!
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.
Most things can be solved with plugins though.
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.
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).
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.
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.)
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.
It would be useful to say what these 5 things 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.
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 )
Been paying for Intellij for nearly a year now and I don't regret a day of it. Well okay, I do regret the one day EAP was totally broken by the VIM plugin, by besides that it has been brilliant.
Its not perfect but its good enough for moving around and copy/paste.
I occationally go back to emacs to macro some data into different formats.
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?
Stock vim is mouseless, and without arrow-keys, which means relying on /? (searching) or other keys to achieve the function of arriving at text. CTRL-F never quite matches that (after you hit enter, the CTRL-F dialog is still open, and needs to be closed with ESC or by clicking away), and moving to the arrow keys/pgup/pgdown/mouse is slow.
Having said that - there are some plugins that match this behaviour - I particularly like the ones where a key (f in vimium) highlights each word with a character, allowing for one or two keypresses to jump anywhere on the screen.
The part about moving the cursor. Vim users typically don't move the cursor with the mouse but rather with the keyboard. Having to move your hands off the keyboard to reach for the mouse then back is the part that starts to feel sluggish if you get used to not doing it.
In a modern IDE you have a multitude of shortcuts and a mouse, and they complement each other.
Longtime vim users who didn't know how to use vim? That's... interesting.
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.
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.
For example: say I jump to this function and want to fix a bug (the `search` should strip off the first two characters here, not just one). So I need to change `regex.search(s[1:], ...)` to `regex.search(s[2:], ...)`:
def compile_hg_glob(line):
pat = glob_to_re(line)
# Mercurial ignore globs are quasi-rooted at directory boundaries or the
# beginning of the pattern.
pat = '(^|/)' + pat
# Mercurial globs also have to match to the end of the pattern.
pat = pat + '$'
try:
regex = re.compile(pat)
return lambda s: regex.search(s[1:] if s.startswith('./') else s)
except:
warn("could not parse hgignore pattern '%s'" % line)
return lambda s: True
Or suppose I'm looking at this and want to add a `,` character to the end of each of the type entries, because I forgot Python likes its commas:
result = result | {
'a': TYPES_ALL
'e': TYPES_FILE_REAL
'x': TYPES_FILE_SYMLINK
'c': TYPES_DIR_REAL
'y': TYPES_DIR_SYMLINK
'f': TYPES_FILE
'd': TYPES_DIR
'r': TYPES_REAL
's': TYPES_SYMLINK
}[c.lower()]
These kinds of things happen constantly, and when you've got Vim burned into your fingers trying to edit text without it (actually edit text, not just jumping to something) feels like typing with oven mitts on.
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.
Obviously the first part is language-neutral, and is exactly why I think multiple cursors is one of the greatest inventions in text editing! :)
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 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.
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).
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 :)
<c-v>8j$A,<esc>
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.
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.
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.
- Go-to-definition is `g d` (with the cursor over the function name in question)
- Project-wide file search is `SPC SPC`
- Jumping to a function is `SPC s i` and then just start typing to fuzzy-match the function name
I stick with this setup because it does pretty much everything I could want from IDEA, and does it without churning up most of the resources on my machine. And trust me, I've tried to switch to IDEA, but it's just too big and too slow, and too poor of an editor for me to actually make the switch.
The one related function that I would miss is using vimgrep and the QuickFix list to get a list of the locations where the function name appears which I can use e.g. to do a search and replace in those files (or a subset of them)
What if I told you I read way more code than I edit?
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.
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
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.
The complexity is usually overstated and a sunk cost besides.
- 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 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".
No apologies, no compensation for building a commercial product on something I had spent a decent amount of time on. Very disappointing of them.
EDIT: it was clearer than I thought - v0.4 [1] has an explicit GPL 2.0 COPYING.txt in the root.
[1] https://sourceforge.net/projects/nprof/files/OldFiles/nprof-...
For anything that had no license spelled out, they had and have no license to use it at all.
To be clear: they appear to have no license to distribute your code today, and owe you damages for all the distribution they have done thus far that was not licensed.
If you're at all interested in doing anything about it, copyleft.org has a bunch of useful resources.
I think the important question here is did they do this in violation of the open source license you had adopted as at the time the alleged infraction took place?
Think about it this way: When Linus started working on Linux and decided to release it under the GPL, was it because he wanted companies to use it as the basis of billion-dollar revenues without sponsoring development or compensating him for his work? Lots of people start contributing to open source at a smaller scale, where it's just individuals and small businesses and non-profit orgs sharing with each other, but it becomes kind of a different matter when a company has dozens or hundreds of millions to throw around and doesn't share back. At least in the case of Linux it is well-funded now but there are other cases where core infra has still suffered - you can find recent stories about how the maintainer of NTP struggled to pay rent even though massive companies rely on it.
I chose to approach this with an economic lens, hence the question of whether the original license was permissive, which is the green-light that allows all commercial exploitations to not appear illegal in the eyes of the law.
Open source is one of those activities where developers, who are no less human than non-developers, interleave social norms with market norms.
As far as humans go, social & market/economic norms don’t mix very well [0], so an unfortunate side effect of a lot of open source projects is that our expectations as humans get routinely violated due to the unnatural mix, as your example of the open source NTP developer in near penury clearly illustrates.
[0] https://www.aglobalreach.com/wp-content/uploads/2015/04/Soci...
In my case I built and maintained my software for 3 years and when I chose my license I knew the license meant that someone could repackage it and sell it. That was a decision I made, and maybe my decision was wrong, but in the end the economic factors meant I could no longer pay rent by doing it anymore, so I stopped. Those actors lost the foundation of their product as a result, so the economic factors didn't end up working out in their favor either.
I could perhaps have prevented their actions by using the GPL, but it wouldn't have suddenly made them pay me - they would have just lifted someone else's inferior permissively-licensed solution, because there were multiple options and mine was just the best. I did previously have corporate sponsorship, but that never lasts forever.
If you want money then ask for it. Offer a product or service. There are dozens of licenses to choose from.
At the time, we had a student working on the project and they used a couple of classes from NProf code for loading the profiler under IIS. This was done incorrectly as it was not in compliance with the GPL license. This was brought to our attention on March 18th 2005, and after careful examination we responded on March 21st 2005, following up by removing said code and rewriting it. We indicated this resolution to you and you were satisfied and showed support for JetBrains. We do have reference to the aforementioned interchange between yourself and JetBrains. Should you require a copy, please let us know. We'd like to apologise for this mishap which was a complete oversight, and was remedied as soon as it was brought to our attention.
Feel free to reach me out if you have any further questions
Apologies on my end for mis-remembering that I already received an apology from the VP of product development at the time.
That would be great - I no longer have the email in question as I lost access to that account and virtually all email records from the early 2000s (mmastrac@canada.com, I'm assuming). If you could forward that to matthew@mastracci.com I can have that for my records so I don't forget the details again.
- The best IDEs by far. There is nothing remotely close. I have been a dedicated Emacs user for over 30 years. But there is so much Intellij does that just isn't available in Emacs, that I started moving more of my dev work to IDE, maybe 10 years ago. I still escape to Emacs sometimes (from the IDE), but if I'm coding in Java, Python, or sometimes C/C++, JetBrains tools are my main environment.
- The products keep getting better with every release.
- Excellent support. They are always fast and address my exact problem.
- Reasonable licensing.
- The free versions of their products are usable. I got by on free versions for years.
I am thankful that they remain independent. I fear than an acquisition would dilute their focus and kill their many-years long streak of stellar accomplishment.
Just to add one to that list of awesomeness.
With these numbers, this confirms that 'developers' are the new customers.
It's very easy to look at JetBrains and say it can obviously work, just the same way people look at RedHat (or other outliers) and say it can work. They're a standout company in this space, and have high reputation, and it didn't come from nowhere. They almost make it look easy -- just sell a great product, boom! But it depends on a lot of factors like when they entered the market, how they grew over time, etc. It's possible they wouldn't be able to get off the ground today if they tried this whole thing again.
In fact I wouldn't be surprised if JetBrains existence, happening before the whole VC craze, has in fact influenced the market itself, today: even with millions of dollars of VC funny money, it would probably be very difficult to compete with them on their turf in 2019, when they have extremely high reputation and a big array of products, in a market that is a very "small world". They're the 900lb gorilla in the room, in a sense, but they did it on their own.
JetBrains products are amazing though, without a doubt, and they deserve their success. I wish them all the best.
I think that's unkind. The product they had when they started (IDEA) was so much better than the competition, that it felt like magic. Yes, they rode the Java wave, but there have been other waves since then (Ruby, Python...) and nobody really managed to replicate for those markets the same experience of productivity jump that JetBrains managed back then.
Meanwhile, JetBrains have done it again with PyCharm, which is the Python IDE and has been consistently ahead of the competition literally from day 1. They entered a market where others had been for more than a decade, and ran away with it. That's just skill, not timing. By the time Python exploded in popularity, they were the obvious choice already. The fact that they can even field competitive products in the Microsoft space, where the gold-standard of IDEs has existed for 25+ years, is testament to their talent.
They've also legitimized a subscription-based approach to software-development tools, which will make it much easier for anyone to compete with them. A "new JetBrains" would find it much easier to develop an IDE today and get paid for it, which wasn't the case 20 years ago. The problem is really that very few people seem to think they can deliver a jump in developer productivity of the sort we've seen with IDEA back then.
Edit: I'm learning in the comments below that IntelliJ IDEA Ultimate gives you the capabilities of the other products all together. This sounds great! I'm going to try it.
Multiple "sources-roots", multiple-projects in the same workspace. Also, you can install pip install external libs in source development mode and debug them, etc. Short of "project imports" that I miss from Eclipse, I'm not sure what you may be referring to.
That's not really true. The experience you get from, e.g. PyCharm and GoLand is substantially better than what you get from IDEA + Python plugin or IDEA + Go plugin. Yes, the plugin will get you 85% of the way there, but it will feel more clumsy and hacky than just using the dedicated product.
Please specify the differences as I am seeing none.
I used to use IntelliJ Ultimate, and had to wait a while before getting new features announced for PhpStorm, for example.
I now just use PhpStorm for PHP and GoLand for Go, instead of attempting to use IntelliJ for all languages. I spend less time configuring IntelliJ for each language and get updates on release day.
JetBrains has an "everything" licence that I was able to migrate to from IntelliJ Ultimate.
I have used IDEA and PyCharm for enough time to say there’s 0 difference between the two.
There are indeed plenty of features that are specific to each IDE/Language that aren't in the IDEA-equivalent plugins.
If you find that WebStorm works better, you probably need to install the node.js plugin in PyCharm (which is free). It's included by default in WebStorm but not in PyCharm.
That's IntelliJ IDEA.
Though it seems completely unnecessary, PyCharm (non-CE) should contain all the features of WebStorm (sometimes with a bit of lag).
I wish they had a way of building an IDE in a completely modular way. Then again, maybe it would end up as bad as Eclipse...
Pycharm professional should have all the features of webstorm in it. The thing with IDEA is that the ecosystem is too huge and it assumes JVM centered development.
I can spend hours customizing the controls and UI but I still feel like someone handed me the keys to some old car made in a country that doesn't exist anymore.
This in part revealed to me the cost associated with all the editor customizations I make. Default settings are nice that way.
live edit someone else's project on your computer with your editor/keybindings/etc.
or you could switch to vscode for the times when you want/need to assist them.
i’m like 60% sure that this is why nixOS was born at all: some very dedicated emacs or vim user got so fed up with moving configs around that they built an entire package manager/distro/thing to solve their config issue for all time.
That's actually something that's a major hole for me; it would be like twice as useful if it did. But yeah, my solution is just: https://github.com/zenhack/vim-config
[1] https://github.com/VSCodeVim/Vim/commit/3158194561fa2fba921b...
in fact i'd extend that to bash as well. i only use very minimal configuration these days.
How did you become unable to do basic text editing without a specific editor setup? Why do people become so dependent on tools?
In the car shop world, impact wrenches are primarily used for the installation and removal of wheels on vehicles.
The impact wrench I started with had a single internal hammer- the thing that makes a click noise and applies torque. After a while of using it, I could hear when the wheel was seated correctly, and when it wasn't.
Later, that tool broke, and got replaced with a dual-hammer one- and all of a sudden, I couldn't hear-- feel-- when wheels were on right, and it took me a few vehicles to adjust to the new noise, weight, and feel of the tool. I got used to the new one eventually, but I still liked the noises that the original wrench made more.
Before I adjusted, I was unable to perform that part my job correctly because I didn't know exactly how to use the new thing that was identical in use-case to the old one.
My CAD program of choice doesn't have many keybinds stock- and so I've bound my own shortcuts to different things buried under various menus. I also have a Logitech G502, which has buttons on the sides of it, that I've also bound to some of the more-used, harder-to-get-to functions. It's much easier to open up the parameters table- which I use heavily to tweak designs I make. It's the way I like to do things, and that one bind on the side of my mouse saves me from rooting through menus all the time trying to find the same thing over and over again. I set up that bind almost two years ago, and I've been using it ever since.
When I got a new laptop recently, I had a hard time doing CAD until after I ported over all my keybinds and stuff.
Now to answer your question- because those of us who use powerful tools to build custom stuff also like to customize the tools we have for the task at hand. A developer who's used to their setup that they live with every day will undoubtedly have a hard time using the factory settings, and an even harder time working with someone else's bindings.
Why do people become so dependent on tools? Because we mold them to suit our desires, and they become an extension of who we are, and what we can do.
Relevant XKCD- https://xkcd.com/1205
It's not like the difference in input speed is really meaningful; as you'll see someone point out in any discussion about this stuff, the bottleneck in programming is thinking.
But what I find will often happen is:
1. I settle on a course of action. 2. I go to actually do it. 3. The editor doesn't do what I expect, because it's not vim. 4. I am momentarily confused, and have to think for a minute about how to do what I want. 5. I lose my train of thought entirely. 6. Rinse, repeat.
So for me it's not so much about any specific thing the editor does to make me productive. I do have opinions about some things, but what's important is that it just fades into the background and lets me think about the problem I'm trying to solve.
Beyond just being "different," I tend to eschew IDEs for much the same reason -- while many of the advanced features seem useful, I find them too distracting to be worth the trouble. Just me and the code, please.
Or think of it another way, why are you only able to work in optimal environments, and is that the real benefit you provide? Are you going to get laid off if you aren't fully optimal? If you switched keyboard layouts would you lose this speed too? Can you afford to make ANY changes at all if this is your criteria?
After having to code about 80 java file application on a data center pull out crappy laptop screen with a jacket with just notepad and javac over a few days I just use the defaults on everything or settings that are one change away (like eclipse mode in intellij which is a meta setting like vim mode). Other than that I just adapt and never customize. This lets me use other people's computers easily, use many different OSes (I write software that enables the rest of my company so I write for what they use on what they use), and editors with little issue. I can also setup a computer in about 20 minutes. I find that the majority of my time these days is deciding what we should be doing and how. The time to write the actual code is pretty minimal.
So I ask again are you optimizing for the right thing here? Unless you are constantly re-enacting the scene from Swordfish I don't think you are.
PS: I'm pretty sure that Emacs must have a multi-cursor mode somewhere :)
of course it does.
in action: https://www.youtube.com/watch?v=jNa3axo40qM
There isn't one loss function for all people.
You've found joy in the narrative of "I just adapt and never customize ... [I can function well in my org] with little issue". Someone with a different set of constraints and preferences won't find that narrative as enjoyable.
It's about how I enjoy coding. Its my job but I love it. It's fun. Part of what makes it so enjoyable is the ergonomics. Ask any craftsman about their tools.
I learned a while back that I had to lean into those things and just get through the awkward if you wanted to keep learning.
I thrive when learning new skills and being "uncomfortable" and out of my element.
It's probably because I'm picking at rust for fun in my personal time that I don't want to deal with the uncomfortable parts. In my own time I coast and comfortably stroll through new problem spaces rather than get to that "my brain hurts" part that's all too familiar.
If rust + intellij was a work requirement I probably would just pick it up and discover that my brain can handle perfectly, two sets of bindings the way people claim to be able to do qwerty and Dvorak interchangeably.
I think this is why I bounced off of react 4 times before sticking, too many things to learn at once. Then again I bounced off of antlr 4 times and only really got it to stick because it was a work need, and antlr is the only new tool in that chain.
Use CLion instead of IntelliJ. It has much better debugging support.
I've used both VSCode and CLion quite a bit for Rust, and I prefer CLion. It's got a much better understanding of the language.
IntelliJ also sucks for Ruby and Go compared to RubyMine and Goland. Even with the language plugins.
- Started by making refactoring plugins for IDEs. Became irritated by those IDEs. Wrote their own IDE.
- Supported various programming languages. Became irritated by those languages. Made their own programming language.
[1]: parent is talking about Kotlin: - https://en.wikipedia.org/wiki/Kotlin_(programming_language)
while I'm referring to Google supporting Kotlin on Android as a first-class ("native") language as of May 17, 2017:
- https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-...
(There might also incentive for Google to move away from anything even remotely touched by Oracle; case in point being Java, despite the open sdk for that).
I would assume so as well. It sounds negative though, but I'm quite okay with this particular one.
I think this is different from student offerings where there is some sort of lock-in. Microsoft makes sure every student can try Microsoft Windows Server and Microsoft Office and get used to how it works, but with an editor from a company that just makes editors and doesn't want to tie you into their ecosystem, I think it's fine.
It's a good idea because, at least in our company, all of the young kids who are fresh out of school use VS Code while most of the seasoned people use IntelliJ (obviously there is one senior person using VIM as required by developer stereotypes).
I was able to talk directly with the PyCharm developers to figure out a problem I was having when starting new projects. Their developers are friendly and very knowledgeable.
I have no hesitation renewing my PyCharm subscription knowing that these guys are building a great product that makes my work easier.
Jet Brains offers the best value for any commercial (i.e. non-free) dev products I've ever used. Currently an active user of Rider, ReSharper, dotPeek, dotTrace, dotMemory, IntelliJ, Android Studio, DataGrip, WebStorm and TeamCity [1] - all world class tools available at a comically cheap price with their "All Products Pack" - even cheaper with their loyalty discount.
I'm normally not fond of subscription-based products but as their product suite offers so much value I count myself as a happy multi-year subscriber that in all likelihood will remain one until I retire from programming.
[1] TeamCity has separate licensing, used to pay for but now comfortably fit within their generous (100 projects / 3 build agents) free-tier limits
I feel this goes against a lot of the guidelines: https://news.ycombinator.com/newsguidelines.html
edit: my apologies for the assumptions and most likely breaking the guidelines myself
Here's a press release on their website:
> In 2019, two eight-story towers known as Space became the new home of JetBrains in Saint Petersburg.
> The largest of our company offices is located on the bank of the Neva River, with a panoramic view looking out over the Gulf of Finland.
> IntelliJ Labs Co. Ltd. Primorsky pr., 70/1 Saint Petersburg 197374, Russia
Here is an article about their operations in Prague (in czech), from what I understand they have most of developers in St petesburgh..
https://ekonom.ihned.cz/c1-65918420-rusti-it-gerojove-na-ces...
In this case, assuming good faith would be assuming that @ordx is stating a fact that they're aware of, not trying to stir up controversy. If you were interested in finding out how they knew that, you could politely ask them what their source of information was, without implying that they have ulterior motives.
Sorry for venting dear HN community, but it's not all roses in JetBrains land.
They still manage to add new features, and fix the worst bugs, but I don't think they have everything entirely under control.
It was night and day. IntelliJ was a dream. And not just because of features; it was smoother and it had an Apple level of cohesive, thoughtful user design.
This was night and day as well !
Sadly, I feel that the experience has degraded a LOT since then.
IntelliJ did not technically get worse, the typical Android build just grew in complexity way faster than IntelliJ optimizations could follow.
Same thing with Gradle actually. It has been getting significantly faster. But if during the 6 months you spent in order to speed up gradle by 30 % the typical build complexity has increased by 50%; sadly it means that you are losing.
Sick leave does not count towards any of those, if you're sick then you don't go to work and you still get paid - as simple as that. If you get sick while on vacation those days then count as sick leave and not vacation.
Also - I would either use their cloud sync and/or VCS to back-up your customizations. It sucks switching to a new computer and losing a day re-configuring your IDE back to baseline =|
[1] https://stackoverflow.com/questions/37776684/which-intellij-...
Looks like they may have gone off the deep-end with the configuration files - I remember the ability to export to a MUCH smaller file but this was probably 4 years ago at this point.
Control+Alt+L for code lint & format makes a heck of a lot more sense than the two separate Control+K Control+J or whatever that Visual Studio demands. Same for optimize imports - Control+Alt+O(ptimize) instead of Control+K Control+I or whatever in VS.
I haven't used Eclipse in ages, but I remember those shortcuts being bad enough that I never bothered to learn them.
Switch to file by name? IntelliJ: Control+E + type name + enter. VS: Control+semicolon (??) + type name + enter (if you're lucky, or you might have to go double click it in the project pane).
Of course, this is all a matter of preference, and the bindings can be changed. Although if you prefer the "chorded" shortcuts of VS, I don't know if IntelliJ supports that :)
This seems to be just some weird preference that my brain has and since Jetbrains is such a nice company and has a sustainable funding model I'm happy to send people their way
1) Its a java app
2) Continuously running compilers/interpreters in the background
3) Running builds and tests can be bursty and its pretty good about not hanging when that happens.
I do think they have really good products, just a little ... slow.
VS 2019 is actually as fast or faster than Rider for me. But that is without Resharper, and without it, I miss way too much functionality.
That said, before I pulled the trigger and purchased a Rider license, I tried running VS without ReSharper. While it certainly was definitely faster, more responsive and used less memory, I still didn't find it as snappy as Rider. It also still had my laptop fans whining, and occasionaly became completely unresponsive.
It's a real shame - Visual Studio is without doubt an excellent IDE, but performance and reliability issues have plagued it since forever. I really wish a serious effort would be made to address these.
The vast majority of the company I'm at uses VSCode (for mostly GoLang & Typescript). So I don't want to make the case to have them pay for it. But 40hrs/w of my existance is spent in a IDE/editor and IMO its totally worth it to pay for the one I feel most productive with.
I understand why but I'm still a bit sour.
And that's how I finally tried VSCode.
Wut? The plugin is there. I installed it in IDEA without any problems just two weeks ago. Then again, I have an Ultimate subscription, I don't know if the free versions are held back.
Do I have to go through the Toolbox to get this?
Unfortunately, the last time I used IntelliiJ it came with its own JDK8. Is that still the case, I wonder?
Unless you're running close to full most of the time, I also don't think the extra disk caching more RAM allows for is generally worth it. I have a few GB free most of the time (both at home and at work) and that seems to suffice to cache whatever files I'm currently working with.
It's easy for young developers to overlook the power of intellij IDES, and to use the "sexier" vscode. But clearly for any medium to large project, learning to master intellijs are one of the highest ROI that a developer can get.
Of course, it should be mixed with ideaVim.
Not too long ago I bought a "powerful" laptop (expensive!). It still chocked frequently when running multiple vm's, docker machines and/or multiple "auto-compile watchers".
Then I tried vscode remote editing. I just run the browser & vscode in the laptop, and everything else on the desktop. It makes for a much, much nicer experience overall.
JetBrains, if this somehow gets to you: please copy vscode's remoting abilities and I'll be back. Until then... I had a great time with you.
Every single HN post about either Emacs, IntelliJ, Vim, VSCode, or Atom always gets riddled with disingenuous comments of people who liked one thing more than other things. Things they either haven't tried or had some cursory experience with them.
These tools are very individual [just like toothbrushes], for someone Emacs offers something that IntelliJ or VSCode can't, for others - nothing is better than Vim.
To truly achieve mastery, one has to try and learn them all and choose a tool that works well for the situation or the one they like (for objective and subjective reasons). Some might say: "that's a waste of time", try saying that to musicians. Go tell James Hetfield of Metallica that he shouldn't be trying all sorts of different guitars because Gibson is hands-down the best.
There's a lot of products I am either reluctant to pay for, or pay for only begrudgingly, because I feel like I have to, even though the value proposition isn't really there. JetBrains isn't like that!
I hope that Google showers JetBrains in money for this.
I have many gripes with the current state of Android Studio but it is still a fantastic product.
I switched to Emacs and that gave me enormous freedom to change things to my liking instead of just learning how to live with the way how IntelliJ people envisioned it. So one can say: switching to Emacs saved me years of waiting for the features I wanted in IntelliJ.
Sometimes brewing your own beer gives you much better satisfaction that you can't buy with any kind of money. And you can say it's 100% free beer, but it is not, when you factor your time.
It's one of the best editor experiences I've ever had though.
Their revenue might look like just $270M but the value they have added by sheer gain in developer productivity across the world will run into several billions.
The software is worth every penny, and having tried many alternatives, I'm hoping I will never have to give it up. Even if they go out of business, so long as I have a matching JRE for my OS it should be useful to me until I no longer need or can write software.
When you want to do Android and non-Android development, do you need both IDEs, or can one fully replace the other?
Increasing productivity of expensive developers is a great selling point.
EDIT: I'm quite sure I have scaled resolution but can't check.
Those that come close are not “native” either. Trading the jvm for xul/scintilla (Komodo) or fucking electron, to get worse productivity and say “it isn’t jvm” is stupid IMO.
Have you ever used PyCharm? It's head and shoulders better than any other IDE for Python out there. A slight delay whenever you restart is worth the productivity improvements it grants the rest of the time.
I doubt this is even remotely true. The JVM (and the CLR, and every modern runtime) is a very well-tuned machine that performs well.
Language services make heavy use of system resources. It's effectively compiling your code as a service whenever you need it, which is a lot.
But how much of that is specifically because of the JVM and how much is just because of what it is, cannot be compared fairly IMO, because as I said in another sub-thread, theres literally nothing that has the same level of functionality across so many languages and platforms.
From what I understand, the VC funding model is toxic for sustainable, profitable businesses that successfully sell products in some niche. VCs either want your business to have a 0.1% chance of being the next Facebook or be something that a FAANG might want to buy out, and if your business isn't one of those things, they'll make you "pivot" and turn it into one.
JetBrains is a good example of the kind of technology companies we need more of.
Esri: $1.1B revenue, 300k customers, $0 raised (2016 numbers)
Anyone else?
I always wondered how much money Microsoft generates out of their proper dev tools like Visual studio, would be interested in seeing those...
or perhaps someone can point me to some market research in this space?
Anybody else had similar experience?
Edit: not trying to rain on Jetbrains parade here, I’m genuinely happy they have a business model that works and products that sell well.
IDEA has done extra work on the "input handling subsystem" to the point where they are faster than most anything out there:
See: https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...
And: https://blog.jetbrains.com/idea/2015/08/experimental-zero-la... (which is now standard)
Anecdotally, I suffer from performance issues on a very high performance desktop when doing data science. Indexing happens frequently and takes at least 30 minutes. Notebooks and scientific mode bug out frequently, even after a fresh install and in brand new environments. Judging by YouTrack, these issues are not isolated to just my machine and workflow.
I hope they figure them out soon because JetBrains's software is otherwise exceptional.
This finds JB editors to be good for typing latency, and mirrors my experience. I keep my number of plugins to a minimum, check if disabling your plugins improves the issue.
For reference, I primarily use it on Windows, with 64GB of RAM, but also use it on MacOS with 32GB of RAM and on another Windows machine with only 16GB of RAM.
(On a 2016 15” work MBP and a 2016 13” home one)
One thing you may find useful if you have the memory is raising the max heap size a bit. The default is inadequate for very large projects IME.
I still use their products despite the slowness but many people don't make the switch because of how heavy the IDE is.
It’s so critical to use text editors for software development and extract all other functionality to separate shell tools.
If a mix of very simple vim or Emacs + grep / git grep / silver searcher + CLI tools for automatic linting, test cases, etc., isn’t efficient for you, and motivates you to bring all these things into one consolidated IDE, I urge you to consider that this is a type of bad code smell and bad workflow smell, the all-in-one IDE is not actually helping productivity but hurting it in the long run, and you should invest right away in the learning curve & barriers you perceive are blocking you from a purely shell command-line workflow that separates code management & search into isolated utilities in separate interfaces.
I do grant there are a very small number of use cases where the IDE approach is useful: helping students who are literally just starting out, helping developers with atypical accessibility constraints that can be assisted with the IDE, probably a few more.
But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development.
It’s such a shame that a whole generation of programmers are tricked into believing those things are good for them.
It reminds me of people tricked into becoming reliant on MATLAB or Jupyter notebooks, and then retroactively trying to defend those tools as productivity-enhancing when they are, from first principles, productivity destroyers.
Do you have any substantiation for that claim?
The language server protocol has been a game-changer, though. Now I'm back to 100% terminal and couldn't be happier.
I suspect this is some tribal identity thing about being a “real” programmer that I fell victim too.
The IDEs are extremely powerful and much better out of the box for working in a large code base. They allow you to navigate a lot more easily and focus on the code itself rather than constantly having to deal with your setup.
Don’t let comments like the parent scare you away from them.
It does take a long time to learn relative to plug and play solutions (especially for someone like me with decades of old habits), luckily I had a few months off from work for the transition. The investment has been well worth it, it helps if you like lisp :)
Disclaimer: I use and advocate for tools derided above: linter/test integration, embedded features like autocomplete, etc.
It’s like the difference between someone who can navigate the highway system with interstate signs & atlases alone vs someone who is unable to navigate at all without a GPS system.
Even if the GPS system experiences no downtime, they still lack skills that make the driving lower quality, like anticipating changes or adjusting for weather.
Coders heavily reliant on IDE tools simply understand the ramifications of what they are writing less well, because they haven’t invested in the mental map of the code and mistakenly believe they can safely offload many parts of that cognitive requirement to an IDE.
Worst of all, they believe that code shipped this way is somehow reinforcing evidence that the IDE was a value additive tool, which is the wrong counterfactual for comparison. You have to consider the value lost from what better solution could otherwise have been shipped for lower cost using a different set of tools.
The percentage of people that are hard to work with is higher in this group though.
And I know, what I'm talking about here. Started with a Commodore 64 in 1982, first Linux 1994. Did everything in emacs, calculated mode lines, Unix was my IDE, you name it.
I'm a very happy user of CLion and IntelliJ IDEA now. Wouldn't want to go back to the dark ages.
This seems more telling about your attitude towards this subject, and perhaps also lesser skill in assessing or understanding those productivity differences.
Honestly, programming languages, IDEs, Jupyter notebooks, etc. are all tools to help individuals solve problems using general-purpose processors. If you feel equally productive without some of those tools, that's fine, but there's nothing wrong with using those tools if they help.
If you never learned Vim to the sufficient level, you will never understand how incredibly empowering and powerful it is for navigating and editing text. And that IdeaVim is hopelessly lacking many of its features.
And if you never gotten in Emacs to the point of writing your own Emacs-lisp packages you will never learn true level of extensibility capabilities of Emacs. There's simply no other tool in existence that lets you do some borderline batshit crazy stuff.
When you don't know what you're talking about, at least have some respect for those who do. I personally used your beloved tools for about seven years (to the degree of above advanced level). I switched to Emacs (with Evil-mode), because I felt that I grew out of IntelliJ. Tell me about maturity.
int main() {
if (a < b)
if (c > d)
;
}
Vim is the javascript of text editors.
now, i'm not 100% sure on the exact behaviour, but e.g. even a cursory test in sublime shows it will highlight the start and end brackets if i'm inside the if-expression and you can "expand selection to brackets".
I honestly can’t tell if this is a spoof “ how hackernews can I make it?” comment or not. What, precisely, is bad about those things? Would there be some virtue in my knowing every method signature in the enormous code base I work on from memory?
Eclipse vim VS Code
As others said, the community edition is free and extremely capable, so I don't see a reason to complain. It's fantastic that I can use my professional job to support development that benefits free users.
I also dislike their insistence on copying the grey Adobe's UIs.
For the stuff I really rely on, I feel good knowing there's a reasonable business model behind it. The ultimate version is $500 / year or $149 / year for business and personal respectively. For a lot of use cases, it doesn't need to save you very much time to pay for itself.
You always have a "perpetual fallback license" for the version you get from your subscription.
If you don't renew, you can still keep developing on whatever version you have. You just won't get the cool new stuff.
On reflection, I think it's a fair model, and fair pricing. They even reduce the renewal price if you renew after the 1st and 2nd years (maybe even more, I don't recall exactly).
Fact is that I love JetBrains products, so I want them to stick around - I want to pay using a subscription model, because that will make it a whole lot more likely.