JetBrains Fleet drops support for Kotlin Multiplatform

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

Yep, I'm glad for their "Classic UI" plugin - I really dislike working with the new one, it's too VSCody for my liking.

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

You also didn't add "IMHO".

>You forgot to add "IMHO"

But also objectively.

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.

>full of crappy bolted on low and mid quality plugins

That's on you. What it comes with is great. And there's a huge selection of good third party plugins if one takes attention to what they install.

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.

ZGC is a much bigger difference though. Try it!!!

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.

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.

No complaints on my MacBook Air M2. What machine are you on?

It’s definitely not as fast to load etc as say sublime, but it’s an IDE not an editor.

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.

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.

[dead]

[flagged]

Ostensibly it's not one of the main features, Datagrip as a product has been a thing long before AI integration was even a thought

I mean adding AI without changing the IDE price would not make to much sense, financially.

I would have love it though ;)

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.

Yes I tried this for awhile but I hit some very odd issue with the bazel plugin and the codebase I work on. It went away when I switched to Goland.

I haven't tried again to see if newer versions have fixed the issue.

yes you can, but only the paid for Ultimate edition if you want the Golang plugin.

Sadly not, as Clion is not available as a plugin like almost all other IDEs: https://www.jetbrains.com/products/compare/?product=idea&pro...

Meanwhile Eclipse and Netbeans have been supporting mixed language development, and JNI debugging, for the last two decades.

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.

Rider handles C++ but it looks like that's only for MSBuild projects.

Thanks. I don't use either but good to correct my guess.

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

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.

You might find this interesting:

https://dmitrykandalov.com/liveplugin

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.

Also, IdeaVim is just awful compared to Evil.

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

There are things missing from Emacs too. Intelligent project and context aware auto-complete. Project wide search that works out of the box.

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.

Eclipse. Coincidentally used as the Java LSP for VSCode, in headless configuration.

Visual Age for Java

OP

Same for Python

Webstorm closer but overall a bit better than vscode. The latter benefits from typescript support, but the former has much nicer devx

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.

The amount of contrast can be measured. https://developer.mozilla.org/en-US/docs/Web/Accessibility/U...

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

It's written all your users, it's not subjective.

You can also configure the VS Code UX.

Very old here (used VC++ v1.0). VSCode user, exclusively for the last 4 years.

RustRover and PyCharm keep my jetbrains subscription going. The AI assistant on pandas APIs is a godsend.

> This, combined with the fact that Intellij products are closed source and can't simply be forked by someone who requires additional capabilities

https://github.com/JetBrains/intellij-community is Apache 2.0

Only some of the language plugins are proprietary.

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

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

That's interesting - I can sort of see it both ways. Would applying unit tests to the exposed functions not have sufficed?

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.

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.