I realize that Kotlin/IDEA are both developed by JetBrains, and thus it has an amazing experience. I just want to know what Rust/* experience comes closest to it.
what I like about Kotlin/IDEA experience:
red squiggly lines
if there is a syntax error, I get a red squiggly line
if there is no syntax error, there is no red squiggly line
in Rust/IDEA, I get both false positive red squiggly lines and false negatives (and thus constantly hitting "cargo check")
auto completion/suggestion
in IntelliJ, as long as I don't have a red squiggly line, I can type "object." and BAM, < 100 ms, I get all the auto completion choices
in Rust, this is hit or miss, I never know if it's going to work or not; sometimes that Rust/IDEA plugin just simply can't infer the type, ... and I'm trying to figure out why it can't infer the type (since without the type, it can't give me auto suggestions)
Now, I realize Rust macro expansion throws a wrench into this setup -- but I am wondering -- what is currently achievable with Rust/* ?
Actually, there's a pretty good plugin for CLion, which is an IDEA editor made by Jetbrains. You can also use the plugin with IDEA or any other Jetbrains product, but CLion is the only one that provided debugging.
Just go to your settings and search for the rust plugin.
I'd also suggest looking at https://areweideyet.com/, which is a great summary of where we are in the IDEA world.
I use CLion and haven't had any problems yet, it does all the things that you have mentioned, with varying degrees of success. It's still an active product.
And, as I read your post for the second time, I gather you are using the Rust plugin in Intellij's IDEA. I have been using CLion and haven't had any of the problems you mentioned. No false positives or false negatives. The IDE infers types correctly, though I often explicitly annotate types anyway (because that's what we do at work, its habit).
Official Support for Open-Source Rust Plugin for IntelliJ IDEA , CLion, and ... both plugins started as Kotlin projects, even before Kotlin was released.
The plugin is improving constantly, but Rust is a pretty "big" language, and constantly in motion, and it takes a while to cover everything.
In my experience, if it fails to detect the type, usually it's because:
1- You didn't "import" the mod you are editing from main.rs or lib.rs.
2- You are inside a macro (definition or call).
3- The compiler still has too few info to infer the type, so the IDE doesn't know what to use.
4- The type is in an external crate and either the crate was not downloaded/compiled yet or the cache wasn't updated yet. In the latter case, closing and reopening the IDE works.
There are other cases (it's evolving) but they are getting rare.
Personally, I use CLion (or Idea, it's mostly the same) for Rust dev and the other tools in the suite for basically everything: Go, PHP, Javascript, Android, Python, markdown, HTML and CSS, etc. Thanks to the scratches I even stopped using a separate editor to quickly edit files not related to the project I am working on.
I quite agree that the current experience is quite frustrating but I have good hope that this aspect of the Rust ecosystem will be a priority in 2019. I'm having hard time trying to convince my company to use Rust and this aspect will be a big point from people against it…
In case of IntelliJ, it's not about Rust stabilizing, it's about actually re-implementing the bulk of the compiler in Kotlin. That said, I also estimate the time from the current state to "nothing too fancy, but basic expected stuff works reliably" as a couple of years as well. Usual disclaimer that software estimates are right next to statistics in "lies, damned lies, and statistics"
It's interesting that Kotlin was developed with IDE requirements in the mind. It results not into things that Kotlin "has", but into things that Kotlin "has not". For example, macros =)
Currenlty, poor macros support is a source of the most problems in IntelliJ-Rust (including performance/latency problems). I'm working on macros support about a half of year and OH MY GOD I'M SO TIRED! Previously I wrote IJ-Rust's type inference engine and I want to say that it's nothing compared with macros!
I'd say, Rust is definitely not designed to simplify the life of IDE developers =)
But I'd not say that it isn't possible to achieve Kotlin-level IDE experience. It just requires a lot of resources.
For example, work on next large update of macros support is close to completion. So stay tuned =)
Kotlin is built directly on Java. It's possible to call it Java 2.0. The difficulties of designing a language is not present to nearly the same extent as with Rust. Hence why Rust is only now coming around to implementing a IDE-consistent compiler implementation. Check the introduction here for an intro into how Kotlin and Rust are entirely different things https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
I'd like to respectfully disagree with some points raised here.
I don't think it makes much sense to compare language design complexities between Rust and Kotlin: they target different niches. However designing a language like Kotlin is hard, precisely because you have to maintain comparability with existing runtime (JVM) and language (Java). Here are some features of Kotlin whose shape I think is explained at least in some part by comparability with Java:
Immutability and null-safety by default, despite the fact that Java has constructors.
Inline functions, which are a way to sneak in reified generics into a type-erased runtime
Readonly collections hierarchy which exists to give an easy functional semantics to existing java collections library.
Similarly, I don't think that differences in IDE support should be attributed language design difficulties. I think this is mostly a historical accident. For Kotlin, IDE support was a major design goal from the start, because it was developed by JetBrains. For Rust, IDE support (more specifically, code analysis as you type support, as opposed to batch oriented tooling like Cargo or clippy or rustfmt) does not seem to be the initial goal, probably because it was developed with C++/Ocaml in mind, which are difficult to write good IDE for as well.
Also, I expect @vlad20012 to be one of the most knowledgeable people about the similarities and difference of these two languages
I use the Rust plugin in CLion and the general experience is okay (intellisense, underlined errors etc.) but there are definite weakpoints. Macros are like a blackhole for the intellisense for example. Debugging Rust is also quite basic because the front end doesn't prettify variables as much as it should.
One of the problems I have with VSCode is that I haven't figure out a way to see the contents of a HashMap in the debugger. Is that a problem with CLion?
