3 ms·

Mostly, that makes sense. I think the thing that doesn't make sense to me is that rust-analyzer seems to me to be a LSP - my mental model of it has nothing to d

by johnfn 6y ago

Mostly, that makes sense. I think the thing that doesn't make sense to me is that rust-analyzer seems to me to be a LSP - my mental model of it has nothing to do with codegen. And I thought that codegen and linking was the slow part in Rust (cargo check runs so fast!), so how could those gains be brought back to rustc? I'd bet other people have this misconception, too - maybe that should be highlighted on the rust-analyzer readme on Github. If rust-analyzer will eventually introduce those gains to rustc, that is fantastic news, and I'll be watching it with great interest! The improvement from RLS to rust-analyzer is exactly the type of improvement that brought Rust from the "fascinating tech demo" to "I could actually see myself using this day-to-day." And yeah, I'd love to read a blog that went into more detail. > working on individual PRs to make things faster. See https://blog.mozilla.org/nnethercote/ https://blog.mozilla.org/nnethercote/ for one of the largest contributors in this regard Yeah, I read through that too. He's my hero! :-) But the feeling I got when reading it was: "fast compile times" really need to be part of the DNA of a language. Let me explain what I mean. Some languages, like Go and TypeScript, have this in their DNA, and that means that every design decision and every addition to the language is considered seriously through the lens of compile time speed, and vetoed if it were too costly. But with Rust, the fact that there's one guy writing a blog post about some incremental wins he managed to chalk up just... doesn't seem like it's part of the DNA. If it is, why is it just one guy, and why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary? I could definitely be wrong here (sounds like I am and rust-analyzer is that big sweeping change). Thanks for all your great responses, by the way. I really appreciate it!

steveklabnik 6y ago
> Thanks for all your great responses, by the way. I really appreciate it! Any time. :D A couple more brief comments: > rust-analyzer seems to me to be a LSP Remember that LSP is a protocol, something/someone has to actually figure out the answers. Like, the LSP says "please draw the squiggles here", but something has to actually say "line 1, column 10, please". Doing that involves semantic analysis, which is what a compiler does. > And I thought that codegen and linking was the slow part in Rust It is the slowest part of the current architecture, but that doesn't mean that the current architecture is the best possible one. The RLS invoked the compiler, and then examined its output to say "line 1, column 10, please". And you said you saw the improvement with the architectural switch to rust-analyzer. Same thing. > "fast compile times" really need to be part of the DNA of a language. You are correct that, when push comes to shove, if there's a tension between, say, runtime speed and compile-time speed, Rust will choose runtime speed. Rust will not have compile speed as high up on the list of concerns as Go does. But it is important enough that we don't let major regressions happen, and actively pursue improvements where possible. https://perf.rust-lang.org/ https://perf.rust-lang.org/ for example, tracks this data over time for this kind of reason. > why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary? Well, again, it's not always either or. He's doing the incremental thing, and others are doing the big sweeping changes thing. His improvements land nearly every release, but the bigger projects take a lot longer. They work in tandem to make things better than they were before.

by johnfn 6y ago

steveklabnik 6y ago

> Thanks for all your great responses, by the way. I really appreciate it! Any time. :D A couple more brief comments: > rust-analyzer seems to me to be a LSP Remember that LSP is a protocol, something/someone has to actually figure out the answers. Like, the LSP says "please draw the squiggles here", but something has to actually say "line 1, column 10, please". Doing that involves semantic analysis, which is what a compiler does. > And I thought that codegen and linking was the slow part in Rust It is the slowest part of the current architecture, but that doesn't mean that the current architecture is the best possible one. The RLS invoked the compiler, and then examined its output to say "line 1, column 10, please". And you said you saw the improvement with the architectural switch to rust-analyzer. Same thing. > "fast compile times" really need to be part of the DNA of a language. You are correct that, when push comes to shove, if there's a tension between, say, runtime speed and compile-time speed, Rust will choose runtime speed. Rust will not have compile speed as high up on the list of concerns as Go does. But it is important enough that we don't let major regressions happen, and actively pursue improvements where possible. https://perf.rust-lang.org/ https://perf.rust-lang.org/ for example, tracks this data over time for this kind of reason. > why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary? Well, again, it's not always either or. He's doing the incremental thing, and others are doing the big sweeping changes thing. His improvements land nearly every release, but the bigger projects take a lot longer. They work in tandem to make things better than they were before.