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 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.
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.
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 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,
Why do you hate memory safety? :-)
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.
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.