For those more familiar with Rust plugin (I merely use it, know nothing about it's dev process), is this a big deal? What does this mean / imply ?
1 Like
The Rust plugin is an alternative to Rust-Analyzer, and many times took inspiration from it.
It imples that their source is becoming closed, which means that it's not open anymore (ha!). Jokes aside, it means that they are further distancing themselves from Rust-Analyzer.
2 Likes
Jetbrains often have more powerful (but sometimes less reliable) tools - refactoring, indexing, etc. - than the community based tools. The Rust plugin has so far been somewhat weak, relative to what I've seen from them elsewhere, so if this is what they need to spend more time and effort on Rust then I guess I'm fine with it?
Jetbrains don't directly support LSP, so you can't just use rust-analyzer now as far as I know, but I expect someone out there is already working on the wrapper plugin.
To some, it may be a big deal, but not to everyone. It depends how you use their tools.
So far, the plugin was working with CLion (C++) and IntelliJ (Kotlin/Java). CLion is paying, and IntelliJ has both a free version (CE) and a paying one (Ultimate), but you needed the Ultimate version to be able to debug. It was also sort of working on PyCharm Pro (Python), but not very well.
In my experience, those tools are much more comfortable, more reliable, and more powerful than VSCode, which also requires a lot of getting used to and messing around with configuration files or finding the appropriate plugins. Then there are other Vim-like tools, but I haven't really tried them (it's a long time since I've used vi). Jetbrains tools are real IDEs and the whole flow is consistent, even across their different tools. But in the end, it's a matter of preference - some prefer VSCode, others Vim - and what else you do with these tools.
The plugin was open-source and partially based on rust-analyzer. It had been taken over by JetBrains for a while, and had a considerable and increasing number of issues (from 1.6k one year ago to 1.8k now). Even though, it was perfectly possible to develop with the plugin; I think a big part of these issues were suggestions, duplicates, and so on. I've seen a few problems but nothing really serious; nothing more than with any other IDE. Though, like any vendor, they favour new features over fixing bugs, so yes, some bugs tend to stay idle for months or even years.
Either way, JetBrains decided to create a dedicated platform, RustRover, and to move the plugin internally to integrate the flow with their other tools. This makes perfect sense since it directly links a paying product to a specific plugin, whereas before it was mixed up with C++ and Kotlin tools, and all the work done on the plugin was not assigned to a defined product.
The problem is that there is no guarantee that the plugin will remain available for IntelliJ and CLion. They may restrict it to RustRover. They justify that by 'we’re still not certain whether users will need the plugin or whether a dedicated Rust IDE will be sufficient'.
Current users who are using IntelliJ or CLion for other developments, or worse, to integrate Rust with C++, for example, may have to find another solution in the future. They can install the new plugin and won't see any difference until RustRover is released one year from now. Or they can use RustRover, which is free during the EAP (Early Access Program).
So, while it's a sensible move, it has been poorly handled, leaving many users confused as to what to do next. When the time to renew their licence comes, what should they do? Keep IntelliJ/CLion, or wait until RustRover is available (and possibly buy both). Note that it's usually possible to adapt licences when they're still running, so I suppose it's not a huge problem, but it's very uncomfortable not knowing what to expect.
There's a silver lining for other users in general, who can now try RustRover for free. I have worked a little with it, and it's OK. A few minor bugs but nothing serious. They do really good products; I just wish they spent more time fixing bugs than bringing yet more features to attract new customers. 
3 Likes
I somewhat disagree with this view. It's not that they're unreliable, but sometimes you need to clean-up the temporary files or re-create the project. It's rare, and it never affected the outcome of the flow for me, only the UX. But yes, when this happens, it's annoying. I've had that with any other IDEs too, to be fair.
I don't feel that the plugin is 'weaker' either. They just brought macro expansion recently - I mean procedural macros, since the declarative macros were already well handled. After doing some comparison with VSCode, which uses rust-analyzer, I actually had more problems with it than with IntelliJ. On the other hand, some features like refactoring "{x}" in a println doesn't work (yet). Overall, it seemed quite balanced when comparing both, except the user-friendliness which was in clearly in favour of IntelliJ (partly because I'm used to it, granted).
Did you have issues or did you miss functionalities in comparison to another tool?
One problem remains in Windows: variable visibility in the debugger, which is based on an old customized version of LLDB. I think it's exacerbated by the difference of binary formats compared to Linux, and the specific Rust types. This means that some variables couldn't be inspected at breakpoints, but they're working on it. That being said, I had similar problems with VSCode, but not exactly the same problems because it has its own LLDB adaptation. So it's more a Windows format problem than anything else; I think it may get better when/if they make the jump to gdb.
I just meant in terms of the Rust functionality was fairly minimal in comparison to their other tools. Not bad, not amazing, not surprising given it's a free plugin.
1 Like
It is a big deal to me and as it was pointed out before, the uncertainty about a future plugin makes me concerned. I've been using the Rust plugin in CLion nearly every day for about a year and a half now, and I am happy with it. I find it reliable-enough and feature-rich-enough.
But probably most importantly, I'm already using CLion (paid), Pycharm (paid), and I was very happy that I did not need yet another IDE for Rust.
So, I'm looking forward to the improvements that this change will bring, and I'm also hoping that there will be a RustRover plugin for CLion
1 Like
Thx for this topic. I didn't know they plan to do smth for a rust. I gotta download it and have a try.
But for me PyCharm with installed plugin is the best choice at the moment. I used to write in Python, so this IDE is pretty comfortable for me. And the hottest thing for me there - if you want to launch a debug you just press a green triangle 
While in VS Code you always have to write 'cargo run'. They don't care about the lifecycle of your keyboard buttons...
I've been using IntelliJ IDEA for essentially all of my Rust coding (as it's what I'm used to in the Java land), and the JetBrains plugin has been a good tool. That said, it has certain issues that I believe are caused by an impedance mismatch between Rust and Java/Kotlin, particularly the very different compilation model. Even though the plugin's Cargo integration is quite adequate, certain Java-isms shine through in the interface, and there are some strange things like cargo fmt or cargo check not available in the editor's standard save actions (possibly the architecture is not designed with external tools in mind). The plugin comes with its own formatter which is not compatible with rustfmt.
Although I'm unhappy to see the free/OSS plugin sunsetted, I hope that RustRover will in the future deliver a first-class Rust experience that's not only good, but great.
1 Like
There's options to enable them both, but they aren't enabled by default.
Yes, there’s a separate custom "Run cargo fmt on save" option in the plugin settings but AFAICS it’s not available as a save action. I don’t think there’s a save action for cargo check either, only the option to enable continuous checking which reduces performance.
Where do these misconceptions come from? The IntelliJ plugin existed quite a while before rust-analyzer. It wasn't "based" in any way on RA, if anything RA is informed by experiences from IJ Rust.
2 Likes
It's been discussed in their blog. As you can still see in the now former Rust plugin Q&A, it shared some code with it:
Does the plugin use RLS, Racer, or Rust Analyzer?
The plugin’s language analysis is implemented from scratch, leveraging the IntelliJ Platform infrastructure for incremental analysis and indexing. However, IntelliJ Rust shares some code for procedural macros expansion with rust-analyzer.
What else did you think was a misconception? You wrote 'these misconceptions' (plural).
1 Like
I must say that, despite the way it was announced, I think it's great that JetBrains decided to make a product specifically for Rust. It's now there among a few other selected well-known languages such as Java, Kotlin, C++, Python.
I know that in reality it's the same platform as IntelliJ without all the Java extensions, which is also used for the other languages, and the same Rust plugin that has simply moved in their internal flow, but it's nice to see that it's successful enough to make it an official product.
As for the way it was announced, I just hope they realize enough people need the plugin to remain available in the other platforms. It may not be a big deal at all in the end.
2 Likes
Ah, I suspected that was it. But no, that doesn't mean it's 'based' on RA. The code in question is as far as I know just a separate binary that loads proc macros and passes commands to them through a JSON interface (since proc macros are dynamic libraries, some Rust code is necessary to run them).
What else did you think was a misconception? You wrote 'these misconceptions' (plural).
Sorry, nothing in your post, I just feel like I see similar claims on every RA vs. IntelliJ thread.
I said it was partially based on the same code, but I'll take that as an apology. Next time just ask for clarification; it's easier to discuss things rather than directly discrediting others' posts. 