Official response: https://blog.jetbrains.com/blog/2021/11/29/welcome-to-fleet/...

It’s written in Kotlin mainly, a little bit of Rust for native parts, Skiko (Skija + AWT)

The UI framework is similar to Compose, but we started when Jetpack Compose wasn’t there :)

Damn I was hoping to see some GraalVM AOT Java Magic.

I wonder if they have plan to use Kotlin Native. But dogfooding is always good.

I think that would have been a great case for Kotlin native.

I really hope it's not Java mess either: no Wayland support, lags

Really? I'm using their IDEs on Fedora 35 with Wayland. Seems to be working fine.

Now disable XWayland and try again

No chance of that, everything they do is in Java...

It's actually Kotlin aka "I Can't Believe It's Not Java!"

Makes sense given that Kotlin is their own in-house language.

To be fair, Wayland is still new (compared to how long Java has existed), and Java/OpenJDK may improve support in the future.

Wayland is almost 15 years old by now, and it's on track to be enabled by default on most distros as well.

Java is 26 years old.

The first distro to use Wayland by default was Hannah Montana Linux, 10 years ago. Only recently have more widespread distros started using Wayland by default.

Java is old, and Wayland is comparatively new.

there also isn't a reason for them to use it xwayland works fine for the usecase.

I hope they support wayland natively but its just not necessary atm.

XWayland does not work fine for multi-monitor setups with mixed dpi. All XWayland applications will look blurry and there is no intention to fix this for XWayland because its already considered obsolete.

x11 has problems this is known. not moving to wayland isn't a regression its just maintenance of the status quo.

Apparently it's not: https://twitter.com/himanshub16/status/1465238053979447296

In the thread someone from JB mentions it's mostly JVM + some Rust

(the tweet: https://twitter.com/hhariri/status/1465239810050830338?s=20)

Unlikely. The rest of their programmers toolset are mostly java based.

Google translate from a dev vacancy:

You will be surprised, but we decided to create a new IDE from scratch and put together a bold team with a proven success track in creating tools inside JB. And right now we have a prototype and a bunch of bicycles.

Our program consists of several parts that communicate with each other over the network.

The first part is an editor that is written in a new cross-platform UI framework. When we made this framework, we were inspired by React.js and Swift UI.

The second part is a small program written in Rust that tells about the arrangement of files on disk and starts processes. File watcher, process monitor and HTTP client in one binary.

The third part is a server that analyzes the source code of the project. It can be IntelliJ, ReSharper, or LSP server.

This architecture adds flexibility: if you run all the parts on one computer, you get a classic IDE. And if on different machines, it will be convenient to work in the cloud or in a container.

Now that's interesting, let's hope it's not immediate mode based and is closer to SolidJS (without Virtual DOM) than modern React, which clearly has no long-term future.

I guess they mean their GUI framework architecture is close to React's architecture rather than actually using JS for GUI.

> modern React, which clearly has no long-term future

Curious, why do you think that?

they didn’t say it’s a JS framework though

The UI is probably written with compose https://github.com/JetBrains/compose-jb

I believe so as well. Compose is very similar to Electron. Jetbrains Toolbox (which uses compose) uses 500mb memory which is on par with what Electron would use for such a simple app.

Why would it be similar? It doesn’t need all the unnecessary abstraction of a browser/DOM. Also, initial memory usage doesn’t mean it scales the same way from then on.

It uses JVM and JVM tends to hunk all memory for object pools so it can allocate fast if needed.

I just checked. On my Windows laptop from work it uses 18.5 MB in the background. It uses 220-240 MB in the foreground though. Which seems totally unnecessary.

I already ditched the Toolbox app on macOS, because it marks the binaries as Intel only (while they're universal). The IDE's built in updater seems fine if you're only using the stable versions. So I think I'm just going to remove the Toolbox app from all my machines.

I really hope that's not the case - at least the browser has an excuse of being a scripting platform, a 3D and 2D rendering and layout engine, a video streaming platform, a database, a server and who knows what rolled into one - that Toolbox thing hopefully has less than 5% of that in its codebase.

Except Electron is 8 years old, and Compose desktop has started active development half a year ago.

Same. Similarly, since VS Code is the obvious comparison here, I really hope they're planning to open source the basic version of this once it's out of beta. I could really see myself using this if it manages to be both open source and actually lightweight and not a 300+ MB blob.