It uses JetBrain’s own analyzer implemented in Kotlin. I have been thinking whether its best for JetBrains to do their own thing, or to use an existing project (racer -> rls -> rust-analyzer) since 2015 and still don’t know the answer! For ecosystem as a whole, diversity is clearly good.
Why would a community founded on open source “love” closed source software to the detriment/obsolescence of that open source software JB provided previously?
They chose licenses that were designed to allow proprietary forks. The MIT license was written for the X Windows system that was intended to be (and was) forked by proprietary UNIX vendors to build a compatible ecosystem of proprietary tools. I presume the Rust folks are excited to see this happening in their ecosystem. If they’d wanted a different kind of ecosystem they’d have chosen a different license.
Is there any feature you would expect from a FOSS Rust IDE that, say, GNU Emacs with rust-analyzer lacks? (I note that major rust-analyzer developer @matkladpreviously was at JetBrains.)
I don’t use rust-analyzer, so I’m not commenting from personal experience, but it sounds like it turns an LSP client into a Rust IDE, and it’s FOSS.
I use Neovim for everything but I switched to CLion for Rust. The built in debugger features were a big reason. I use the debugger a lot and CLion makes it very easy. The refactoring features are also good although rust-analyzer has gained some of them too now. Overall I think comes down to the I in IDE: everything is integrated.
I suspect part of what’s delaying it is that a lot of people (myself included) still hew to the “the OS is the IDE” philosophy that led to every libc function having a manpage.
For example, I use gVim as my code editor of choice, and I use coc.nvim to integrate Rust (I still need to get memory of how to browse and invoke refactoring features to stick, but that’s another matter), and there are Git integrations and terminal integrations available for it… but I choose to instead have a git gui window and a copy of Yakuake just persistently sitting around so I can switch to them… and I’d do so no matter how good they got, short of Fluxbox/late-stage KWin 4-style support for binding multiple applications together into a tabbed window at the OS level.
Yes, I use the Godot game engine’s integrated editor for features like Ctrl-dragging nodes into the code to create object references and the greate integrated help. Yes, I fault things like Qt’s QWidget APIs for not having as polished a RAD experience as Borland Delphi 1 on Windows 3.1… but I also fault every Git integration I’ve ever tried for having UX that I like less than plain old git gui and I fault any kind of built-in terminal emulator for either producing a smaller viewport than Yakuake, or just reinventing “Hit F12 to hide/show the 90% wide, 80% tall terminal” at the application level with poorer support for thw work I’ve done to make sure things like passing Ctrl-modified keys to applications work correctly.
…and I’m not even using a tiling window manager yet.
I haven’t tried RustRover yet, but based on having used their other IDEs for ages I’d say it’s a bit of pricing and UI.
Generally the language specific IDEs are extremely tailored to the language, IDEA itself still at times feel largely oriented towards the JVM ecosystem and using other languages can seem a bit clunky in terms of how you configure the toolchain and other language specific things.
They cost less than IDEA, but if you buy a few of the IDEs you are better off buying the subscription for all products. I generally live in a terminal, but for certain languages/tasks I still prefer a full IDE and the all products subscription definitely has been worth it for me.
For the others JetBrains IDE, the difference is mostly UI and pricing.
The pricing part is self evident: WebStorm and Pycharm are much more affordable than IntelliJ ultimate.
The UI part is more subtle. IntelliJ mostly feel like it is geared toward Java/kotlin development, and using it for Python or JavaScript mean that you will carry that bagage in your projects. While never a PITA, you always end up feeling other language don’t have the same focus as java. For example, you always seems to have an option for specifying a JDK, even though it make no sense for your project. The project structure window is very Java centric. Etc.
By having a dedicated IDE, you can remove those part that exists to accommodate Java, and sell it cheaper.
I wasn’t there, but I imagine the main explanation here are business and technical historical reasons — IntelliJ IDEA started as a Java IDE, and PyCharm came after IDEA already were successful. I would imagine, technically, it’s much easier to “fork” an IDE for X and turn it into an IDE for Y, than to make an IDE for X and Y: refactors which change cardinality from singular to plural are painful. And, from the business perspective, if you have a wildly successful product, it might be scary to branch that directly into a mostly orthogonal market niche, much easier to experiment with a separate brand.
Today, having separate products I imagine is still great from the business perspective — you can clearly track which languages people buy most, you could price individual products differently, and you could have “all products” pack as well.
For the user, it could be a rather significant negative. If you hop between languages, and use more esoteric ones, then JetBrains model would be fairly inconvenient. That’s the reason I still use VS Code, although I much prefer the IJ platform.
OTOH, many users work overwhelmingly with a single language (or a single project even). In that context, having a GUI that is exactly tailored for what you do out-of-the-box is a benefit. For every language, there are certain aspects that you want to show in GUI by default, but if you do this for every language, you run out of pixels (and user’s attention before that). One great example here comes from the early days of IntelliJ Rust, when I added initial support for the CLion. Those days, when you open a Rust project in CLion, everything worked, but there was also this giant panel in UI warning you that “CMakeLists.txt not found”. This makes total sense for CLion — it requires CMake to work, and so must warn the user pretty aggressively if it can’t make head or tails of a C++ project. But of course there’s no CMake in Rust projects!
Unclear. It does make sense for Java since LSP support for that language is abysmal, and IntelliJ works wonders. But rust-analyzer is a first-class LSP server that plugs into virtually anything. Maybe they are catering to their existing CLion user base.
True, you didn’t. It seems I’ve skipped a few intermediary questions.
What is the most popular editor for Rust today? VSCode.
Does using VSCode feel wrong to write Rust? I think not.
What VSCode is written in? JavaScript.
Does using JavaScript feels wrong when writing Rust? I guess not, because of point 1.
So, why using JavaScript to write Rust is different than using Java for writing Rust? Well, saying “they’re different languages” is I guess true, but I fail to see how that answers the question.
Even if we argue that using Emacs is “right”, then Emacs is largely written in ELisp, and it’s kind of similar to Java and JS in runtime.
Does using VSCode feel wrong to write Rust? I think not.
It does to me… but then I use gVim for all my coding and fall back to Featherpad for anything I don’t want a programmer’s text editor for.
(And I’m also one of those people who feels that the answer to “Is Electron the right tool for the job?” is always “No” because, if you’re doing something web tech is properly suited for, then you need the kinds of ad-blocking and privacy extensions and userstyles/userscripts and so on that only come with a proper web browser.)
(I say this as someone whose only Java application of note is a Flatpak-sandboxed copy of jDownloader, whose only potentially-Electron app of note is a pinned browser tab containing Discord, and who wants to find time to replace Thunderbird with something that’s less of a hog. I resent that I can’t get rid of [insert name of ANY web browser] for being an order of magnitude more bloated than every other app on my desktop except Thunderbird, which sits in the middle between the two points.)
Bah, Rust is just AOT-compiled LLVM bytecode. A Java or JS program is all native after a few seconds of startup…
Rust is a poor example to compare to, given how much Rust’s type system and general API trends present in the ecosystem rub your code’s inefficiencies in your face at every turn, while JavaScript and, to a lesser extent, anything GCed, lure you into writing code that can fall off the runtime’s fast path at a glance because it’s prioritizing not distracting the coder with implementation details.
(And yes, I would write everything I create in Rust for the maintainability advantages if the ecosystem was complete enough.)
Even your hand-coded x86-64 program isn’t really native - it gets lowered into the native microcode in your CPU for execution.
And yet somehow, something about the JavaScript and Java runtime environments and ecosystems let me recognize their applications on my system by their responsiveness or resource consumption flaws, while the PyQt QWidget applications aren’t appreciably different from the C++ Qt QWidget ones.
(Most likely because “be glue for C and/or C++” is standard in Python, while JavaScript and Java both encourage you to do more without dropping into a lower language, and both reinvent much more of the UI rendering in the GCed layer of the stack that’s more abstracted away from the machine model.)
When things like VSCode are praised for “being uncommonly light and snappy for an Electron app”, that says something about your platform.
FWIW, I find vscode (and found intellij when I used it) to be as snappy as xcode or visual studio.
I find vim, once I’ve loaded it up with plugins for syntax highlighting, completion and error checking to feel more sluggish than vscode.
Eclipse is a beast, but given my experience with intellij I put that down to architecture rather than implementation.
At $WORK we use a lot of Rust and are starting to see some of the costs that weren’t obvious at first.
We deploy on consumer devices rather than servers so code bloat is a problem. Even simple programs end up… big. It’s a mix of generics, macros and a culture of just adding in another crate that seems to be at fault. Did you know that bitflags! generates large Debug impls? I didn’t until this week.
Runtime memory use tends to be relatively high too. The ownership rules and [derive(Clone)] encourage copying rather than sharing. Sometimes the copies end up on the heap, sometimes on the stack - both have caused issues. In GCed languages sharing data is a lot easier.
I like Rust a lot, but don’t want it used for everything.
You’re conflating two separate concerns. Why I don’t like JavaScript- or Java-based apps written by other people, and why I do like to use Rust for my own creations.
I find vim, once I’ve loaded it up with plugins for syntax highlighting, completion and error checking to feel more sluggish than vscode.
I’m generally a fairly minimalist guy. With VSCode, I found myself paying for the memory bloat of a webtech-based IDE even after chopping the UI down to the LSP-enabled check-on-save programmer’s text editor I wanted… and it’s the same rust-analyzer whether I’m using VSCode or Vim. (I use check-only-on-save in Vim because I have sensory processing issues and want to absolutely minimize unexpected changes to what the screen is displaying in my peripheral vision when I’m focused on my cursor. I combine it with pear-tree to ensure that typing an opening paren/bracket/quote/etc. won’t cause a big, distracting re-highlight.)
Eclipse is a beast, but given my experience with intellij I put that down to architecture rather than implementation.
I find that every Swing, SWT, or JavaFX application I’ve ever used has subtle but irritating input latency issues on Linux (across multiple distros, multiple physical machines, and two decades)… the same kind of input latency issue that drove me from KDE to LXDE for most of KDE 4’s lifecycle when KWin 4.0 and beyond started exhibiting it. I am very doubtful that IntelliJ would magically solve that.
Plus, the machine I’m currently on has its RAM maxed out at 32GiB and I still see it getting worryingly full during the course of my workflow no thanks to my browser(s). I don’t need to spend time on learning how to optimize the JRE’s memory management strategy for things other than long-running application servers.
That’s the “written by other people” side of things done. Now for the “written by me”.
Runtime memory use tends to be relatively high too. The ownership rules and [derive(Clone)] encourage copying rather than sharing. Sometimes the copies end up on the heap, sometimes on the stack - both have caused issues. In GCed languages sharing data is a lot easier.
I’m willing to accept a certain bit of “dependency author was sloppy” bloat if it means never seeing another NullPointerException.
I like Rust a lot, but don’t want it used for everything.
I want to use it for everything because it’s the only language with an even marginally mainstream ecosystem that has a strong type system, a not-like-Haskell focus on “fearless upgrades”, and a large stable of packages for making it easy to expose bindings for other languages.
In other words, my preference for Rust comes down to a mix of “I’m tired of burning out trying to reinvent Rust in other languages” and “OK, I implemented [thing]. it’s done. If you make me touch it again, you’ll be sorry!”
I hope that doesn’t mean I need to buy another IDE if I’m already using paid license for CLion.
Edit: Eh, I think it does.
For the existing open-source plugin, we’ll do our best to maintain compatibility with newer versions of our IDEs, but we won’t be fixing bugs or adding new features.
The Rust plugin actually uses Kotlin (I know, basically the same thing).
I believe all the classic IDEs use Java Swing as the GUI library, which isn’t native or electron, in my opinion, but I guess it depends on what is meant by “native”. This is different from an IDE like Eclipse which used SWT. SWT wraps native components from the OS and makes them available to Java, where Swing draws the components from Java.
There’s a reason for me to not consider it all on its own. As a Linux user, across two decades, multiple machines, and and multiple distros, I’ve never found a Swing, SWT, or JavaFX app that didn’t suffer from an irritating problem of subtle but noticeable input latency on Linux desktops.
(For context, I was an avid KDE 3.5 power user but migrated to LXDE and stayed away from KDE 4 for much longer than many other people because each new “it’s fast and stable now” release never seemed to fix the input latency KWin had gained in the port to Qt 4… and I’ve been around long enough that I remember when multi-monitor users had to hex-edit the JRE to rename the string XINERAMA to some non-matching piece of gibberish to un-break Java apps on multi-monitor desktops.)
My understanding is that both new and old UI are basically Swing, though details are fun. Eg, JetBrains maintains their own JRE to have better font rendering: https://github.com/JetBrains/JetBrainsRuntime
And year, JetBrains in general do a lot of work in the space of desktop GUIs:
the core IDEs are heavy users of Swing
Rider uses the “Rider Protocol” to strictly separate IDE UI (JVM+Swing) from brains (C#), and, as far as I understand, that’s a significantly different protocol than LSP
there are two version of “let’s glue JVM to skia” idea — both Noria and Compose For Desktop work that way (and I think both a powered by skija
I can’t speak directly to RustRover (since it just came out) but I use JetBrains IDEs for most of my work because the experience is generally more reliable, consistent, and powerful than VSCode + plugins. For example, refactoring “just works”, and works in more cases. Autocomplete is also better, JetBrains tends to put what you actually want at the top of the list (using a combination of types and simple ML). JetBrains also ships its own linters and they tend to be excellent. And since my employer pays for the licenses, I might as well use what works best (for me).
And JetBrains has their own LLM-based coding assistant, though it’s rolling out slowly and you have to join a waiting list. I haven’t gotten to the head of the list yet but my hunch is that given it’s deeply integrated into the IDE, it’ll generate far fewer “this code doesn’t even compile, much less work” completions than Copilot.
It doesn’t yet offer inline completions, but it seems to do a good job of grabbing context for chat style questions. For now I use it and copilot at the same time.
Does this still use their own analyzer or did they switch to
rust-analyzer?It uses JetBrain’s own analyzer implemented in Kotlin. I have been thinking whether its best for JetBrains to do their own thing, or to use an existing project (racer -> rls -> rust-analyzer) since 2015 and still don’t know the answer! For ecosystem as a whole, diversity is clearly good.
The great thing about Rust’s license is that they can fork and add proprietary enhancements to rust-analyzer if they want.
Great or terrible, depending on your viewpoint.
The rust community seems to prefer licenses that encourage proprietary forks. I imagine they’d love this.
Why would a community founded on open source “love” closed source software to the detriment/obsolescence of that open source software JB provided previously?
They chose licenses that were designed to allow proprietary forks. The MIT license was written for the X Windows system that was intended to be (and was) forked by proprietary UNIX vendors to build a compatible ecosystem of proprietary tools. I presume the Rust folks are excited to see this happening in their ecosystem. If they’d wanted a different kind of ecosystem they’d have chosen a different license.
“When will there be a FOSS Rust IDE?”
Is there any feature you would expect from a FOSS Rust IDE that, say, GNU Emacs with rust-analyzer lacks? (I note that major rust-analyzer developer @matklad previously was at JetBrains.)
I don’t use rust-analyzer, so I’m not commenting from personal experience, but it sounds like it turns an LSP client into a Rust IDE, and it’s FOSS.
I use Neovim for everything but I switched to CLion for Rust. The built in debugger features were a big reason. I use the debugger a lot and CLion makes it very easy. The refactoring features are also good although rust-analyzer has gained some of them too now. Overall I think comes down to the I in IDE: everything is integrated.
I suspect part of what’s delaying it is that a lot of people (myself included) still hew to the “the OS is the IDE” philosophy that led to every libc function having a manpage.
For example, I use gVim as my code editor of choice, and I use coc.nvim to integrate Rust (I still need to get memory of how to browse and invoke refactoring features to stick, but that’s another matter), and there are Git integrations and terminal integrations available for it… but I choose to instead have a
git guiwindow and a copy of Yakuake just persistently sitting around so I can switch to them… and I’d do so no matter how good they got, short of Fluxbox/late-stage KWin 4-style support for binding multiple applications together into a tabbed window at the OS level.It’s the Don’t make me code in your text box effect operating in the opposite direction.
Yes, I use the Godot game engine’s integrated editor for features like Ctrl-dragging nodes into the code to create object references and the greate integrated help. Yes, I fault things like Qt’s QWidget APIs for not having as polished a RAD experience as Borland Delphi 1 on Windows 3.1… but I also fault every Git integration I’ve ever tried for having UX that I like less than plain old
git guiand I fault any kind of built-in terminal emulator for either producing a smaller viewport than Yakuake, or just reinventing “Hit F12 to hide/show the 90% wide, 80% tall terminal” at the application level with poorer support for thw work I’ve done to make sure things like passing Ctrl-modified keys to applications work correctly.…and I’m not even using a tiling window manager yet.
I don’t know tbh. I use emacs for rust but I’m not sure people would call it an ide.
rust-analyzer is awesome and seems to work pretty well with eglot.
Maybe refactoring would be nice https://lists.gnu.org/archive/html/emacs-devel/2023-09/msg00545.html
Just hope that there are enough Rust developers to maintain a fork of the original free version.
“When will there be a FOSS Rust IDE in a decent framework?”
And then,
“When will there be a FOSS Rust IDE in a decent framework?”“When will there be a decent FOSS Rust IDE that isn’t so bloated?”
How about VSCodium with rust-analyzer? Isn’t it enough?
Hm, obvious question – what’s better about a standalone Rust IDE?
Is this a pricing issue, a UI issue, or features? Or all?
It says you can use the Rust features within IntelliJ, so I guess it’s UI or pricing.
I haven’t tried RustRover yet, but based on having used their other IDEs for ages I’d say it’s a bit of pricing and UI.
Generally the language specific IDEs are extremely tailored to the language, IDEA itself still at times feel largely oriented towards the JVM ecosystem and using other languages can seem a bit clunky in terms of how you configure the toolchain and other language specific things.
They cost less than IDEA, but if you buy a few of the IDEs you are better off buying the subscription for all products. I generally live in a terminal, but for certain languages/tasks I still prefer a full IDE and the all products subscription definitely has been worth it for me.
For the others JetBrains IDE, the difference is mostly UI and pricing.
The pricing part is self evident: WebStorm and Pycharm are much more affordable than IntelliJ ultimate.
The UI part is more subtle. IntelliJ mostly feel like it is geared toward Java/kotlin development, and using it for Python or JavaScript mean that you will carry that bagage in your projects. While never a PITA, you always end up feeling other language don’t have the same focus as java. For example, you always seems to have an option for specifying a JDK, even though it make no sense for your project. The project structure window is very Java centric. Etc.
By having a dedicated IDE, you can remove those part that exists to accommodate Java, and sell it cheaper.
I wasn’t there, but I imagine the main explanation here are business and technical historical reasons — IntelliJ IDEA started as a Java IDE, and PyCharm came after IDEA already were successful. I would imagine, technically, it’s much easier to “fork” an IDE for X and turn it into an IDE for Y, than to make an IDE for X and Y: refactors which change cardinality from singular to plural are painful. And, from the business perspective, if you have a wildly successful product, it might be scary to branch that directly into a mostly orthogonal market niche, much easier to experiment with a separate brand.
Today, having separate products I imagine is still great from the business perspective — you can clearly track which languages people buy most, you could price individual products differently, and you could have “all products” pack as well.
For the user, it could be a rather significant negative. If you hop between languages, and use more esoteric ones, then JetBrains model would be fairly inconvenient. That’s the reason I still use VS Code, although I much prefer the IJ platform.
OTOH, many users work overwhelmingly with a single language (or a single project even). In that context, having a GUI that is exactly tailored for what you do out-of-the-box is a benefit. For every language, there are certain aspects that you want to show in GUI by default, but if you do this for every language, you run out of pixels (and user’s attention before that). One great example here comes from the early days of IntelliJ Rust, when I added initial support for the CLion. Those days, when you open a Rust project in CLion, everything worked, but there was also this giant panel in UI warning you that “CMakeLists.txt not found”. This makes total sense for CLion — it requires CMake to work, and so must warn the user pretty aggressively if it can’t make head or tails of a C++ project. But of course there’s no CMake in Rust projects!
Unclear. It does make sense for Java since LSP support for that language is abysmal, and IntelliJ works wonders. But rust-analyzer is a first-class LSP server that plugs into virtually anything. Maybe they are catering to their existing CLion user base.
Running a java app to write rust feels…. wrong.
And why using JavaScript to write Rust is different?
I didn’t say anything about Javascript?
Even if I had - they’re different languages?
True, you didn’t. It seems I’ve skipped a few intermediary questions.
Even if we argue that using Emacs is “right”, then Emacs is largely written in ELisp, and it’s kind of similar to Java and JS in runtime.
The fun thing is that “Rust compiler” that VS Code uses is written in Rust, but “Rust compiler” used by Rover is written in Kotlin,
It does to me… but then I use gVim for all my coding and fall back to Featherpad for anything I don’t want a programmer’s text editor for.
(And I’m also one of those people who feels that the answer to “Is Electron the right tool for the job?” is always “No” because, if you’re doing something web tech is properly suited for, then you need the kinds of ad-blocking and privacy extensions and userstyles/userscripts and so on that only come with a proper web browser.)
Why do you hate memory safety? :-)
Why do you hate native code? :P
(I say this as someone whose only Java application of note is a Flatpak-sandboxed copy of jDownloader, whose only potentially-Electron app of note is a pinned browser tab containing Discord, and who wants to find time to replace Thunderbird with something that’s less of a hog. I resent that I can’t get rid of [insert name of ANY web browser] for being an order of magnitude more bloated than every other app on my desktop except Thunderbird, which sits in the middle between the two points.)
Bah, Rust is just AOT-compiled LLVM bytecode. A Java or JS program is all native after a few seconds of startup…
Even your hand-coded x86-64 program isn’t really native - it gets lowered into the native microcode in your CPU for execution.
Rust is a poor example to compare to, given how much Rust’s type system and general API trends present in the ecosystem rub your code’s inefficiencies in your face at every turn, while JavaScript and, to a lesser extent, anything GCed, lure you into writing code that can fall off the runtime’s fast path at a glance because it’s prioritizing not distracting the coder with implementation details.
(And yes, I would write everything I create in Rust for the maintainability advantages if the ecosystem was complete enough.)
And yet somehow, something about the JavaScript and Java runtime environments and ecosystems let me recognize their applications on my system by their responsiveness or resource consumption flaws, while the PyQt QWidget applications aren’t appreciably different from the C++ Qt QWidget ones.
(Most likely because “be glue for C and/or C++” is standard in Python, while JavaScript and Java both encourage you to do more without dropping into a lower language, and both reinvent much more of the UI rendering in the GCed layer of the stack that’s more abstracted away from the machine model.)
When things like VSCode are praised for “being uncommonly light and snappy for an Electron app”, that says something about your platform.
FWIW, I find vscode (and found intellij when I used it) to be as snappy as xcode or visual studio.
I find vim, once I’ve loaded it up with plugins for syntax highlighting, completion and error checking to feel more sluggish than vscode.
Eclipse is a beast, but given my experience with intellij I put that down to architecture rather than implementation.
At $WORK we use a lot of Rust and are starting to see some of the costs that weren’t obvious at first.
We deploy on consumer devices rather than servers so code bloat is a problem. Even simple programs end up… big. It’s a mix of generics, macros and a culture of just adding in another crate that seems to be at fault. Did you know that bitflags! generates large Debug impls? I didn’t until this week.
Runtime memory use tends to be relatively high too. The ownership rules and
[derive(Clone)]encourage copying rather than sharing. Sometimes the copies end up on the heap, sometimes on the stack - both have caused issues. In GCed languages sharing data is a lot easier.I like Rust a lot, but don’t want it used for everything.
You’re conflating two separate concerns. Why I don’t like JavaScript- or Java-based apps written by other people, and why I do like to use Rust for my own creations.
I find that every Swing, SWT, or JavaFX application I’ve ever used has subtle but irritating input latency issues on Linux (across multiple distros, multiple physical machines, and two decades)… the same kind of input latency issue that drove me from KDE to LXDE for most of KDE 4’s lifecycle when KWin 4.0 and beyond started exhibiting it. I am very doubtful that IntelliJ would magically solve that.
Plus, the machine I’m currently on has its RAM maxed out at 32GiB and I still see it getting worryingly full during the course of my workflow no thanks to my browser(s). I don’t need to spend time on learning how to optimize the JRE’s memory management strategy for things other than long-running application servers.
That’s the “written by other people” side of things done. Now for the “written by me”.
I’m willing to accept a certain bit of “dependency author was sloppy” bloat if it means never seeing another
NullPointerException.I want to use it for everything because it’s the only language with an even marginally mainstream ecosystem that has a strong type system, a not-like-Haskell focus on “fearless upgrades”, and a large stable of packages for making it easy to expose bindings for other languages.
In other words, my preference for Rust comes down to a mix of “I’m tired of burning out trying to reinvent Rust in other languages” and “OK, I implemented [thing]. it’s done. If you make me touch it again, you’ll be sorry!”
I hope that doesn’t mean I need to buy another IDE if I’m already using paid license for CLion.
Edit: Eh, I think it does.
Is it native or electron? Is it Java (like JetBrains other IDEs)?
Probably Java given this line in the post.
The Rust plugin actually uses Kotlin (I know, basically the same thing).
I believe all the classic IDEs use Java Swing as the GUI library, which isn’t native or electron, in my opinion, but I guess it depends on what is meant by “native”. This is different from an IDE like Eclipse which used SWT. SWT wraps native components from the OS and makes them available to Java, where Swing draws the components from Java.
JetBrains now has Fleet in preview, which uses a new UI library called Noria. This IDE feels a lot closer to something like VSCode.
Do you know if the “new UI” in, for example, Goland, is using Noria? Or is it just restyled Swing components?
It’s restyled Swing, AIUI other IDEs on their old plaform are picking up same look.
There’s a reason for me to not consider it all on its own. As a Linux user, across two decades, multiple machines, and and multiple distros, I’ve never found a Swing, SWT, or JavaFX app that didn’t suffer from an irritating problem of subtle but noticeable input latency on Linux desktops.
(For context, I was an avid KDE 3.5 power user but migrated to LXDE and stayed away from KDE 4 for much longer than many other people because each new “it’s fast and stable now” release never seemed to fix the input latency KWin had gained in the port to Qt 4… and I’ve been around long enough that I remember when multi-monitor users had to hex-edit the JRE to rename the string
XINERAMAto some non-matching piece of gibberish to un-break Java apps on multi-monitor desktops.)I don’t know the answer to that.
The IntelliJ Platform is open source, so the way to get the answer here is to take a look at the source:
My understanding is that both new and old UI are basically Swing, though details are fun. Eg, JetBrains maintains their own JRE to have better font rendering: https://github.com/JetBrains/JetBrainsRuntime
And year, JetBrains in general do a lot of work in the space of desktop GUIs:
Ah yes. Thanks!
What are some compelling reasons to use RustRover over VSCode + Github Copilot + rust-analyzer?
I can’t speak directly to RustRover (since it just came out) but I use JetBrains IDEs for most of my work because the experience is generally more reliable, consistent, and powerful than VSCode + plugins. For example, refactoring “just works”, and works in more cases. Autocomplete is also better, JetBrains tends to put what you actually want at the top of the list (using a combination of types and simple ML). JetBrains also ships its own linters and they tend to be excellent. And since my employer pays for the licenses, I might as well use what works best (for me).
FWIW Copilot has a plugin for intellij.
And JetBrains has their own LLM-based coding assistant, though it’s rolling out slowly and you have to join a waiting list. I haven’t gotten to the head of the list yet but my hunch is that given it’s deeply integrated into the IDE, it’ll generate far fewer “this code doesn’t even compile, much less work” completions than Copilot.
It doesn’t yet offer inline completions, but it seems to do a good job of grabbing context for chat style questions. For now I use it and copilot at the same time.