JetBrains Fleet drops support for Kotlin Multiplatform

Post by wiseowise » Tue, Feb 11, 2025, 8:31 PM UTC

deergomoo wrote: post #23

malkia wrote: post #6

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

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.

Post by tommica » Tue, Feb 11, 2025, 8:41 PM UTC

homebrewer wrote: post #40

solardev wrote: post #28

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…

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…

Post by jayd16 » Tue, Feb 11, 2025, 9:14 PM UTC

teh64 wrote: post #12

NomDePlum wrote: post #10

Earlier quoted context omitted.

It is possible to install the Python and Go plugins into IntelliJ. That's the setup used wildly in my current place of work. It wouldn't surprise me if that was the case with Rust, C++, and possibly even C# too. I'm sure there is some loss of UX and related features in this setup but there are always trade-offs.

No both C++ and C# need to be bought as separate IDEs: Only Clion includes C++: https://www.jetbrains.com/products/compare/?product=idea&pro... Only Rider includes C#: https://www.jetbrains.com/products/compare/?product=idea&pro...

Post by billllll » Tue, Feb 11, 2025, 9:28 PM UTC

vips7L wrote: post #33

tadfisher wrote: post #27

Earlier quoted context omitted.

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

Post by vips7L » Tue, Feb 11, 2025, 10:05 PM UTC

billllll wrote: post #47

vips7L wrote: post #33

Earlier quoted context omitted.

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

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…

    A doIt() throws B {
       throw new B();
    }

    void usingIt() {
       A a;
       try {
           a = doIt();
       } catch (B b) {
           throw new RuntimeException(b);
       }
       
       a.woohoo();
    }

    void usingIt() throws unchecked B {
        var a = doIt();
        a.woohoo();
    }