I've been digging more into Rust, and things not working because I forgot to import the trait drives me bonkers. Like, you create a struct, you build an implementation, you implement a trait on it, you try and use it in another module, you can't, you feel like you must have goofed something, you hack around for an hour, oh you remember you forgot to import the trait you already implemented, you open up HN in a fury.... Is there a really important reason rustc doesn't know what traits are implemented on what structs? It can't be a dependency graph thing, it has to know about the struct in the first place.
I suggest you start reading the compiler error messages as they say exactly what trait is missing, no need to waste an hour.
For example for this code:
trait Foo {
fn foo(&self) {}
}
struct Bar;
impl Foo for Bar {}
mod test {
use super::Bar;
fn test() {
Bar.foo();
}
}
22 | Bar.foo();
| ^^^ method not found in `Bar`
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
|
20 | use crate::Foo;
|
A less condescending way to say what you said is, "oh they're pretty clear in the compiler output, are they buried or something?" And then I would say that in the linter in Vim, you only get the "method not found in Bar" which could be all kinds of things.
This seems like you’re using a relatively uncommon tooling setup (no language server, some kind of inline vim errors rather than the command line), and expecting that to “just work.” As a user of arcane tools, it seems to me a slightly unreasonable expectation. If you’re not going to go down the “golden path” of using rust—analyzer, you’ll need to assume that your editor’s support for the language may be incomplete out of the gate and figure out how to supplement it. Even with rust-analyzer, the source of truth is always `cargo check` and friends, so I recommend getting super familiar with them on the command line, regardless of your editor setup.
Yeah no you're definitely right, I'm definitely not in the golden path for Rust dev. I guess my quibbles (which I would cop to being quibbles... I think anyway) are:
- I'm already using 'cargo check' as my linter (rustc doesn't understand modules, seemingly).
- My setup works for JavaScript/React/Svelte, SQL, C/C++, Python, and Go.
- It can't be the case that (Neo)Vim + Ale [0] is arcane. Also the link in "Tools" from rust-lang.org goes to the rust.vim repo, which defaults to Syntastic, which I'm pretty sure has the same issue.
I don't necessarily think I should extrapolate from my experience to a broader "Rust is different for little/no gain" critique I've made in the past, but I sure want to haha. And to kind of anticipate a little, I wouldn't blame Ale here because--again--it works for everything else.
But anyway, yeah I've mostly given up on linting and I just run 'cargo check' in a terminal buffer now. It's probably something as simple as adding a command-line argument to... idk cargo or rustc to make the additional "help" format a little more amenable to Ale? Maybe I'll take a crack at it when I get some time.
cargo/rustc can already provide all its output as structured json, including the appropriate byte position to apply substitutions suggested in help blocks.
I'm pretty sure that's already how it works yeah, then yeah maybe adding some smarts to ALE is the right thing to do here? Unclear without looking into it more.
I haven’t used ALE in a while, and my colleague who uses vim uses CoC, but as far as I understand, rust-analyzer should “just work” with ALE. You may need to install rust-analyzer (via cargo) and tell ALE to use it, potentially? There’s an older and not well maintained language server called RLS. I would be surprised if ALE defaults to that one, but that could be part of why you aren’t getting great tooling out of the box if so.
I did find this blog post, which seems to suggest there may be a bit of extra config required to get rust-analyzer going with ALE: https://petermalmgren.com/rc-batch-day-9/
Yeah I think maybe I'll just come around to rust-analyzer? My experiences with language servers has been really spotty: they lose the state, eat CPU, want to autocomplete everything, etc. But idk, if it's a "this is the way" thing, I guess part of learning is adopting the customs. Just feels a little disappointing I can get by with like goimports/gofmt/go vet in Go, but there's no analog in Rust.
Oh no, the nice thing about it is you can basically configure it to do whatever you want. You can choose linters or fixers, lint/fix on save or on a configured "I've left insert mode" lag, etc. etc. It's actually really amazing [0].
One of the things I've really enjoyed about the Free Software ecosystem is choice, like mostly before Rails the attitude was "we don't presume to know the best anything, here are some options." I'm not saying there aren't tradeoffs (complexity, bitrot, 7 half-baked options vs. 1 incredible one), only that I kind of low-key resent the "opinionated" software that's out there. I guess I don't really see it as opinionated (like I think Rails' convention over configuration was actually a pretty good idea and exemplifies the "execute" phase of the explore/execute cycle of tooling), I see it as "flashy and targets the 80% use-case to get mindshare".
To be clear, I don't think rust-analyzer is that opinionated or flashy or lazy. I think it's awesome. But Rust's linting story is essentially "why would you use anything besides rust-analyzer, language servers are awesome and have no downsides." Which like, yeah they do.
Oh cool I didn’t know that ALE was so flexible, thanks!
And yeah rust-analyzer is definitely the happy path, but if you were trying to get by without a language server (not going to lie on a very large rust project rust-analyzer’s RAM usage can get up there), I think that `cargo check` output properly parsed and displayed in your linter would probably get you a huge portion of what you need. Between that and rustfmt, I think the only thing you’d be missing would be go to definition and that kind of thing (but you can set that up with a ctags-style thing or just replace with fuzzy grep).
In fact, before I figured out how to get rust-analyzer working in emacs, I used a setup where `cargo check` ran on save, and the output showed up in flycheck. From what you said about ALE, it sounds like you could set it up the same way. The main thing would be making sure there’s a way to get the FULL output of `cargo check`, probably not inline because there tends to be a lot of it. But e.g. with emacs I get error underlines that show the first part of the error, and then I can expand that in a popup window, or run cargo check, which opens cargo check in another buffer, with the output parsed so that if I press enter on an error, it brings me to the location in the code.
All of which is to say that it is doable! Maybe it would just take some extra ALE configuration, since the defaults are probably oriented towards people who are using rust-analyzer.
If you’re using rust-analyzer in your editor of choice, it will often suggest and auto-import traits when you try to use their methods with the trait not in scope. It knows, based on the dependency graph and your own code, all of the traits that could provide a method.
I use rust-analyzer in emacs, but it’s available in any editor that supports language servers.
With my setup, I’ll start typing a method, get a completion for the trait method I want with the trait indicated, and select the completion. The trait is then automatically imported and the method is completed.
rust-analyzer is a language server, which (along with autocomplete and maybe infuriatingly) I'm not into. I think this mostly reinforces Eli's point, which is broadly that you need a lot of editor support to use Rust reasonably ergonomically.
I think the sibling comment pointing out that the compiler errors tell you exactly what trait you need is for you then! You can get them with just a `cargo check`, no language server required.
Haskell automatically imports all typeclass definitions (equivalent to traits) when you import a module, so you sometimes see lines like
`import Foo.Bar ()`
Which looks like it's just importing nothing at all (`()`) but is actually pulling in some traits and nothing else.
You don't see this often because "orphan instances" (instances defined in a file besides the location of the trait definition or the type definition) are discouraged, but they do occur.
I had also thought that there was a reason one could need that pattern to import instances even in the absence of orphans, but on reflection I think I was mistaken.
