Introducing the Fleet Public Preview | The JetBrains Fleet Blog
blog.jetbrains.com
Since the initial announcement of Fleet, we have had an overwhelming amount of interest from all of you, with over 137,000 people signing up for the private preview. Our reason for starting with a clo

Fleet is a new IDE from JetBrains

  •  hfkldjbuq   ( @hfkldjbuq@beehaw.org ) 
    2•2 years ago

    Will Fleet be open source?

    We are considering open sourcing parts of the product or the technology behind it. Stay tuned for details in the coming months.

    open core non-commercial use… I would only use it if I had to… GNU Emacs still is the best.

    Fleet is mainly written in Kotlin, which means it runs on the JVM. The UI framework is a home-grown solution using Skia (via Skiko). For those of you wondering why we didn’t use Compose Multiplatform: we started working on Fleet when Compose Multiplatform wasn’t available yet.

    Furthermore, Fleet uses Rust for the Fleet System Agent, which is a process that runs on the target machine. It is used to build the project, run code, execute terminal commands, and perform other actions in the target environment on behalf of Fleet.

    They are too invested on the JVM already… Webasembly ftw

    •  astynax   ( @astynax@0xdd.org.ru ) OP
      2•2 years ago

      The Fleet’s “commercial part” is related to IDEA’s paid features. But IDEA has the “community edition” which is fully open. Eventually, that part of functionality should be available in the Fleet somehow.

      Another “paid part” is related with cloud features, but at some degree clouding may appear in a free form.

      Also, Fleet works well with LSP and that functionality will be available freely.

      “GNU Emacs still is the best.” but “too invested”, really? :) (I’m emacser too so I know how to be “too invested”)

      JB owns Kotlin and people there know how to use it properly. Some resource-critical parts of the Fleet are made using Rust or call C-libs (Skia). But for the “domain logic” level Kotlin plays pretty well. (I was a part of the Fleet team, so I saw all the guts :)

      •  hfkldjbuq   ( @hfkldjbuq@beehaw.org ) 
        1•2 years ago

        The Fleet’s “commercial part”…

        indeed open core business model similar to idea

        JB owns Kotlin and people there know how to use it properly.

        Sure. that is the most logical thing for jetbrains to do. I’m just critical of using JVM for something like an editor because startup time, memory consumption, … and I would be glad to see webassembly taking some JVM market as well.

        Some resource-critical parts of the Fleet are made using Rust or call C-libs (Skia). But for the “domain logic” level Kotlin plays pretty well. (I was a part of the Fleet team, so I saw all the guts :)

        I will have to test it to see for myself.

        “GNU Emacs still is the best.” but “too invested”, really? :) (I’m emacser too so I know how to be “too invested”)

        GNU Emacs is the best current editor in terms of freedom, extensibility, ecosystem, frontends for both tui and gui, but it loses in performance, safety, modernity, graphical interface (all this mostly due to “too invested” in legacy, Elisp, no proper requirements engineering and UX/UI).

        I’ve been hopeful for Helix editor and their planned webassemly plugins system https://github.com/helix-editor/helix/issues/122. Lapce has wasi in it already https://github.com/lapce/lapce/issues/598.

    •  Aarkon   ( @Aarkon@feddit.de ) 
      1•2 years ago

      Webassembly isn’t always the most efficient solution, e.g. when manipulating the Dom, JavaScript is usually faster.

      If you take Webassembly as a replacement for the JVM on the server side, well, I can understand everybody who would like to wait for that piece of technology to mature a bit more. ;)