And in the main, JetBrains actually seem to pay attention to what customers ask for in their online feedback site.
I'm looking to get into either Go or Rust soon, and I'll definitely be using GoLand/CLion.
Am I using a different IDE? I'm dealing with bugs in their refactoring engine almost every day (at least in Python and TypeScript); I need to invalidate the cache every other week because something something is not working; it's 2020 and I still can't configure my IDE deterministically through text files (which regularly results in situations where building the project works fine for colleague X but not for me, even though we seem to have the same config, so I end up having to delete the project and create it again). And don't even get me started about CPU usage…
That's not to say that Jetbrains IDEs don't provide incredible value. They do. But I still think they leave a lot to be desired when it comes to stability.
The jetbrains tools do a pretty great job with typescript and when you use annotations in pycharm.... or anything where the types can be rigorously determined; but, obviously, it’s not perfect when the type system says “anything is fine”.
As for building the project; Python just totally sucks at reproducible builds. I don’t think pycharm can fix the entire packaging ecosystem.
So, fair... it’s not perfect; but compared to what? Have you used tools with better support, better stability? Better tooling?
It’s a pretty high bar to clear to say the editor isn’t completely perfect.
Yeah yeah, it uses Java, it eats your ram and the cpu can go crazy, sometimes you need to reset the cache or delete your entire .idea folder.
Eh.
I also wish it was better at some things, but I still love it; what’s the alternative? Visual studio? Hahaha~~~~
It's not that hard a problem. At least TypeScript is statically typed and in Python we're using type annotations everywhere. Besides, the bugs I was talking about mostly concern imports (I move file.py from A/ to B/ and PyCharm forgets to update `import A.file` to `import B.file`), and renamings (PyCharm suddenly renames some random variable deep inside dependencies like Tensorflow, too, so I end up having to re-setup my entire Python environment afterwards).
The thing is: Those auto-suggestions for imports work totally fine and code navigation via Ctrl+click works fine, too. So PyCharm does interpret the import statements correctly and I'm at a loss as to why the refactoring doesn't work then, too. Maybe auto-completion and refactoring are two completely separate systems?
...but I think it is a tricky problem.
For example Black[1] is a very carefully crafted project that does an excellent job, but it fails at refactoring files just to apply lints with “inconsistent code generated” on some projects and files; and that’s just apply limiting rules.
...but, I for whatever reason, the JetBrains refactoring for static languages (c#, Java, kotlin) does seem significantly superior.
Yes, you can[1]. It will even sync automatically with whatever git repo you store the settings in.
> regularly results in situations where building the project works fine for colleague X but not for me
This is a problem with relying on the IDE host to also be the host of your applications. Your repo should contain build settings, not your IDE.
You should switch to Docker or Pulumi or [insert declarative build tool here] -- something more deterministic and consistent across users.
> I'm dealing with bugs in their refactoring engine
As others have said, this is much more likely to be a problem with dynamic languages. I haven't done much with Python, but I've never had a TypeScript refactoring problem in 3+ years of using it as my primary language and IntelliJ as my primary IDE.
> And don't even get me started about CPU usage…
I have a much bigger issue with memory usage, but it's still not a big problem (and I think it's a memory leak in a single plugin anyway).
Also, JetBrains seems to have (correctly) assumed that dev time is much more expensive than dev hardware.
If I have someone whose slow IDE drains 1 hr of work per week and costs $75/hr, then it's only going to be a few weeks before it was more cost effective for me to upgrade her CPU than to worry about the IDE at all.
1. https://www.jetbrains.com/help/rider/Sharing_Your_IDE_Settin...
No you cannot. Note I was being very precise in my wording. While you can now export your Jetbrains IDE's config as a git repo (or zip file) of text files, you still cannot configure the IDE through text files (like in SublimeText) because 1) the text files' format is not documented anywhere and likely to change in the future without further warning and 2) Jetbrains also writes changes to the git repo automatically. I want to be in control of my config, though. (Sure, I could roll back any changes but I think that's very sub-optimal solution.)
> This is a problem with relying on the IDE host to also be the host of your applications. Your repo should contain build settings, not your IDE.
Well, yes, we do have all our build scripts etc. in our repo but that doesn't keep people (myself included) from running and debugging things from within their IDE because it's a lot more comfortable.
I noted your wording, which was not as narrow as your intention. You just said you wanted deterministic, text-based config, which JetBrains has.
I've used VS Code's text-file config, before there was a GUI for most of the config options, and I actually found it to be pretty frustrating. A good GUI is a lot better than editing text, even with the IDE helping you stay within the schema.
JetBrains IDE's probably fail the worst in that regard, I agree; but once you have a config you like, it's easy to keep it consistent.
> but that doesn't keep people (myself included) from running and debugging things from within their IDE because it's a lot more comfortable
Again, these aren't mutually exclusive. You can run/debug code in a Docker container[1][2]. The IDE experience is exactly the same (click the Debug icon or use the shortcut, set breakpoints, whatever), it's just that the VM is running your code instead of your dev environment.
1. Typescript - https://blog.entrostat.com/debugging-a-typescript-project-in...
2. Python - https://www.jetbrains.com/help/pycharm/using-docker-as-a-rem...
I've encountered the odd issue with EAP versions of Rider (to be expected of course), but the release versions have been rock solid. Coming from Visual Studio, it's been a godsend!
This last one with partial compile, and specific debug loops, it is an awesome product!
Just opened a big solution in both VS and Rider to confirm:
- VS was really laggy after opening, pinning all 8 Xeon E3 cores for 2 full minutes!
- VS memory sitting at 1.3GB, plus another 0.9GB for ReSharper
- Rider took 22 seconds to load the solution, then used a bit of CPU for 30s (but was totally responsive in that period)
- Rider memory sitting at 1.1GB
- Overall, Perf is better in Rider than VS w/Resharper
- Memory usage for a single solution might be higher than VS.
- There are scenarios where Rider may have much higher memory usage but -vastly- better performance. VS is only 32 bit, There's only so much process space it gets (2GB or 3GB, can't recall offhand) at which point it's gotta swap whether it wants to or not. Rider is 64 bit, so it will be less afraid to allocate if it makes sense on the hardware (and the JVM tuning deities.)
- You can load multiple solutions in Rider with much less penalty than you'd expect. Rider normally runs as a single Main process with Resharper/.Net/etc hosts for each open solution. This seems to give me lower memory usage than Visual Studio.
- With Akka.NET (53 projects, C# and F#) and Akka.Persistence.Linq2Db (6 projects) open, Rider sits at 1598MB nominally, goes between 1.2GB and 2GB, the Resharper subprocesses (already included in those totals) sit between 300-800MB and 60-200MB.
- Visual Studio 2019 with Resharper and Intellicode -DISABLED- shows up as 1363MB for Akka.Net, 653MB for Akka.Persistence.Linq2db, for a total of 2016MB.
Side note, Rider has been open for days with me doing all sorts of nasty things like switching between branches without unloading (Oh yeah, come for the lower memory usage, stay for the hot-reloading.) Those VS numbers were right after I opened, by comparison.
Rider bypasses all of the process limitations and syncing overhead by using the Resharper/C# logic exclusively, and is much faster and more responsive as a result.
Also VS has been slowly copying Resharper features but is still far behind. I mostly use VS today for heavy debugging where it still excels.
Absolutely money well spent.
But that's not why I stopped using JRebel, I stopped using JRebel because 10 years ago I worked on monolithic code bases that got deployed to application servers where a build and deploy cycle took 30 minutes, if I did the build with no unit tests. Even though it took constant fiddling to keep JRebel working and a hot deploy worked on maybe half the changes I made, it saved me many hours.
Now I work on microservices with embedded app servers where a build/deploy cycle is 30 seconds, no need for JRebel. Sorry sales guys!
I'm delighted that their smarts and dedication in building a high-quality, user-focused product has paid off in a big way for them.
Usually that goes away when you get them to try some of the IDEs, the experience is second to none (as far as IDEs that work extremely well out of the box go).
The amount of times I've got praised for writing neat C# code that was Resharper doing its magic :P
The dollar-a-day I spend on the Jetbrains all-products subscription more than pays for itself.
My employer pays for the ultimate license, but I will absolutely pay for it once I move on.
Also, any company that has significant presence in Russia is subject to Russian influence. These people have ways to make you do what they want if you or your close ones are inside the borders, so you'd be wise to mistrust any software that comes from here.
Most of the staff is Russian though which sort of makes it a Russian company I guess?
VS Code gets this very right. It's generally not as powerful or friendly as JetBrains products, but the far superior keyboard navigation experience gets me to attempt to switch once a month or so.
I tried to convert from VS Code to PyCharm a while back - I didn't (too familiar with VSC), but I stuck with the merge view for some time - it's absolutely amazing!
In fact for all of my use cases it performs better than IntelliJ because it isn't trying to be 200 different tools at one time. With JDK 15 and ZGC my project only uses 250mb of ram for the language server where IntelliJ pushes over 4GB.