It's absolutely not an alternative to RustEnhanced. Sublime-LSP + Rust-Analyzer complement RustEnhanced, adding Language Server functionality. They don't conflict in any way.
Source: me, a contributor to both RustEnhanced and Sublime-LSP
You’re right, I was mistaken (and too late to edit my comment).
Out of interest, is there a page anywhere explaining the difference between RustEnhanced and Sublime-LSP + Rust Analyzer? I’ve got both installed, but when I enable Sublime-LSP + RustAnalyzer the experience and functionality is different enough that I assumed it was overriding RustEnhanced.
The cargo/rustc output is optimized for the batch operation nature of cli tools, giving as good an output as possible in such an environment. rust-analyzer has the potential of showing even better output (modulo the editors' capabilities, vscode for example doesn't let you write arbitrary html in tooltips) because of the immediacy and allowing people to click on things as they explore solutions. I think that the experience is not quite there, but there's no reason it can't be as good if not better than what we have now in the cli.
Rant: In my ideal world editors would allow me to write a plugin that mimics the current cli output fairly close, with overlays and tooltips fully controlled by the plugin. Imagine clicking on the red squiggles and a pop-up with the cli output, but with syntax highlighting, editable and click to go to line.
There is no doubting the power of that stuff to speed up what you're doing, but I think it also comes at a cost of understanding. I never really learnt java until I didn't have eclipse holding my hand all the time. I just wonder how much our love of shiny things leads to the Eclpise and Visual Studio problem, when we build massive amounts of software which essentially does nothing but gives users another way to do something they could have done anyway if they actually understood it. I dunno. It's complex.
But these tools also can work as a way to teach the user about what alternatives they have that they would otherwise not know about. It doesn't remove the responsibility of the user to learn, it just adds another opportunity to do so.
If you look at the structured suggestions that rustc gives, the message succinctly explains what concept you're changing, giving you some keywords that you can Google for, and the transformed code allowing you to continue without having to consider the implications necessarily. You can't get that immediacy from a book.
will tell you that Iterator is a trait (so you should use the appropriate style and mark it with dyn to make it clear) and that it has an associated type that must be specified (showing you the syntax you'd need)
warning: trait objects without an explicit `dyn` are deprecated
--> src/main.rs:1:13
|
1 | fn foo() -> Iterator {
| ^^^^^^^^ help: use `dyn`: `dyn Iterator`
|
= note: `#[warn(bare_trait_objects)]` on by default
error[E0191]: the value of the associated type `Item` (from trait `std::iter::Iterator`) must be specified
--> src/main.rs:1:13
|
1 | fn foo() -> Iterator {
| ^^^^^^^^ help: specify the associated type: `Iterator<Item = Type>`
Then it will tell you that you cannot ever return a trait directly, because its unsized (?Sized), but the compiler peeks at the function body and checks which of the 3 solutions could apply. In this case, it introduces you to the impl Trait feature (opaque type that implements a given trait):
error[E0746]: return type cannot have an unboxed trait object
--> src/main.rs:1:13
|
1 | fn foo() -> dyn Iterator<Item = usize> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
|
= note: for information on `impl Trait`, see <https://doc.rust-lang.org/book/ch10-02-traits.html#returning-types-that-implement-traits>
help: use `impl Iterator<Item = usize>` as the return type, as all return paths are of type `std::vec::IntoIter<{integer}>`, which implements `Iterator<Item = usize>`
|
1 | fn foo() -> impl Iterator<Item = usize> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
But if the implementation were different it would show you how to use boxed trait objects:
error[E0746]: return type cannot have an unboxed trait object
--> src/main.rs:1:13
|
1 | fn foo() -> dyn Iterator<Item = usize> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
|
= note: for information on trait objects, see <https://doc.rust-lang.org/book/ch17-02-trait-objects.html#using-trait-objects-that-allow-for-values-of-different-types>
= note: if all the returned values were of the same type you could use `impl Iterator<Item = usize>` as the return type
= note: for information on `impl Trait`, see <https://doc.rust-lang.org/book/ch10-02-traits.html#returning-types-that-implement-traits>
= note: you can create a new `enum` with a variant for each returned type
help: return a boxed trait object instead
|
1 | fn foo() -> Box<dyn Iterator<Item = usize>> {
2 | if true {
3 | Box::new(vec![1, 2, 3].into_iter())
4 | } else {
5 | Box::new(None.into_iter())
This is not perfect, as it is a complex topic and its done in the cli output, but there's no reason that having this level of interactive learning in rust-analyzer wouldn't be a net positive.
Quicker feedback. It'll tell you in-line the issue (if any) is with your code as soon as you save the file. cargo will tell you the same thing but it takes longer.
In addition, this provides type annotations inline and other IDE features like go-to-definition and find-usages.
So the "move from" didn't really make sense to me. You wouldn't stop using cargo (rust's package manager) to use rust analyzer (a code analysis / code completion tool).
