5 ms·

Yes. And the thing is, because Rust is such a complex-to-compile language, and because there's all this discussion around its slow compilation times that they'r

by _bxg1 7y ago

Yes. And the thing is, because Rust is such a complex-to-compile language, and because there's all this discussion around its slow compilation times that they're working to improve, I just assumed the whole time that "well I guess this is the cost of having such a powerful type system". I didn't question how terrible the editor experience was. But now I see how much better it could've been! I know the Rust team is hard at work, and I know they have a lot on their plate, and I'm very grateful for the work that they do. But I think it was a mistake to de-prioritize the editor experience for so long. It may have permanently turned off lots of people to Rust because they tried it and assumed the language was just too hard, when in reality they were flying blind. The compiler messages may be known for being great, but many people, especially newer devs figuring out a language, don't sit there with a compiler open while they explore what is and isn't allowed. There's much more to the dev experience than the compilation experience.

steveklabnik 7y ago
There was no conscious choice to de-prioritize IDE integration. Folks have been working on it for a long time; the rls has been on the stable distribution since september 2018, for example. There is always more work to do than there are hands to do it. It is not-trivial to re-architect a near-million LOC compiler, while also still doing all of the other things that the project needs.
- _bxg1 7y ago
  Apologies if I came off as ungrateful, that was not my intent. I don't know the inner-workings of the project's prioritizations; I just, from the outside, haven't seen much movement on the language server in the time I've been using Rust and assumed it was because some of the other (many!) things that were being worked on had taken attention away from it.
  - steveklabnik 7y ago
    It's all good; I think in some cases it's a distinction without a difference. Like, it is true regardless of the why, we have had a less than stellar IDE experience. Saying "we do care about this" only does so much to help; it gives you hope for the future, but doesn't change the facts on the ground.
oconnor663 7y ago
I'm not a compiler writer myself, but my impression is that designing a compiler "the traditional way" and designing one "the IDE way" look really different. Most people who learned to write compilers 10 or more years ago learned the traditional way. As a new language, Rust benefited from a lot of obvious-in-hindsight things, but "design your compiler for an IDE first" just hadn't reached quite the same level of obviousness by 2010.
- munificent 7y ago
  You are right. Even today, my impression is that most CS students taking compilers and PL courses are still taught in the "batch mode compile the world" way. Most textbooks still assume that too. It's somewhat understandable because the way you architect a compiler for an IDE is a lot more complex. It's basically everything that's hard about a compiler plus everything that's hard about data validation, and everything that's hard about caching and cache invalidation. But, yeah, there's a big gap between industry and academia with regards to how to architect an IDE/compiler.
  - vaylian 7y ago
    I think IDEs make things look more complicated than they actually are. Especially new students have trouble understanding what the difference between a programming language and a programming environment is, because they are exposed to them as one unit.
- _bxg1 7y ago
  As someone who knows very little about compiler implementation but has some interest in it, I'm curious what makes the difference between the two in terms of architecture
  - pjmlp 7y ago
    Basically the IDE one needs to take into account that your program is broken all the time, yet you want code completion for everything else that is actually correct. Also it needs to respond immediately after asking for completion, as anything beyond 2s is frustrating development experience. You also want to get real time errors and warnings, just for the parts that are actually broken, not a wall of text like many batch compilers that fail to understand the remaining of the file. Also you want to be able to do code refactorings, regardless of the compilation state. So basically you want a Smalltalk/Lisp Machines like experience. Anders has a nice interview about this, https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg...

by _bxg1 7y ago

steveklabnik 7y ago

There was no conscious choice to de-prioritize IDE integration. Folks have been working on it for a long time; the rls has been on the stable distribution since september 2018, for example. There is always more work to do than there are hands to do it. It is not-trivial to re-architect a near-million LOC compiler, while also still doing all of the other things that the project needs.

_bxg1 7y ago
Apologies if I came off as ungrateful, that was not my intent. I don't know the inner-workings of the project's prioritizations; I just, from the outside, haven't seen much movement on the language server in the time I've been using Rust and assumed it was because some of the other (many!) things that were being worked on had taken attention away from it.
- steveklabnik 7y ago
  It's all good; I think in some cases it's a distinction without a difference. Like, it is true regardless of the why, we have had a less than stellar IDE experience. Saying "we do care about this" only does so much to help; it gives you hope for the future, but doesn't change the facts on the ground.

oconnor663 7y ago

I'm not a compiler writer myself, but my impression is that designing a compiler "the traditional way" and designing one "the IDE way" look really different. Most people who learned to write compilers 10 or more years ago learned the traditional way. As a new language, Rust benefited from a lot of obvious-in-hindsight things, but "design your compiler for an IDE first" just hadn't reached quite the same level of obviousness by 2010.

munificent 7y ago
You are right. Even today, my impression is that most CS students taking compilers and PL courses are still taught in the "batch mode compile the world" way. Most textbooks still assume that too. It's somewhat understandable because the way you architect a compiler for an IDE is a lot more complex. It's basically everything that's hard about a compiler plus everything that's hard about data validation, and everything that's hard about caching and cache invalidation. But, yeah, there's a big gap between industry and academia with regards to how to architect an IDE/compiler.
- vaylian 7y ago
  I think IDEs make things look more complicated than they actually are. Especially new students have trouble understanding what the difference between a programming language and a programming environment is, because they are exposed to them as one unit.
_bxg1 7y ago
As someone who knows very little about compiler implementation but has some interest in it, I'm curious what makes the difference between the two in terms of architecture
- pjmlp 7y ago
  Basically the IDE one needs to take into account that your program is broken all the time, yet you want code completion for everything else that is actually correct. Also it needs to respond immediately after asking for completion, as anything beyond 2s is frustrating development experience. You also want to get real time errors and warnings, just for the parts that are actually broken, not a wall of text like many batch compilers that fail to understand the remaining of the file. Also you want to be able to do code refactorings, regardless of the compilation state. So basically you want a Smalltalk/Lisp Machines like experience. Anders has a nice interview about this, https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg...