Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JetBrains Fleet drops support for Kotlin Multiplatform

blog.jetbrains.com

Post reply on HN
Print view View original

261–270 of 276 posts

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#261

Post by tadfisher »

vips7L wrote: post #260
tadfisher wrote: post #243

Earlier quoted context omitted.

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

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…

The difference is you can just call

    val a = a();
And start the stack unwinding. The `try/catch` is not mandatory to call a().

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#262

Post by rhubarbtree »

lenkite wrote: post #247
alde wrote: post #138

Earlier quoted context omitted.

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.

Cannot comment on Typescript, but Go and Rust are miles better on Jetbrains IDE's. It is not even a competition - vscode is left in the dust.

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

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#263

Post by rhubarbtree »

damidekronik wrote: post #148
rhubarbtree wrote: post #130

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.

Love Webstorm, but I am having constant problems with type hints. Typescript with a solid setup that over time stopped working well.

Same, but vs code doesn’t help me half as much as intellisense.

I often open code written in vs code and immediately spot a bunch of bugs

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#264

Post by thesurlydev »

RockRobotRock wrote: post #206
thesurlydev wrote: post #189

Earlier quoted context omitted.

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.

I'm dipping my toes into AI features with JetBrains' assistant subscription. What am I missing out on?

Couldn't tell you. The fact that JetBrains decided to make it a paid add-on beyond the normal IDE subscription cost turned me off.

I wonder if AI assistant will be deprecated once Junie is GA. Anyone know?

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#265

Post by vips7L »

tadfisher wrote: post #261
vips7L wrote: post #260

Earlier quoted context omitted.

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…

The difference is you can just call val a = a(); And start the stack unwinding. The `try/catch` is not mandatory to call a().

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.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#266

Post by solardev »

AnthonBerg wrote: post #256
b_e_n_t_o_n wrote: post #76

Earlier quoted context omitted.

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…

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…

If it's a simple drop in improvement, I wonder why it's not enabled by default?

Seems like some things become faster while other things become slower? https://youtrack.jetbrains.com/issue/IJPL-1284/Increase-defa...

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#267

Post by vips7L »

NeutralForest wrote: post #29
vips7L wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#268

Post by andrekandre »

robertlagrant wrote: post #182
seanalltogether wrote: post #174

Earlier quoted context omitted.

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…

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

not the op, but had similar experience

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

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#269

Post by AnthonBerg »

solardev wrote: post #266
AnthonBerg wrote: post #256

Earlier quoted context omitted.

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…

If it's a simple drop in improvement, I wonder why it's not enabled by default? Seems like some things become faster while other things become slower? https://youtrack.jetbrains.com/issue/IJPL-1284/Increase-defa...

I’ve wondered about the same thing.

–Thanks for the link!

I only notice things getting much quicker, fwiw. I do habitually throw resources at the IDE as mentioned in the next Youtrack comment down.

Re: JetBrains Fleet drops support for Kotlin Multiplatform

#270

Post by robertlagrant »

andrekandre wrote: post #268
robertlagrant wrote: post #182

Earlier quoted context omitted.

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

not the op, but had similar experience 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…

Ah, right. Yeah, that is surprisingly bad! Why wouldn't they at least generate enums!
Post reply on HN