I still don't understand where Jetbrains is going with Fleet. Is it a platform to prototype ideas for their IDEs? Is their long-term goal to replace their IDEs with Fleet? Is it just a standalone product?
So far, it seems like they're very slowly recreating their IDEs from scratch in Fleet while continuing development on the IntelliJ Platform and related IDEs, doing twice as much work for nothing.
I think Fleet's their hopeful answer to VSCode. IntelliJ is powerful, but so, so messy, with a convoluted UI from the 90s/2000s. Even the simplified one is much klunklier than VSCode, especially for everyday/every-hour tasks like NPM scripts, debugging, etc. Every essential function is hidden in tiny competing side panels triggered by some obscure icon in a different part of the screen.
I love and use Jetbrains IDEs every day, but after a decade I still only find their UIs merely tolerable. Many of my colleagues try them out for an hour or two and then jump ship back to VSCode just because the initial "wtf is going on" factor is so high =/
I'm guessing Fleet was their answer, an opportunity to develop a greenfield UI for a new generation of devs raised with UX (vs the old guard of IntelliJ users from past decades). It made sense, until AI suddenly took over everything and nobody cared what your IDE UI is like anymore.
You forgot to add "IMHO". IDEA has fantastic UI, it's fully configurable and 100% usable through pre-assigned hotkeys. For example, fuzzy search is available everywhere, in every tool window, in the database window, in search results, etc. The same key combination (ctrl+alt+arrow up/down on my instance) can be used to jump between search results, symbol usages, TODOs, linter results, and so on. They thought through and implemented countless convenient features, most of which I will not be able to remember, but do use every day purely through muscle memory.
They're also now intent on destroying them in favor of the "new" primitive UI by trying to cater to new users (who are seemingly fine with never becoming power users). The good UI is still available through a plugin, but it's obvious it will be dropped in the next few years. I'm pretty sure they will lose the old guard like me right after that.
> They're also now intent on destroying them in favor of the "new" primitive UI by trying to cater to new users (who are seemingly fine with never becoming power users).
I am a power user of my tools. It is sad when a tool gets simplified and have configurations deleted, it is like getting rid of "Advanced" option, essentially.
Genuine question, what are you missing from the old UI? I am still maybe not a “fan” of the new UI, but I’ve since gotten pretty proficient with it and I genuinely can’t think of anything that’s impeding me. I think the general information density dropped somewhat, but a lot of the old UI was noise. I don’t need a big file path taking up 60% of the top toolbar. Nor a default Jetbrains space logo just sitting there. Why do I need a disabled stop button when no task/debug job is running? The old VCS tools were quick to access but it was also just 3 arrows next to the word “GIT:”. That’s a bit clunky and hard to click isn’t it? And it’s not like I need to optimize milliseconds on “updating this branch”. It happens a lot but opening a menu is the same amount of effort while not requiring close hit targets. No matter your muscle memory, you’ll nudge 16px over every once in a while. (<shiftshift> pull <return> also being my preferred way to pull/any VCS action anyway, so the point is moot)
Maybe my one main complaint is the side panes. I still loathe the hieroglyphic buttons. I would love a return to the sensible vertical text labels… but even then I realize I never change the order of those panes, so it’s not like I’m ever unsure of which pane is which at this point.
It feels… perfectly cromulent. I don’t really care at this point, if it helps new folks use IDEA IDEs, cool. Doesn’t affect my life at all now. And that’s coming from someone that does actually use the useful features of an IDE, and has been for a long time.
I too missed the old VCS tools in the new UI. But it was 10 minutes work to get them back in the toolbar, along with a few other things I missed (and that setting syncs to my JetBrains account, so new installs get that same modification).
I get trying to be minimalist but the VCS icons are really useful because they also convey if something has not been pushed / pulled yet.
Honestly the hieroglyphic buttons are a deal breaker for me. It's just a cognitive load I can't overcome without frustration. The vertical labels were just perfect and Jetbrains actively ignores feedback on that. On a second place, not having bottom toolbars anymore is such a downgrade! I would use it to have a convenient console at hand constantly. I did use the Git buttons constantly, and now it's either hard or impossible to customize some buttons, plus they'll be hieroglyphical. And at the end, I just don't like how there's less information like where my file is located (as in, "which index.js was I looking at?"), visual separators marking button borders and tab borders are now gone, and so on.
Now, there's the classic plugin but it's got an expiration date. I also could get used to all of this, and I did, I migrated to VSCode. It has a surprising (yet hilariously complex) amount of theming options and I got the contrast to previous JB defaults. Because Jetbrains' communication has been just awful throughout this change these past couple of years, I just don't trust them anymore to not destroy my workflow on a whim, it's a portent of enshittification.
The bottom toolbar... is something I didn't consider actually. Also agree with you on that. That removed a whole layout option. (Split bottom left/right, OR open a wide bottom pane. Now all panes need to be splits.)
I despise the trend of removing text labels for icons. It's bad design, everyone knows it's bad design, Windows 11 is full of this mistake, but one company did it and I guess now everyone has to do it.
I literally did not renew last month after twelve years of paying, and longer overall, and the UI was the last straw. I installed the "classic" UI plugin, but it's like you say, I know they're going to drop it. I figured that if I have to use a UI like their new one then I can use VSCode as well, there's no real reason to stay. The real cutting edge stuff is happening over at VSCode anyway. Plus Jetbrains never made a decent VCS interface and I can always use an older version with a permanent fallback licence.
I mean, I did start the post with an "I think"... it's pretty clearly an opinion, no?
I also don't think that's some obscure hypothesis on my part. It was just the zeitgeist at the time Fleet first came out (https://developers.slashdot.org/story/21/12/04/1655249/jetbr...)... seemed obvious that it was to counter VSCode. Fleet's own homepage says "We envisioned Fleet as a coding tool with a clear minimalist design that doesn’t overwhelm and helps keep you focused."
I'm not trying to convince anyone that one look & feel is better than another, just point out that there IS a generational divide (my guess) or at least a divide (of SOME sort) between those who prefer dense UIs and those who prefer simpler ones. My younger coworkers especially seem to struggle with the full-blown IntelliJ – it's just a trend I noticed, not some deep scholarly analysis. It's part of a generational fashion trend towards more whitespace and less information density.
Jetbrains already risked quite a flame war when they launched the "simplified UI" for IntelliJ, to a very mixed love-it-or-hate-it reception. They realized they couldn't change the existing UI too much without alienating some % of their existing users. So Fleet was a way to instead make an alternative, sharing some of the same backend but with a different enough UI for those who want it.
I doubt it's ever going to replace the traditional IntelliJ UI, especially now that they're refocusing efforts on AI stuff instead of minimalist UIs.
I don't know, being uber configurable isn't necessarily what you want when you're not familiar with a tool and you don't know yet what you need to configure or faff with
I've only recently started using JetBrains, so I'm only familiar with the new UI but I distinctly feel like I don't know what I'm missing on extra functions because I'm just not aware of it existing
> I've only recently started using JetBrains, so I'm only familiar with the new UI but I distinctly feel like I don't know what I'm missing on extra functions because I'm just not aware of it existing
Don't worry, I've been using it for 10+ years and I still feel that way every day :)
VSCode can do all of that, and for most languages, VSCode's/OSS LSPs are often more performant/feature rich than whatever running inside IDea that takes tens of minutes to index a project in my computer.
Who should I take seriously now? The "power users" who claim that vim with lsp and terminal is the way, or the "power users" who claim that bloated UIs is the way?
As far as I am concerned, "power users" only really need the functionality to be there and accessible with a command palette, do away with "power users" panels and buttons please.
>VSCode's/OSS LSPs are often more performant/feature rich than whatever running inside IDea that takes tens of minutes to index a project in my computer.
Typically if this happens I notice IDEA is indexing the entire dependency tree for something like node or python. It'll have an understanding of everything but is much slower to index and typically not needed. If you exclude node_modules you'll have very fast time once again
I'm the opposite, vs code feels so clunky to me and full of crappy bolted on low and mid quality plugins. Yes it's lower barrier to entry on making things and for editing configs but the configs are opaque, hard to find. Odd for microsoft that it's more of a linux mindset than windows. It feels so janky setting up run configurations or test runs.
I think how awful making run configurations is, is the one worst aspect of VSCode. tasks.json? launch.json? I just want the "run" button to run a custom build command and I could just not figure it out.
Not to mention it hardly seems to support simply running things from package.json script section when doing JS stuff. Every time I try it seems to never quite work, or is very clunky and obtuse, sometimes requiring the creation of new files (???) to do it.
Compare that with the other main IDE I use, Visual Studio. It works great.
My only problem with jetbrains UI is that it's slow. Night and day difference using even vscode, let alone vim, sublime, helix, zed, etc. I tolerate it because the functionality it brings, but I find myself actually writing code in something faster. And I don't see fleet improving on this in a meaningful way - it's basically a competitor to vscode, which I don't use for the same reasons I won't use fleet.
There is a whole nother discussion about "progressive discovery" of functionality which I think is actually wrong although that would be a fringe view among "UX" specialists.
Jetbrains always leave so much performance on the table!!
Jetbrains IDEs go pretty fast when the JVM running them is switched over to the ZGC garbage collector, and by making sure the Metal or Vulkan renderer are being used. (And DirectX on Windows? idk?)
The difference is pretty stark. ZGC is Verygood. Everything is very responsive. This is not an “enterprisey” JVM GC that takes ages to spin up for throughput. It’s quick.
The whole IDE starts up in like 1 second on my 2018 Intel i7 laptop?, including open projects and all. It’s wild how fast IntelliJ can get – and it’s also kinda wild how much performance they leave on the table with the default options.
It’s an easy config change in the .vmoptions file.
I think on macOS the Metal GPU-accelerated UI rendering is the default these days. On Linux you need to opt in to the Vulkan equivalent. It’s still a bit unrefined but worth it even now.
Slow? Jetbrains IDEs, slow? Compared to, of all things, the LSP-reliant VS Code?
I pay for them primarily to save me from LSP, which they do for many languages, though the Elixir plugin is not by Jetbrains (but it actually predates LSP itself).
Exactly this. Every time I revisit a Jetbrains product, I uninstall it within 5 minutes. It doesn't matter how great the features are, it's just sluggish.
People can rag on Electron apps all they like, but VSCode on modern hardware is very snappy. Jetbrains is a noticeable downgrade.
There are still things like opening a menu somewhere that has a random worst case latency of ~2 seconds for me. It feels random and is frustrating, but not quite enough where I'd consider learning to use something else
interesting, what menu? Just curious if I have gotten used to it. My desktop is a 2700x and my laptop is an 8th gen i7, hardly competitive nowadays. I usually have 3-6 IDE windows open. I think sometimes resolving TS types in Webstorm can take a few seconds after some changes.
Just use Eclipse or Netbeans instead, I never liked InteliJ for Java development due to its continuous indexing, errors have to be explicilty asked for, and the ten finger combos for shortcuts.
VSCode is anyway running either Netbeans or Eclipse headless for its Java support, better use the real deal.
Yep, same here. I just uninstall because it's unusable compared to vscode/vim/emacs/zed for the same jobs. And I have a new-ish macbook pro. I always hear people say they have a different experience, but, like with so many things in life, that always seems not true when I sit next to them; then it is just them being used to sluggish misery as the normal.
Well.. I'm running it on an M3 and it can be truly slow. Not always! But opening up a package inside a multi-module Kotlin project can literally take 10 seconds. Which isn't much seeing how great of an IDE it is and how much time it saves because it is so powerful. But it's heavy alright. Every time I see new features I don't really use, I wish they would invest in trimming fat instead.
There's something really not right there. Right click the bottom right status bar area, enable memory monitor and ensure you aren't running out of RAM or something. I use IntelliJ on an old Intel MacBook with a large Kotlin project and its performance is good. I never have to wait ten seconds for something like that. It sounds like you may have some old flag that's limiting its heap size or pushing it into GC thrashing or something. Definitely look at the IDE logs and see if you can track it down.
I actually use Jetbrains products because of the performance.
Sure indexing a new project takes a while and things will be sluggish at first but once it done, it works great. And you can easily edit huge files, like seriously huge files without problems, even the search will work smoothly. Basically the Java school of performance, absolute resources hog but scales very well.
For me vscode is intolerably slow. Sure it starts up quickly but the editing experience is absolutely infuriating. I had projects that I could not work with in vscode because a few thousand lines of code in a file were already too much for it.
My main barrier to IDEA is actually performance. Despite people's complaints about electron apps, VSCode is viscerally snappier in all the little interactions. I tried to switch to IDEA for the powerful features, but it always felt like mud
I haven't tried Fleet but that could be part of it
I thought fleet would be that snappy alternative, but then, in a fit of insanity, they decided to outsource all the actual non-render logic to the IDEA engine, and the whole thing was dead on arrival for me.
Now I use Zed, which seems to be what Fleet should have been.
I feel similarly about IntelliJ IDEs as someone primarily coming from Xcode.
Xcode has its own share of weaknesses, don’t get me wrong. It’s just that I’m irritated more frequently by quirks of IntelliJ IDEs like how the sidebar palettes work in a way that they’re constantly at battle with each other and how super simple considerations like per-editor-pane back/forward/history are missing. They sometimes feel like they trip over the basics in pursuit of fancy gizmos.
I’ve been trying DataGrip for SQL stuff after Azure Data Studio (a closed source fork of VS Code) was recently deprecated.
It has all the same UI problems
I remember of their other IDEs like WebStorm. Clunky and weird looking, and that’s coming from someone that appreciates generally Windows 9x style controls and palette, JetBrains just can’t get it right.
As a side note one of the advertised features of DataGrip is its AI/LLM features which I thought was kind of cool after dealing with a terribly designed and legacy database; LLMs have really helped with refactoring.
So once I got a license for DataGrip and then opened it the AI tool was no where to be seen. I had to go read the docs page online to find out I have to install the extension myself. Weird.
The advertised AI feature is… behind another paywall with a seven day trial. Hang on, I just got DataGrip for its “included” AI support and you want to charge me for it anyway?
I’m glad I got the license for free via their OSS support, but would I have bothered if I knew one of the main features is actually a separate paid feature? Probably not.
> Many of my colleagues try them out for an hour or two and then jump ship back to VSCode just because the initial "wtf is going on" factor is so high =/
Really?
I mean, the UIs are basically the same now. I have them open side by side on my desktop right now and they're both:
- black boxes with a panel on the left of icons, then a tree of files, then a tabbed pane of open files.
- clicking on the icons on the left opens some obscure subwindow depending on you magically knowing what the icon means.
The only meaningful difference is that in vscode there's a command palette at the top where you can type in random stuff and get a list of actions, and in intellij you have to 'know' that the shortcut for that is 'press shift 3 times' instead of 'shift control p'
...but I mean, thats it; they're otherwise pretty much identical, practically.
Honestly, anyone who opens intellij and then goes back to vscode because its too different is a numpty.
Things work differently, and people don't like different things, and if they go back because it was different or the shortcuts are different, that's fair. It is disruptive.
...but, because the 'wtf is going on' factor is too high? Realllllllly? What does that even mean?
Come on. They're not that different. If clicking on 'run' on the top right instead of on the left bar is too 'wtf', you really haven't made a real effort to try using the other IDE.
(The same goes for old school intellij users who try vscode and then run away. Give it a decent shot before you walk away because it's too hard if the only hard thing is your keyboard shortcut muscle memory... vscode is pretty great)
You only really see the deep differences when you use them extensively for things like refactoring and debugging.
Please don't post flamebait. Jetbrains seem intent on dumbing down their UI as much as possible so we have to hunt through useless hamburger menus instead of just looking in pinned panels, etc.
I talked to a Jetbrains representative at a conference about this. They said Fleet was/is an experiment in the realtime collaboration tech, which really bloomed during Covid.
They said it is no longer seen as a good direction internally, so not to expect much.
That's a shame to hear, I really would love something like Fleet from them where I dont have to install the umpteenth IDE flavor, or use one of their plugins with an IDE built around something else entirely.
I've been hoping that Fleet would emerge as a true multi language IDE. I code in GoLang and Python regularly. I currently have the Python plugin in Goland which is not the professional plugin. If I want them I have to use a different IDE and switching back and forth is a pain.
Also, with a rewrite I've hoped that remote development will be less buggy than it currently is with Goland. It's laggy too and you see weird screen flashes. Sometimes certain features don't even work over remote.
I don't think they're slow at all. Takes a while to index when opening a new project, then everything is snappy.
My main reason for using JB is I loathe the shitty build your own ide experience of VSC. Everything is more difficult, whereas in JB everything just works.
Fleet has a "smart mode" that can load an intellij backend for IDE like features. But that only happens if you enable it. Thats why it can do Kotlin even though Kotlin doesn't have an official LSP.
Unfortunately they started building Fleet before Compose Multiplatform was ready, so now they support three UI technologies. Granted, Fleet uses the same rendering base as Compose (Skiko), but that's got to be a dead end ultimately.
> I still don't understand where Jetbrains is going with Fleet. Is it a platform to prototype ideas for their IDEs? Is their long-term goal to replace their IDEs with Fleet? Is it just a standalone product?
They don't necessarily need to exactly know what it is, perhaps is just Jetbrains hedging their bets.
In my opinion it seems like an experimental competitor to VS Code while also giving them a way to dog food new Java-based UI frameworks (KMP, Compose).
Anyone wondering whether JetBrains IDEs are still worth it - absolute yes from me. VS code is a UX mess by comparison. Webstorm can be tricky to configure with Typescript but once it’s setup my goodness it’s good.
Unfortunately many new developers don't believe in powerful "power" tools anymore. They like to connect many small tools for an inferior experience and they just scoff at bigger tools for being "too complicated".
I use another big tool which is around 20 years old, and that can do everything and a ton more from a single screen at the same speed or faster, with greater integration.
Yet people don't touch it because it's old, complex, looks ugly and its UI is too dense.
Oh, I forgot, it also includes a learning curve, but the same people devote their lives to "rice" their Vim installations for months.
Switching from a large, complex tool that includes a learning curve is expensive. You set a high bar for switching from Eclipse because you are used to it, paid a learning price and are productive in it. And you are right. But that also means that picking such a tool from a multitude of options should be done after careful consideration, which is exactly what using smaller tools provides.
On a somewhat related note, I want my professional software to only provide a (great) speedup of development. I want them to only do what I could do without them (even if it takes a week instead of a minute). This means I can often look at things that fail to work and understand what is failing. This is also helped by new engineers starting with smaller tools and building up to integrated, distributed tools only after knowing how individual elements work and can be connected. Integrating with a (good) big tool is then not a fight as it brings a "wow" moment -- "instead of doing all this by hand I can do it with a few mouseclicks!". My 2c.
[Talking from the perspective of Eclipse, because it's the only IDE I invested my time in]
In this case, it's not. Eclipse put Integrated into IDE, but doesn't subtract transparency in the process. You can see what it does, tweak every step meticulously if you want, and return to defaults with one click, if you prefer.
What this transparency brings is mental flexibility and understanding. Do I want or need to switch? I'm doing the same thing in Vim or KATE of BBEdit in 15 minutes. Maybe I stumble with a couple of shortcuts, but that's not a problem.
The funny thing is I see the compiler command every time I press build, so it's burned in my memory after a day. While I can read valgrind outputs and understand what it says, Eclipse highlights the lines automatically, so I'm faster. While I can gnuplot performance graphs, Eclipse auto-builds them so they are on my desktop after a 10 hour torture run.
In my case, Eclipse enables me to carry a whole toolbox and more in a single folder, yet all the tools it uses and what it does is so transparent that I can switch away on an instant if I don't get my installation with me, or I'm connecting to a server in a datacenter far, far away.
I don't like to be blindsided by my tools. I like blinkenligths in a way, and Eclipse gives me these blinkenlights while being highly automatic.
So while I understand your case, it doesn't apply to Eclipse, at least, because it's not a strangler, but a great enabler and HUD in my experience.
For the time investing part, I don't grind. I get a tool, and start using it, and when it becomes limiting, I start poking it and learn what feature solves that problem at hand. By that way, I learn the tool as I go, and if the tool can't expand to my needs at some point, it fades away from use gracefully. I don't do "stop, drop, roll" thing while changing tools, so I can't paint a timeline about when I picked a tool and dropped another.
I think the big drawback to eclipse is it's a beast to get setup correctly before it performs well. It's built to support everything, but really does a pretty poor job out of the box.
I primarily do Java development. I started with eclipse, fell away because at the time it had pretty awful maven support. Moved over to Netbeans which has pretty good maven and java support, but went through a somewhat "unsupported" period of time and ultimately I moved over to intellij.
Intellij has been a joy to work with in Java code bases because everything just works and the smart features are actually worth it. Intellij can do pretty major refactors that both netbeans and eclipse can't think of. Further, it has really good code improvement suggestions that neither eclipse nor netbeans had. I can also simply check out any code base and tell intellij to open it and be up and running immediately.
A yellow line in intellij is almost certainly something you can right click on and hit "make better" and you'll have better and easier to understand code as a result.
All that said, you sound like you are working with a C/C++ environment. I've not done a lot with Intellijs clion so I couldn't tell you how comparable it is. It wouldn't shock me to learn eclipse is better as intellij is really well built for dynamic languages, maybe not so much for statically compiled languages.
I have never written Java projects so big that used Maven in any capacity. Instead, I'm using it with C/C++ as you guessed and Python. Also XML, JS and other supported parts of the projects I write go through Eclipse if the projects themselves are beyond a certain size.
For C/C++, Eclipse has a "so-called" indexer, which indexes the whole project, does static analysis on the fly, provides great auto-complete and warns you about gotchas. Since it can read the whole project, it has a better view than a C++ LSP, and it works reasonably fast and provides great detail.
Also, Eclipse has "Linux Tools Integration", which is also a boon for C++ development on Linux.
All in all, it helped me to build a materials simulation code without any memory leaks and with great performance insights, so I can't complain. Plus, I love build and launch profiles of that thing.
In my case it is because I am wary of these tools breaking in a way which cannot be fixed, or services being suddenly revoked for external reasons.
Example: now that I'm a solopreneur I use JetBrains DataGrip, and overall I am very pleased with it. But I couldn't have it on my previous two jobs. One of the jobs restricted my work computer to only allow MySQL Workbench (arbitrary Powershell scripts also were allowed, of course), and the other one didn't want to pay for a licence, no matter how much I pleaded.
So before I had to make due with (admittedly) inferior tools because they were free and available as the lowest common denominator in the general workplace.
Being comfortable with the tools affects a large part of my productivity, and I'm more productive with a crappy-but-familiar toolbox than I am with the unknown spaceship.
All of the tools I use are free software and actively maintained and updated, plus they have very nice logging, so I can diagnose what's happening. I only needed to read the logs because I was young and experimenting with the parts I shouldn't and broke the thing on purpose. However, you can just create a copy of the installation directory to back it up completely.
Again, the tool I gave as an example has integrated configuration snapshots, and if something breaks I can revert to a config 2 seconds or 2 years before, including component versions installed at that time.
To be honest, I probably used that feature at most two times in the last 20 years.
Workplace restrictions something off-limits and I can't tell anything about. The people I gave examples are persons I know and they have no such restrictions in place.
> Unfortunately many new developers don't believe in powerful "power" tools anymore.
I have to use IntelliJ due to Kotlin codebase, but I'm still more of a fun of Emacs and I don't like Idea that much. I think IDEs somewhat lack the power that simpler tools have, which is automation.
One thing I miss from IntelliJ is programmability. That's why I still use Emacs on workplace for anything outside of Kotlin (git, grepping, note-taking etc). I even edit code in Emacs from time to time when it's easier to write a Lisp function which will batch edit code than doing keyboard macro.
Another thing I'm missing from IntelliJ is determinism. Everything is asynchronous, so the same combinations of actions can lead to different results, making automatisation painful.
IntelliJ is very programmable, but it can be a bit intimidating because out of the box it assumes that you want to program it by creating plugins. That's very different to the elisp REPL driven approach. LivePlugin bridges the gap by letting you control the IDE from a repl-like console, building up scriptlets that use the same plugin APIs. There are examples for how to do things like add menu items, explore the semantic PSI trees, trigger refactorings or do whatever else you want to do.
- Tracks the mode globally (rather than per editor), and treats mode-switching as an edit operation (so if you accidentally enter a read-only tab in insert mode then you need to switch to another tab, escape, and then go back to get your keybinds back.
- Doesn't bind escape in sidebar dialogs, so trying to exit insert mode in a terminal or commit dialog just defocuses the sidebar instead
- Still applies its other binds, so even falling back to CUA/IntelliJ keybinds doesn't work either!
- Makes no effort to integrate IntelliJ keybinds, all you get for conflicts is "would you like to lose the Vim or IntelliJ functionality that binds this key?"
The difference is stark when you compare it to something like Evil that actually values the user experience. (How's that for an irony?)
Such vim/emacs configuration aficionados are engaging in a hobby, some under the pretense that it'll make them more effective, but many simply for the fun of it.
I feel like I "earned" the right to use big ugly IDE after learning the underlying complexity the hard way, but that's only for one language.
Jumping into a new language with JetBrains is the difference between me spending 2 hours figuring out a codebase and submitting a PR, and me spending 2 hours fucking around trying to fix things.
An IDE generally adds another complexity layer, esp. if you’re not experienced in the language, that’s true. Maybe the reason I didn’t feel that was the gradual ramp up in using the IDE, and starting to play with a language in the terminal first.
I still don’t use an IDE for projects up to a certain size, but after a certain point, being able to also store all the nitty gritty bits about a project (building, profiles, environment, flags, etc.) in a project saves more time than it requires to set them up.
I have moved to VScode after being a paying Jetbrains customer for 6 years.
The Jetbrains IDEs are clunky and slow, they also have plenty of bugs which remain open for years.
They do offer some really powerful refactoring capabilities but I don’t miss them.
Most of my work is in Go, Rust and Typescript.
I was told by Jetbrains representatives that Fleet is now deprioritized internally, which is a pity.
My experience too, I found myself more and more annoyed because I'd run into something, find a years-old ticket that has never been addressed.
I really liked JetBrains tooling in the past, but that and then they also started hitting me with spammy advertising right after I paid for another year, and just couldn't stand it, refunded and cancelled.
Jetbrains has been my go-to recommendation for years.
Unfortunately they are forcing a VSCode UI on everyone and outright lying about their adoption figures (claiming it's off by default and everyone actively chose to use it). The new UI is just as much a broken mess as VSCode. The only way I can get work done is by using my fallback license for the 2023 versions.
It is apparently inconceivable to JetBrains that power users exist and pay good money for power user tools. JetBrains only cares about VSCode script kiddies anymore.
PyCharm is excellent; have not found anything as good for heavy python development
update: emphasis on "heavy". It's good for python projects. For some one-off script I'm more likely to use Zed. pyCharm indexing drives me nuts sometimes. But Zed lacks the features that I use in pyCharm for larger projects.
Their tools are fantastic and worth the $$ and having worked in the profession for 25 years I have little patience for the variety of elitism I often encounter on jobs that goes along the line of: "I just use vim and (by implication) so should you."
JetBrains has always had issues with performance and slightly clunky UI. But in return there's just a pile of amazing refactoring and analysis tools that nobody else offers.
I pay for tools that make my job easier so I can concentrate on delivering. Working without RustRover or CLion is just unpleasant.
I have an emacs + LSP + Rustic etc configuration which does about 80% of what I can do with RustRover. But it's brittle, slow, and takes work to maintain. VSCode suffers from similar problems (not slow, but brittle and ergonomics are worse).
In my first job, I used C, vi, and cscope. In my second, Java and Eclipse. I was an order of magnitude more productive with an IDE. Some of it was the language (though I was actually pretty good at C and rusty at Java), but most of it came from the rapid feedback loop and improved code discoverability.
The UX of Jetbrains IDE is objectively worse, I will take Rider as example (since I use it everyday).
We can start with basic things: the contrast, in default settings in dark mode for both. In theses conditions, Rider contrast is too low for a screen you have to stare all the day, compared to VS Code.
Commonly used item are in sub menus (in vscode they are sorted by most commonly items on top), common shortcuts requires finger gymnastics.
Unless you have more these feel not only extremely weak but extremely subjective. Please avoid trying to phrase your opinions as some fact it’s a tiring trope these days.
The fact that's the contrast is bad isn't something subjective, the font rendering is also shit and reduce the contrast further.
This is an accessibility issue, not some subjective problem.
- “default theme sucks and is bad accessibility”. On its own this is objectively provable of course except when you’re talking about probably the single most commonly changed setting in a coders primary IDE other than maybe font. Calling the app objectively bad because it chose a bad default theme that gets immediately changed is a weak take
- “hidden menu options” this is the subjective one as I called out unless you can provide examples that are universal.
- “bad keyboard shortcuts” is subjective for the most part but even still is a widely changed option and very easy to fix. So calling the app objectively bad for this is also a weak take.
You can select a simple metric, practicality, that will be objective.
The items in VS Code are sorted the chance you have to use it depending of the context. In rider, commonly used items are in submenu (rename hiding in refactoring), less commonly used items are not in the submenus.
For the keyboard shorcuts, again you can argue practicality as an objective metric. The number of keys for a combo and distance between the keys have a big practicality factor, and Jetbrains IDEs loves F-keys (that you can't reach if you hold a keyboard like ergonomists recommends)
Due to the poor font rendering and colors picked in Rider, by default there is a contrast of 4.77 which is just meet the minimum ratio, and for an app you stare all the day at, it's not enough.
From the firefox docs:
> Having good color contrast on your site benefits all your users
I suggest you to read some research on UX so you can understand that a big part of UX is in fact, not subjective.
Like poor contrast cause reading fatigue on all humans, but at varying level.
And that researchers determined a contrast ratio at which a certain percentage of the population can read without problems.
And yes that's a recommendation because they can't force you to do it, so they recommand you to do it.
That's not the question. The question was "you can change the toolbars and shortcuts in JetBrains Rider, no?"
I presume the answer is yes, from what you said. Then it becomes less of an issue, if not an non-issue.
IDEs and code editors are tools which we live with for a long time. Nobody expects their defaults to be unchanged. Otherwise we'd be all using notepad.exe for coding.
Not having the defaults organized by your tastes is not a valid reason for disqualifying a tool out of the gate.
As a counter example, Electron's font rendering is nothing to drool over, from my perspective, and doesn't give an extra point for using it in my case.
An IDE's literal whole selling point is supposedly being a packaged product that you can just pick up and run with, at the price of not being particularly good at any of the things it does (and usually being pretty expensive).
If you still need to customize everything then, well, what did you actually gain over assembling your environment by yourself from actually competent pieces?
I don’t think so, because the IDE doesn’t carry the language tooling with it, but interfaces with the tooling you already have in place.
That said, every IDE is opinionated about workflows, and if you’re open to adapt to that, the defaults makes sense. Otherwise you slowly hammer it to the shape you want.
For me an IDEs greatest selling point or the infinite flexibility it provides.
The OC point was that VS Code UX "is a mess by comparison", and VS Code UX is fully configurable, therefor if you have a problem with VS Code UX, you are complaining about it's defaults settings.
Also Jetbrains IDEs font rendering is simply awful, it doesn't hold the comparison to electron: https://i.imgur.com/u4ZV2Kd.png
I'll quote an earlier comment of mine written a couple of months ago (with links to the issue tracker)[0], because - after many years of being a happy JetBrains user - I sadly can no longer recommend the IDEs (some worse than others, Rider has been okay, though new features often just don't work at all), since the quality of QA has gotten very bad over the last couple of years:
- The autocomplete popup sometimes froze the IDE completely (and killing the process caused minutes of data loss), open for close to a year
- Since two months ago, the Typescript language server fails to start in Vue projects (due to a broken update by the Vue team). A fixed version of WebStorm was released yesterday, in the meantime you were apparently expected to search for the error message, stumble upon the YouTrack page, and apply a workaround
- Performance is abysmal in a larger React MUI project, think 10-15 seconds for feedback on code changes, sometimes errors just stick around for a good minute or more, or even stay until you manually remove all code and put it back
- In some situations WebStorm makes autocomplete suggestions that aren't allowed - think effectively a type T with keys K | L, where Omit<T, K> leads to only suggesting K properties, while removing the Omit makes it suggest both K and L properties
- After updating from 2024.1.X to 2024.2.Y, the window had no buttons for minimizing/maximizing anymore. Now, this was partially caused by my environment, but after I found a workaround it was closed as "Third Party Problem". Still feels like a regression to me, since my environment did not change.
I've mostly stopped updating the IDE, as almost every version brings new regressions in basic editor features. This morning I updated and tried to copy some text. WebStorm showed me a "Copying..." dialogue for more than 30 seconds.
I just tried Cursor, which is based on vscode. And I couldn't stand it, back to JetBrains in a week. Everything, just everything is inferior. Starting with Git plugins, search etc. So yes, learn the ide, just use JetBrains.
I use both VS Code and PyCharm for Python development. I spend the majority of the time in VS Code, but I’ll jump over to PyCharm when I need to do certain refactorings or code navigation (e.g. implement the methods of an abstract base class, find all methods overriding this method, etc), since PyCharm has much better support for that. Microsoft’s approach seems to be “GitHub Copilot can do it”, but while there are some things Copilot can do that PyCharm can’t, there are other things where PyCharm does it much more quickly or reliably than Copilot does
Yes. Absolutely. But with one caveat: JetBrains is clearly lagging behind in AI features and none of the 30+ LLM plugins come close to the killer feature of Codeium's Windsurf (Cascade). For this reason, I've been using both Windsurf and JetBrains in concert which is a pain but works for now.
I have high hopes for "Junie" but fear it's going to be a while before it's ready for prime time.
Agreed. VScode is fine for me as a markdown editor/log viewer/advanced text editor, but when its time to develop, I can't imagine doing without the IDEA Ultimate productivity boost.
One thing I’ve always liked specifically about Jetbrains is that I think their IDE’s use the best visualization for merge conflict resolution. I don’t use Jetbrains much lately due to my current line of work, but I still find myself reaching for the IDE to resolve particularly hairy merge conflicts
Phpstorm ran out of chances I'll give it. Last three tries all went the same way, permanently stuck indexing a project and being an overdeveloped notepad.exe during that; when vscode and phpintelphense could go from cold boot to code assist in seconds on the same project.
Contrary to that, I used Jetbrains IDEs for a decade, or even longer, and recently I have switched to VS Code for my Go and TypeScript work. Sometimes less is more.
I've been long user of JetBrains' products - and love them. I even use ReSharper in Visual Studio (which I still consider better IDE, but for Linux / Mac - JetBrains is my choice, and heck, sometimes even Rider/CLion/RustRover/GoLand on Windows too - especcially GoLand).
But... but... I've always wanted (and willing to pay) a single IDE with any plugin that works in it - not just so many different versions...
I'm a multiple programming language user - mostly C++, but also Python, Go, Rust, C#, etc.
That doesn't work and is a major problem for me. I have a Java project with C++ native code. Using a devcontainer so the C++ dependencies are installed seems like the right thing to do... Unfortunately, I need to use Idea for the devcontainer and can't use both it and clion. Separating it to two projects defeats the purpose as the Java code depends on the C++ code which will be in a different container.
VSCode supports multiple languages in one container just fine. My hacky solution is to use a hybrid container with IntelliJ for the Java code and then connect VSCode to it for doing C++. That means I will be forfeiting my CLion license. I contacted their support (which is reasonably responsive), they say they're working on a solution but I don't know when it will be practical for me.
Thanks!!! I also saw your other post about C# - maybe one day JetBrains would change their mind!
I'm trying latest IDEA (2025.1 EAP) and for the first time a bazel project that I have got parsed successfully (had to enable some old legacy flag though), so there is hope!
Over the years I've tried both the google plugin, and now the BSP one.
Mixed results. Almost always works on Linux/OSX, but my dominant platform is Windows.
Yesterday tried it again (BSP one) with IDEA 21.5 EAP with nightly on the plugins, and things got synced, but was not able to find any targets (they are C++ targets), funny it found and listed a "filegroup"
But I have my hopes up, the BSP looks like it's doing the right thing discovering much faster the targets, and probably needs more work just to finish all edge cases (like mine - Windows).
IntelliJ has supported this for over a decade also, and having used Eclipse for PHP a decade ago, I think it's very generous to say that that was actually supporting non-Java languages as an IDE, rather than just a very slow and heavyweight text editor. I'd say Eclipse's weakness for Python, PHP, etc. at that time led to how long IDE-skepticism has been a thing.
I would happily pay through the nose for their language and refactoring features as some sort of LSP or plugin for other editors.
I use their products because that aspect is best-in-class for many languages, but the actual applications themselves leave a lot of be desired. Core text editing is pretty good, but so many Byzantine nested menus and odd Java fully-modal locks-out-the-background dialogs.
Was just going to post that yeah, ALL the JetBrains IDEs have a "Command Palette" with fuzzy search for all actions. I can't remember the last time I even went through the menu bar.
Back in the day I wrote a significant part of the first version of PyCharm. A part of he job was also making the same language-supporting code available as a plugin, and virtual feature parity between PyCharm standalone and the Python plugin inside IDEA (the paid version) was a requirement.
Maybe things changed after the 15 years that have passed since, but I don't see why would they.
They can't build the mothership, that means they only have one product. The problem I have is that they build these editors to their benefit, not mine. I had the same problem despite liking the tools initially. Between nvchad and vscode, I have all my bases covered for any situation/language.
>With Fleet you can collaborate on code in real time
Genuine question - Does anyone actually do this? What for?
I have been writing code for about 25 years and not once did I wish for someone else to start editing the same files I’m editing in real time. Yet, this seems like a huge selling point for some of these editors.
You've never been on one computer with another developer and eventually just hand them the keyboard? (or Vice-Versa) Or on a work call sharing your screen, where you give them remote control of your screen? (or vice-versa) This is a way to let someone else collaborate with you, within their configured IDE, with their preferred plugins and tooling configuration.
If you don't do any peer programming, then you wouldn't understand it.
I've been working for the same company for over 7 years and a lot of the shared code that other developers use is mine.
Frequently I would guide other developers to implementing something and in doing so I'd guide them down to what files to open and how to integrate it. I find this process a lot more convenient over Zoom where I can annotate with a pencil. I use that to underline blocks of code. It's a bit like you have a mouse and I have a mouse on the same screen but in a nice way.
In a workflow like that I sometimes want to write pseudo code and I would very much welcome a feature like that. Currently JetBrains has a "Code with me" plugin or something similar, but it's a bit laggy and struggles when fast typers meet. And a feature like that is good both when I take my laptop and sit next to you, and when we're on Zoom while talking.
It's helpful for mentoring or pair programming with another person. They can more clearly see the code as you change it, like Google Docs, rather than just watching a screenshare.
It was an experiment at one company I had for maybe 6 mo and failed miserably. Also a coder here for ~20 years. Code was slightly less error prone and slightly more predictable in LOE but productivity dropped massively. Most importantly all the developers hated it.
Same. I've only used collaborative tools like Google Docs with other people exactly once in college for a group report. Naturally we procrastinated so long that we were knocking it out the day it was due. I must say it did a good job adding momentum.
Other than that never in my professional experience as a programmer. Except for open source work I was helping with. 3 of us would meet on Jitsi main contributor would sometimes share an SSH session with us in addition to streaming live coding sessions. Don't recall it actually being useful though. Dunno. It's probably one of those features that if it works well and is easy, then I might use it more.
I've used it a total of 2 times since I first saw the ability in Atom back in 2017. Once was more for the "this seems neat, let's try it" factor. The other was a legitimate, let's troubleshoot an issue while staring at the same massive screen together. It's not a bad feature, it just never stuck with my workflow - I typically hop on a Zoom call now days, someone shares their screen and pair program the old fashioned way (by yelling out stuff like one does when someone else is playing solitaire)
I personally find value in having two editors. A light editor like Emacs for writing Markdown, git, quick scripts, and a JetBrains IDE for longer running projects, and debugging. I don't feel the need to wholly replace one with the other
Fleet was a strategy to counter vs code. As such it did not work that well. It's not feature complete enough to consider as an intellij alternative and a bit too different for vs code users to take serious. So, easy to see why they are pulling the plug on that.
Vs Code of course is the wider ecosystem of plugin compatible editors based on the vs codium platform. This includes a lot of the recent AI editors, and several non vs codium based editors that can integrate the plugins (e.g. vi).
The core issue is that Fleet is outside of that ecosystem and doesn't have the community or user adoption to get that fixed. It's a chicken egg problem that's hard to fix. It's being pulled two directions. On one hand you have existing intellij users who use that to do most of their development. And on the other hand you have people that are using vs code and depend on a lot of its plugins. Fleet is a bit of an empty room for both groups of users. None of my more serious projects load correctly in fleet. I've tried it a few times and it's just missing too much stuff for me to take it seriously. And I bet VS Code users would be equally unhappy.
Fixing that would involve bringing over the majority of features from intellij and vs code, and recreating those in fleet. Which of course wasn't really happening given that it's being positioned as a closed source platform.
IMHO keeping Fleet closed source was the mistake that doomed the whole effort from day 1. In short, they were on their own and not really able to pull that off. Google is understandably focusing on supporting intellij, which at least has an open source core. Providing an open source core for intellij in 2009 was the key enabler that allowed them to move from eclipse to intellij. Google embraded it in 2013. Some of the older people here might remember that Android Studio started out on the Eclipse platform. Eclipse support ended in 2015. Open source is what made that transition possible.
Which of course raises the question what the whole point of a closed source Fleet was given that users, plugin developers, and major partners like Google are all focus on the open source ecosystem around intellij. And the rest of the ecosystem is vs code based.
Answer: there is none. Hence this foregone conclusion.
I'm happy to see JetBrains focussing on IntelliJ / Android Studio instead. I was really scratching my head when they announced a standalone KMP IDE based on Fleet just 4 months ago. [1]
Yeah I've been using KMP a lot for a hobby project app the last couple of months, already shipped on Android and iOS and will have a Windows Desktop version out soon as well.
As someone who has been incredibly frustrated attempting to use multiplatform frameworks in the past and is used to them causing more problems than they solve, I've been very pleasantly surprised by KMP and Compose Multiplatform.
... but I never once used Fleet, I just do all the coding in Android Studio.
Personal opinion is that JetBrains products have gone down hill the last few years. Tons of memory leaks and performance issues. They are also way behind on the AI front, borderline obsolete in some areas. This is coming from someone who has used jetbrains daily for over a decade
Most of the young crowd is very biased towards vs code irrespective of the top notch features which intellij is providing, so to win the game against vs code fleet becomes critical.
I have the exact opposite experience same thing almost a decade. They were great then there was a phase of really bad performance around 5-6y ago and in the last 3 years it has been much better improving with each version. It is especially much more reactive when indexing large projects or just navigating them.
Agreed, RustRover is by far the best IDE for Rust atm. I also use the AI Assistant which is so toned down that it's actually useful and not full of spam.
What would you suggested instead of JetBrains tools for AI-assisted development?
(I don't just want to hear what everyone says; I specifically I want to hear what JetBrains lovers think about this.)
I was about to go all in on JetBrains becaue I can't stand VSCode, and about to transition from ChatGPT only to trying out in-IDE integrations... but if there's a better thing to try first... all ears.
I've been using Jetbrains IDEs for quite some time. I currently use IntelliJ and Cursor together. Cursor is everything I hoped Jetbains AI would be. The TypeScript support in VSCode and derivatives (like Cursor) is great, unlike Jetbrains. As I already have a license, I switch to IntelliJ for the fantastic Git and DB plugins, as well as the great refactoring and find/replace features. Local History and diffing in Jetbrains is also far superior, so sometimes I use history labels as snapshots in between significant changes from Cursor.
If you're transitioning from ChatGPT pastes to an IDE integration, I would recommend a trial of Cursor. They have acquired SuperMaven, and the autocomplete feature is mostly appropriate and useful. I think the chat-diff-review-apply workflow really tightens and accelerates the feedback loop, as well as the ability to submit an error from the terminal to the chat session with a single click. People say good things about the Compose and Agent features, but I haven't so far been drawn to them to explore.
I use the PyCharm CoPilot plugin. Works great. Can't comment on how good the CoPilot model is vs say Claude or ChatGPT, but it seems decent for what I use it for (autocomplete, small snippets, stuff that I'd look up in the docs or SO, etc.)
I would highly suggest using the jetbrains plug-in "continue". It's BYOK or you can connect it to Ollama. Supports refactoring, inline, RAG, chat, etc.
I rather like the idea behind Continue.dev, especially when I have Ollama with some larger models running on a server somewhere.
However, I have to say that it's a bit buggy, some things like running together with the SonarQube plugin breaks it, other times UI elements for keyboard shortcuts just hang around on the screen when they shouldn't be visible/present. There's a good deal of stuff in their issue tracker: https://github.com/continuedev/continue/issues?q=is%3Aissue%...
That said, I had a pretty good experience with the GitHub Copilot plugin, as long as you're willing to pay for it.
JetBrains is WAY behind VS-Code and its forks (e.g. Cursor) in terms of AI features.
Their own offering, "Jetbrains AI" absolutely SUCKS (just read the reviews, you'll see why).
Third-party AI plugins are pretty basic. Most just offer inline completions and a chat sidebar. For example, GitHub Copilot for Intellij is a shell of itself: No agent capabilities, or even model switching (although that seems to be coming in a future update).
Generally speaking, Jetbrains seems to have missed the AI code editor revolution, and are now trying to play catch-up. The problem is that their plugin API seems to offer less capabilities than VS-Code when it comes to implementing advanced AI features (think of cursor like features). This, combined with the fact that Intellij products are closed source and can't simply be forked by someone who requires additional capabilities, makes it hard for third parties to build advanced AI features.
PS: I also tested their new "Agent" plugin called Junie (invite only beta). It's really basic (like 30% as good as cursors agent mode), but since it's still in invite only beta this should be taken with a grain of salt.
> Most just offer inline completions and a chat sidebar
As someone who doesn't use AI all that much: what else does an IDE need besides an inline prompt and a ChatGPT window to the side? I've played around with the continue.dev plugin and I can't think of anything else I'd want out of AI assistants with the quality they're at at the moment.
> GitHub Copilot for Intellij is a shell of itself
That's on Github, to be honest. And to be expected. It doesn't make much sense for Microsoft to fund a plugin for a competitor's IDE when they already have their own IDEs to sell.
> Intellij products are closed source
They follow the same protocol Microsoft uses: the core is open, but some language plugin features are proprietary. For Microsoft, the proprietary part is just the C# debugger at this point, whereas IntellJ has a whole bunch of paid-for plugins that are closed-source. Still, you can fork the community edition of IntelliJ should you wish.
I have the opposite experience. Intellij works well, fewer crashes and no ai crap that gets in my way. Too many developers rely on shitty ai crutches and you can easily snuff them out because their code is shit.
Yeah, agreed, long time user, just let my sub lapse. I don't like VSCode like I did IDEA but all the features are there, and more, much more. The AI integration and choices (Cursor, Trae, RooCode, Aide, Windsurf, PearAI, etc etc etc) are way better and honestly take the place of a lot of stuff Jetbrains had an advantage on. Also Jetbrains stuff is often not working or unreliable - developing within Docker containers, for one, and it keeps popping up with their shit AI assistant that you can't disable. Honestly, what is this, Clippy and MS Office?
This is definitely surprising given they announced a KMP standalone IDE only a few months ago. For now, Flutter still seems to make more sense than KMP while the KMP world is still maturing.
Dart is an amazing and underrated language too. It compiles to native assembly, has pattern matching, async/await, and null safety. The only thing it's missing in my opinion is some form of checked errors, currently they only have unchecked exceptions.
Oddly, I’m conflicted on Flutter so far, but I have loved working in Dart.
So much so that I ended up writing a queueing app for scheduling batches of sequential tasks on the server in Dart just to see how it could work as a NodeJS replacement, and thought the whole dev experience was great.
I just don't trust Google with a programming language. I feel like Golang has escaped the orbit of Google and could survive without it (I might be wrong). But for Dart I'm pretty sure it would die fast and I don't want to invest time into it as a result.
I read that AdWords is built on Dart’s JS transpiler so I wouldn’t expect for them to just get rid of it. I really wish they would have pushed it over Go tbh. I’d love to use it for back end services.
The modern language landscape is backing away from checked exceptions. Funnily enough Kotlin eschewed them as well, converting checked to unchecked exceptions on the JVM.
The modern language landscape has not backed away from checked errors. Rust is praised for its checked errors, countless posts on this forum praise Result<T> in multiple languages. Swift has checked errors and Kotlin is implementing them via union types in the near future.
Checked errors, via results or exceptions have never been the problem. It has always been Java the language that hasn't provided the syntax sugar for handling checked errors effectively.
There is no difference between:
A doIt() throws B
fun doIt(): Result<A, B>
It all comes down to what the language lets you do once you encounter that error.
There is a huge difference: the first is an _exception_, which:
- Unwinds the stack to a try/catch or exception handler, making exceptions practically difficult to deal with in concurrent programming.
- If unchecked, can be ignored, silently propagating during stack unwinding.
- If checked, infects the call stack with 'throws' annotations.
The second is a normal return value, with no try/catch needed, handling the error case is mandatory in order to handle the success case, and there is not a separate execution regime occurring whenever an error case is encountered.
I genuinely disagree. There is no difference between a checked exception and a Result.
- In concurrent programming uncaught exceptions won’t leave the future. Both values are available to you just like Results. I also don’t think arguments for concurrent programming are valid though. 99% of all code is single threaded.
- It is checked.
- Result infects the call stack as well.
- handling the error case with a checked exception is also mandatory with handling the success case. There is no separate “execution regime”. What is the difference here:
val a = try {
a();
} catch (b) {
onB();
}
val a = match (a()) {
Success(a) => a
Failure(b) => onB()
}
You definitely just don't know how checked exceptions work. This is not true at all. The compiler will not let you call a(); without handling the exception or checking it up the stack. The same way results work.
Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors.
Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else.
Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.
I'm only saying what I've seen here. I typically see praise for Rust's checked errors. Especially since they provide ? to panic and uncheck them. Personally I disagree with Bloch, if you are the thrower you can't possibly know if the caller can or cannot recover from your error so in my opinion its best to check it. If you are not the thrower and you can't recover from it I prefer to uncheck them, because if I can't recover my caller most likely can't either.
The issue really just arises with Java not giving you the capability to uncheck that error easily if you can't recover from it. For example, you need a ton of lines to uncheck:
A doIt() throws B {
throw new B();
}
void usingIt() {
A a;
try {
a = doIt();
} catch (B b) {
throw new RuntimeException(b);
}
a.woohoo();
}
My ideal situation would be for some sort of throws unchecked operator (or whatever syntax we want to bikeshed over) that turns them into unchecked exceptions.
void usingIt() throws unchecked B {
var a = doIt();
a.woohoo();
}
Have you heard of the language elm? The language elm is so safe that it is literally impossible to crash the program short of a memory error.
That's essentially the direction of modern programming languages. It's part of that feeling you get when programming haskell. Once you get it running, it just works. It's very different from the old paradigm where once you get it working, it can crash and you have to debug and do more to get it working better.
I always thought a really good use of KMP would be in writing shared non-visual code, e.g. a library that interacts with your API(s) and any non-visual like that. Then paint a dumbish, platform-specific frontend over the top and link together.
As someone who has to manage native ios and android apps I thought this would be the perfect solution as well. I wanted to write all my data models, api calls, sql cache and business logic as a separate library written with kmp, but what i didn't like was that the ios framework that was generated was a black box with just objc headers. If it generated full swift code that i could inspect for correctness and tweak if needed, I would have jumped on using it right away.
kmp exposes everything as obj-c meaning c headers and not very good type annotations (enums are int only so you cant have full checking on each switch, everything is obj-c reference semantics meaning multi-threading gets tricky, kotlin exceptions are not catchable from swift) so there are a lot of edge cases to write unit tests for (on the client side) which negates a lot point of using kmp, and thats in addition to all of the kotlin-isms that leak out...
they do but its going through objective-c which inherits c enums (which are basically integers) so when you use it from swift its like switching over an unbounded set so you always have to handle "default" cases leading to bugs compared to usage from android
I'm a Vim user, but I occasionally try JetBrains/VSCode to see what I'm missing out on and RustRover, CLion, Goland etc. are by far the most sluggish pieces of software I've used. I am demonstrably slower on them than using Vim with my fuzzy finder, LSP, and AI integrations.
I thought Fleet might add the "magic" to something more VSCode like, but I also don't understand the long term vision.
Same. Although I haven't tried VSCode in a lot of years. I did at one time have it set up to emulate vim quite well. I used it as a daily driver for over 6 months. It would puke the bed at least once a day, reseting the theme, losing all keyboard shortcuts. I'd restart it and go on my merry way.
I keep my Kotlin LSP for NeoVim up to date but it's just not a great experience. I often have to open IntelliJ to sort out import issues. The entire Java community is built on "don't worry about knowing where your imports are coming from, your IDE will do that magic for you". So much is this the case, that the first Manning Kotlin book even said it. Because of this, I was eager to give Fleet a shot. My impression was, "you won't build an LSP because you're afraid of losing revenue... but you'll build this?" Ok. I guess that makes sense - keep people on your playground.
I sure do LOVE Kotlin as a language. But telling me I have to use your product to write it? I'd rather write Go... or even Typescript at that point. Both of those have really nice experiences in a simple text editor + LSP.
Concur. I find that RustRover and PyCharm are outstanding in terms of refactoring, introspection, and treating projects as unified. But they are so slow. Lately, even copy+pasting may take seconds or longer. This and other actions sometimes terminate with an error about being too complex.
That's why I use JB products. I download them, start them up and that's it. I don't need any separate plugins, they just work perfectly out of the box.
Also probably part of the reason why they're so bloated. IDEA with just a single mid-sized project can and will take 10GB+ memory (simple java+gradle for spring or android). Out of the box it has ~100 plugins installed, most of which are useless for most people.
It does work well but it's often too much and uses even more memory than vscodium.
It sounds like your perception of how a computer works is incredibly flawed. ram doesn't sit unused, the kernel uses it for caching and locality. The more RAM you give the kernel, the more you can have resident in the slab cache, the page cache, the filesystem cache, the network backlog, etc. Even on very large machines with more RAM than an average desktop, the kernel can still make use of almost all of it.
I work on efficiency so when people say things like "it's ok for my IDE to be an inefficient pile of garbage that locks up resources" it makes me wonder what kind of program they are producing.
You're both right. The issue here is that both the JVM and the kernel use algorithms that can use all your RAM to speed things up, and there's no good way to know which side should 'win' (to get the best performance).
Historically the JVM will happily use all your RAM even if it doesn't need to, because that reduces the amount of GC work required which increases CPU time available to the IDE for analysis and other tasks. It can be told there's a limits, in which case it'll spend more time GCing to stay under it.
Modern JVMs changed this old default and will wait until the app is idle then start reclaiming memory and releasing it back to the OS. I guess it depends what you mean by "mid sized" but 10GB is quite a bit. It'd be worth checking that everything is running on a recent JVM. Gradle in particular can be a hog if you run it on old JVMs.
I use Rider for .Net and WebStorm for JS. Before I left work I checked, with our small/medium sized project each of them were using a little under 2gb according to windows Task Manager. Adding in some other related processes I'd estimate the two combined might be using 5-6gb in total. So I have at least 26gb left over.
To quote Lord Farquaad: That is a sacrifice I am willing to make
I didn't say it's an inefficient pile of garbage. It's obviously making use of the memory in order to provide information and quick navigation etc.
My computer works completely fine while I have multiple jetbrains ides and browser windows, Docker etc running.
So maybe your perception is the one that's flawed. I know for a fact that my computer can handle it, but it seems like you mistakenly believe that it can't?
I wish Jet brains would give AI features for free for some time, Github co pilot will be incompatible with fleet for some time and even with other legacy jetbrain IDEs like webstorm / pycharm it does not work very well. They always release features for vs code first and then webstorm follows.
The CPU-based one-line AI generated code is available without a subscription. I'd love for Jetbrains to make a slightly-upgraded version that runs on the GPU instead, but the single-line suggestions work fine for me.
I don't think it makes sense for something as compute intense as cloud LLM code generation to be made available for free. I do wish I'd have the ability to connect IntelliJ to a local LLM instance without having to bother with custom plugins or Ollama, though. They're supposedly working on a locally-hosted LLM integration, but that'll be locked behind a subscription as well.
CoPilot has been working fairly well for me in GoLand. I don't know if Copilot has the same or more support in Goland than in Webstorm/Pycharm, so, if the latter, my observation might well be disjoint from yours.
But so far, it's a moderately capable assistant. My biggest complaints with it have more to do with its responses than its fit with the IDE.
Copilot in VS Code has model options, the new agent is available in VSC Insiders that will implement full features and show it's changes in a diff viewer. Jetbrain IDEs don't have the option to change models
And their default model is pretty bad in JS/TS world. (but great in C#)
Copilot works great for every language but the plugin integration into JetBrains IDEs is not as deep.
> In the past year, we’ve also observed significant advances in terms of approaches to application development, an area that we at JetBrains are also heavily investing in. Just recently, we announced a new coding agent named Junie.
That agent must not be very helpful if it causes even the company creating it to be able to support less products.
Good riddance. It is almost like the decision to build a "standalone KMP IDE" came from some Reddit thread with 5 upvotes. Android ecosystem is built around Android Studio, in what world millions of devs would suddenly switch from free (subsidized) Android Studio to a paid Fleet developed by a third party (third first third party?) is beyond me.
Most comments here either praise IDEA-variants as "outstanding", or blame it for being "slow and complicated", both of which feel odd to me (especially the first one). I strongly prefer JetBrains products over anything else, so if it's possible to use PyCharm, I will use PyCharm instead of Vim/VSCode. Yet I cannot imagine calling it outstanding. Maybe, that's just my bad character overall, but I just am surprised why is it that all IDEs/code editors suck so much. About 5 years ago, when LSP appeared (introduced by VSCode IIRC), many people predicted that soon they will far surpass IDEA's (and the likes) autocompletion, etc. And honestly, I believed them. Why wouldn't it? It seems like a simple task, once you have generic LSP functionality, the rest should be "just details", like finding/making good data source for particular language/lib/etc.
And all that JetBrains IDEs do, feels to me like a pretty simple stuff. Like all these refactoring options (pretty much the main reason why I prefer their IDEs over simpler editors, it feels like a natural extension of Vim keybindings: why should I do anything as simple as extracting a method manually?), it seems like a thing that should be easily scriptable once you have powerful code-editing API, so I feel annoyed by the fact they are pretty much "hard-coded" into IDE and I cannot easily add a couple of my own simple refactorings. BTW, they didn't really change over the last 5 years or so. Some bugs get fixed, static code analysis gets smarter and more specialized for a current version of some language, but nothing that would feel like real progress. It's hundreds of tiny distinct things, and it seems like that would progress much faster, if all these things were open-source plugins. As people predicted, when LSP came about. Yet apparently it doesn't, because as imperfect PyCharm is, VSCode cannot do even as much.
So, basically, what distinguishes IDEA from anything else seem like super simple things, and it seems weird that for it it must compromise to use that clunky, configurable via UI (instead of neat JSON/TOML/whatever), memory-hungry IDE. And it still puzzles me. Of course, if it seems so simple, it's fair to ask why I didn't make my own yet. Well, yes, I didn't even look into it. But I just cannot understand, what's the hard problem that community struggles to solve, why all opensource or semi-opensource editors didn't leave clunky "traditioinal IDEs" far behind yet with regard to these core function, even though it seems those traditional IDEs haven't evolved for years?
> I cannot easily add a couple of my own simple refactorings
While this isn't as powerful as the full plugin API, there is Edit > Find > Replace Structurally which can be used to write some pretty complex code alterations, and you can save/load templates to reuse them later.
IMO Jetbrains IDEs are the best IDEs. That doesn't make them amazing or great or outstanding. They have their bugs, their resource leaks, and sometimes just plain weird design decisions, but they're ahead of the competition by a long shot for many programming languages. Other IDEs can match what Jetbrains has to offer, but you have to install and configure every feature yourself, while the Jetbrains stuff mostly comes with batteries included.
JB products have in-memory PSI (as opposed to LSP queried over network), and this PSI by it's nature is multi-language, so they support language injections naturally. This comes in very handy when you are writing an HTML file with embedded CSS and JS, or when you have inline HTML strings or regexps in your code.
As you can see it's not that easy. At the core of an IDE is a database that has to incrementally update itself based on real time edits that can arbitrarily break the datasource (code) that the database is modeling, often in highly confusing ways. Refactorings often require sophisticated data analysis in order to not break code themselves, they aren't simple at all.
The LSP architecture complicates things further by introducing an asynchronous data structure synchronization problem between frontend and backend. Jetbrain's architecture is conventional, with analysis and UI running in-process. They can share data directly and use locks for mutual exclusion. The downside of this is that if locking isn't fine grained enough, or if the GC causes stalls, you can get UI hitches and sluggishness. The upside is that it's a pretty dramatic productivity upgrade because you aren't solving all these hard distributed computing problems that the LSP design introduces.
So the question becomes who solves their problems first? Jetbrains and Oracle have done a ton of work in recent years on solving these problems. Java GC pause times have been driven down aggressively, now there are fully pauseless GCs available although I don't know if IDEA uses them yet. GC pauses haven't been visible for me in years at any rate. And Jetbrains have done lots of work over time to reduce the amount of lock contention that can cause UI stalls, to introduce limited amounts of asynchronous replication within the process and so on.
The thing is, when you're in-process you can use the same ideas as in the LSP to reduce UI latency but to whatever extent makes sense or is necessary in a specific context. Nothing stops you tossing in an actor with a queue if you want that, or introducing a lock if a UI stall is in fact preferable to the alternatives (and sometimes it is). But you aren't bound to it all the time. Whereas the LSP design with separate processes and a hard address space separation doesn't allow that. To add anything you need to extend the protocol and handle the possibility of data skew between frontend and backend, which introduces a lot of surface area for bugs, which then drains time that could be spent on fixing refactoring bugs or adding new static analyses. So it's a hard tradeoff and one isn't clearly a winner to the other.
After decades using Emacs and Idea, I have post traumatic configuration syndrome.
So now I use VSCode and lazyvim/neovim. Which I can install anywhere in about 5 minutes and have a fully working environment with 0 effort and 1 breakage a year. It's great.
So far, it seems like they're very slowly recreating their IDEs from scratch in Fleet while continuing development on the IntelliJ Platform and related IDEs, doing twice as much work for nothing.
reply