Live data from Hacker News

JetBrains Fleet drops support for Kotlin Multiplatform

blog.jetbrains.com

161–170 of 276 posts

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#161
post #149

Earlier quoted context omitted.

You can also configure the VS Code UX.

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

> Nobody expects their defaults to be unchanged.

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

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#162
post #147

Earlier quoted context omitted.

So your arguments that it’s “objectively bad” are - it has bad defaults for theme (which I bet most devs change immediately anyways on every IDE) - “common items” (which when unspecified could be assumed to be subjective to each persons workflow) are hidden in submenus? - “common shortcuts” (again unspecified) require stretching (again, something trivially changed) Unless you have more these feel not only extremely w…

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.

Allow me to be more clear then:

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

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#163

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…

That, to me, is a feature, not a bug.

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.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#164
post #136

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.

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

“objectively bad”

No, it’s subjectively bad for you.

It really grinds my gears when people use “objectively” when being objective is to deal purely in unbiased observable, repeatable facts.

Your justification starts first with screen contrast - something that is truly in the eye of the beholder.

Then you go on about “finger gymnastics” for shortcuts - again something that you (and yes I don’t disagree others as well) suffer from.

Neither are issues that have bothered me one iota - so much so that your mention is really the first time I’ve thought about either.

However you then compare this to another app that also has many detractors thus creating an instant bias.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#165

Earlier quoted context omitted.

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 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. https://github.com/continuedev/continue

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.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#166

Earlier quoted context omitted.

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…

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

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.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#167
post #163

Earlier quoted context omitted.

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…

That, to me, is a feature, not a bug. 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…

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

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#168
post #147

Earlier quoted context omitted.

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.

Allow me to be more clear then: - “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 subjecti…

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)

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#169

Earlier quoted context omitted.

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…

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.
Post reply on HN