Re:Rust Is Surprisingly Good as a Server Language
by steveklabnik on Monday July 13, 2020 @03:49PM
(#23824869)
> 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/ 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.
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/ 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.