If you haven’t yet used rust-analyzer, immediately go and try it out. The developer experience is much better than RLS, particularly for larger projects.
One question I’ve had for some time: what exactly is the relationship between Ferrous Systems and the Rust core team? The most important part of this article - the call for sponsors - calls out the former, but I would think Mozilla would also be greatly motivated to sponsor this work. (If they haven’t already?)
Ferrous Systems is a private consulting company that specialises on Rust and sponsors some community projects such as Rust-Analyzer. I don't think the company has any "official" relationship with Rust governance. However, Florian Gilcher and Aleksey Kladov who both work at Ferrous Systems are active community members and also members in some Rust teams.
It's generally thought in the Rust community that the community benefits from diversifying the pool of stakeholders and also commercial players. Rust doesn't want to identify too hard as "Mozilla's language".
Edit: Forgot to mention: There isn't currently any legal body such as "Rust foundation" so it's hard for the Rust project itself financially sponsor this kind of project. It's mostly either Mozilla or then some "third party" player.
It's hard to understate how much of a difference rust-analyzer makes. Rust is a complex language, and the compiler is very pedantic. This makes it very hard for beginners--even with lots of systems experience--to scan lengthy compiler error messages, to locate the relative line that it is complaining about (necessary for context), and to try to make sense of the error (Rust error messages are very good, but good messaging can only get you so far with respect to difficult concepts like lifetimes). This feedback loop is on the order of minutes, and it only starts when the user invokes `cargo build` or similar. Rust-analyzer dramatically shortens this feedback loop by _immediately_ highlighting errors: fewer changes since the last known good state, and it visually points you to the errant expression.
For me, this (coupled with non-lexical lifetimes and error handling improvements) made the difference between "I can't justify using Rust because I can't be sufficiently productive" and "the productivity hit is sufficiently small that it makes good sense to use Rust for some of the applications I write, especially factoring in its rate of improvement".
From https://rust-analyzer.github.io/:
"The following companies contributed significantly towards rust-analyzer development: Ferrous Systems, Mozilla, Embark Studios, freiheit.com".
I imagine that it's evolving quite quickly, and it's also the sort of thing where it's probably both fun and fine to stay close to the bleeding edge. Should I just periodically download the latest released binary, or is it worth building from master?
It seems good! I wanted to play with Rust WASM things but it doesn't seem to help with completion of sources from wasm-bindgen's canvas 2d context for example. :/
My reading of the linked references indicate that the system is not using Prolog or even Horn clauses. They are using a logic inference engine, but it isn't a Prolog system.
This is the future of all systems/OS programming in my opinion.
My other goals for 2030:
- RISC-V ubiquity
- RedoxOS on all major archs
- Linux kernel maintenance shifting to at least 25% Rust code
Rust Analyzer is one of the biggest pieces that I think will get us there as far as compile times and beating out C++ ubiquity that is already in this space.
It's important to point out that rust-analyzer uses some bleeding edge features of the protocol, so sometimes certain things won't work as well in editors other than vscode. That being said, I believe the rust-analyzer author has indicated that he would fix that up to use more standard features if rust-analyzer becomes the officially recommended IDE backend.
I'm confused on what you're asking, isn't that exactly what the Language Server Protocol is? You can use RustAnalyzer as an LSP for Rust & Vim, I use RustAnalyzer also as the LSP for Rust & Kakoune.
Remember that not everyone is versed in all subjects all the time. This might be the first time they are finding out about the LSP, or it might be the first time they’ve found out the LSP works with vim. No reason to assume any of this.
Sure, but is what I asked not valid? I asked some questions, and said I was confused by their statement. If anything, I acknowledged this, which is why I wrote "Language Server Protocol" and not just the acronym LSP that they had to look up.
Yes, your first sentence can easily be read as (I am only exaggerating slightly) “how can you be so stupid to ask the obvious?” Short form online communication is hard.
If you’re on vscode it is probably not the moment to switch to rust analyzer. It doesn’t work that well compared to rls. It gets tripped up easily and stops working if your code has bugs. It also doesn’t format on save.
My experience has been very different, rust-analyzer works seamlessly in my VSCode environment, even moving from the remote WSL plugin to the remote SSH plugin. I've had zero issues with it, and it feels truly magical, when I first installed it and saw what it could do (and how fast it it) I was actually blown away. I really can't overstate how great it has been.
I can't speak to your experiences obviously, but based on mine I would recommend that anyone on VSCode gives it a shot immediately.
Not sure what you're using - rust-analyzer does support format-on-save (in fact it's actually a VS Code built-in, rust-analyzer just exposes a formatter for Rust files that then gets used by the built-in format-on-save feature)
Also compared to RLS it works much better on code with errors in, at least in my experience.
It seems there is more than one plugin for using Rust in vscode and they don't have the same level of support LSP and RA. It could be more clear which is considered "official" from RA's point of view. Also, one of the likely candidates only gained support for RA recently, in the last couple of versions.
In my understanding, Chalk's immediate goal is to be able to reproduce the existing trait system. Achieving that goal does not mean that GATs just automatically happen; they'll need to be implemented in Chalk, and then all the other polish work that happens with new major features needs to happen. There's a ton of work other than "chalk exists."
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).
One question I’ve had for some time: what exactly is the relationship between Ferrous Systems and the Rust core team? The most important part of this article - the call for sponsors - calls out the former, but I would think Mozilla would also be greatly motivated to sponsor this work. (If they haven’t already?)