4 ms·

> I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely

> I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. Where can I read more about this? What ended up happening?

steveklabnik 4y ago
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit: > RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment. > rust-analyzer uses a fundamentally different approach that does not rely on using rustc. In RFC 2912 rust-analyzer was adopted as the official replacement for RLS. These RFCs provide some more color. The long and short of it is, the RLS relied on a process where rustc would sort of pre-process your codebase, and spit out a "save analysis" file. RLS would read this file, and do its thing. rust-analyzer, on the other hand, doesn't use rustc at all(*), and instead analyzes your code on-demand, in an incremental style. The latter has many advantages in an IDE context. The * is there because part of the original idea is that rustc would end up producing some libraries that rust-analyzer would also use, allowing them to share code. Given that rustc has also been moving towards an incremental, on-demand architecture, this would be easier. I am out of the loop these days, but from the relative outside, this effort seemed to stall out. I don't really know why. Maybe it has been happening and just isn't really visible. Regardless of those details, rust-analyzer is very good. It's a shame the transition took so long, in retrospect!
- rektide 4y ago
  Very cool. Thanks for the links & write up!
nindalf 4y ago
I can't find the original link to his proposal, but I did send him a message on reddit asking if still had a link to it. The gist of it was, he felt the first attempt to make a Rust LSP (RLS) had the wrong architecture. It was basically running the Rust compiler in check mode and relaying the errors back. In his opinion an IDE needed a different, incremental architecture that stored state. It also needed to be much more tolerant of errors. He had already made a Rust IDE plugin in Java for JetBrain's IntelliJ-Rust plugin, and wanted to make a similar one in Rust. So he started the rust-analyzer project and it succeeded. Last year it became the official LSP of the Rust project. (https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...)

steveklabnik 4y ago

https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit: > RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment. > rust-analyzer uses a fundamentally different approach that does not rely on using rustc. In RFC 2912 rust-analyzer was adopted as the official replacement for RLS. These RFCs provide some more color. The long and short of it is, the RLS relied on a process where rustc would sort of pre-process your codebase, and spit out a "save analysis" file. RLS would read this file, and do its thing. rust-analyzer, on the other hand, doesn't use rustc at all(*), and instead analyzes your code on-demand, in an incremental style. The latter has many advantages in an IDE context. The * is there because part of the original idea is that rustc would end up producing some libraries that rust-analyzer would also use, allowing them to share code. Given that rustc has also been moving towards an incremental, on-demand architecture, this would be easier. I am out of the loop these days, but from the relative outside, this effort seemed to stall out. I don't really know why. Maybe it has been happening and just isn't really visible. Regardless of those details, rust-analyzer is very good. It's a shame the transition took so long, in retrospect!

rektide 4y ago
Very cool. Thanks for the links & write up!

nindalf 4y ago

I can't find the original link to his proposal, but I did send him a message on reddit asking if still had a link to it. The gist of it was, he felt the first attempt to make a Rust LSP (RLS) had the wrong architecture. It was basically running the Rust compiler in check mode and relaying the errors back. In his opinion an IDE needed a different, incremental architecture that stored state. It also needed to be much more tolerant of errors. He had already made a Rust IDE plugin in Java for JetBrain's IntelliJ-Rust plugin, and wanted to make a similar one in Rust. So he started the rust-analyzer project and it succeeded. Last year it became the official LSP of the Rust project. (https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...)