4 ms·

I wholeheartedly agree. I tried Rust a few months ago and I was a little dumbfounded on how little 'modernity' I felt (regarding the IDE experience) compared t

by fb03 6y ago

I wholeheartedly agree. I tried Rust a few months ago and I was a little dumbfounded on how little 'modernity' I felt (regarding the IDE experience) compared to what several articles told me I should expect when using Rust with, for example, Visual Studio Code. Last month a project with requires the development of a high performance event collector came in, and I decided it was time for us to go to the Rust side. Again, I redid my dev setup with VSCode but this time I used rust-analyzer, and oh boy. "What, I now have practically instant inlay typings as I type a line of code??" e.g: "let x<: type> = ..." type inlay changing dynamically as I instantiated the object on the right hand side. So if you just like me got little winded at the sheer complexity of the whole Rust thingy and decided to wait a little more to dive in, let me tell you: rust-analyzer makes the whole thing way more palatable. Fast forward a WEEK later and I have a multithreaded message passing, postgresql consuming backend prototype to show the guys. It is very performant and consumes about 2 megabytes of ram while running and providing a continuous streaming websocket info feed to the to-be-developed dashboard that we are doing. Rust is awesome. and better tooling is going to make it soar even higher.

_bxg1 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.

by fb03 6y ago

_bxg1 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.