6 ms·

Rust analyzer is a game changer. Try it today if you haven’t already.

carlmr 6y ago
It is, with RLS I always felt it was what kept me from really liking programming in Rust. Since I don't program Rust every day it would be looking up everything. Now with rust-analyzer it's fast and exact enough that I can stay in the flow.
brundolf 6y ago
+1 Not only is it infinitely better than the default RLS, it's honestly one of the better IDE experiences I've ever had in any language period. In particular it has novel features like inline labels for inferred types, argument names when calling functions, etc.
- adamnemecek 6y ago
  I’m also very impressed with the rate of progress. They are moving very fast and I can notice a pretty big improvement regularly.
  - brundolf 6y ago
    Yes! I follow them on Twitter to keep up with the updates, it seems like there's a new feature every week Edit: Not sure why you're getting downvoted for making a positive, relevant, and factual statement. Sometimes I just can't figure out what goes on in people's heads when they downvote something.
  - Xylakant 6y ago
    As one of the managing people at Ferrous Systems, I’d like to mention that the pace of development is very much only possible because of the sponsors of the project, both individuals and corporate and some paid for feature development. This allows us to spend constant engineer hours on the project instead of what’s just left over as well as pay some money to contributors as well. A big Thank You to all of them.
    - brundolf 6y ago
      I'm curious how much your architecture also plays into it? I read a blog post you did a few months back comparing the big-picture architecture to others like IDEA, and it sounds fantastic. I've worked on observables-based/unidirectional data-graph style projects before (not compilers), and at least in my experience that paradigm really opens up head-room for productivity
      - Xylakant 6y ago
        I sincerely cannot comment on technical matters of RA, I wish I could. I’m just the guy that needs to balance the budget :)
        brundolf 6y ago
        That's fair! Keep up the great work :)
      - matklad 6y ago
        The higher order bit here is indeed funding: ides are deep and complex, they need a lot of focus. The internal architecture (or rather culture) of making the thing easy to work with is also an important factor. For example, this very document is a part of intentional “architecture for ease of development”. The fancier stuff like incremental compilation with salsa are liabilities: Rust is a complex language, so we have to pull complex tricks to make IDE works. This slows development down, so we compensate by focusing even more on build time, isolating complexity, and reducing interdependencies.
- kuschku 6y ago
  Rust analyzer gets really close to what the IDEA family of IDEs provides, but it's just not there yet. Personally I'd have preferred more community investment in an IDEA plugin.
  - ibraheemdev 6y ago
    The benefit of the LSP is being able to integrate with any text editor. Focusing on an IDEA plugin would leave behind the many developers who prefer VSCode, Vim, Emacs, etc.
    - kuschku 6y ago
      The LSP means every single language server has to reinvent the wheel again and again. It’d have been much more useful to build bindings for IDEA plugins so they could be integrated into arbitrary editors, especially as the IDEA plugins for most languages even after several years of LSP development are still superior. All in all it’s like the whole JVM vs. WASM, Java vs Electron story again, with someone deciding to reinvent the wheel but worse. There’s even bindings like https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server or https://plugins.jetbrains.com/plugin/10209-lsp-support https://plugins.jetbrains.com/plugin/10209-lsp-support to glue it all back together. It’d have been much simpler to reuse an existing ecosystem from the start.
      - brundolf 6y ago
        Presumably IDEA plugins have to be written in JVM languages, and use specific language-level bindings, and I would bet they're not very well decoupled from IDEA itself (which would make it really hard to write adapters to other editors). Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.
        kuschku 6y ago
        Sure, but imagine if the LSP designers had, as first project, just written a binding for IDEA. Then VSCode could've immediately had all the advantages of IDEA, and we'd be able to use both interchangeably.

It is, with RLS I always felt it was what kept me from really liking programming in Rust. Since I don't program Rust every day it would be looking up everything. Now with rust-analyzer it's fast and exact enough that I can stay in the flow.

brundolf 6y ago

+1 Not only is it infinitely better than the default RLS, it's honestly one of the better IDE experiences I've ever had in any language period. In particular it has novel features like inline labels for inferred types, argument names when calling functions, etc.

adamnemecek 6y ago
I’m also very impressed with the rate of progress. They are moving very fast and I can notice a pretty big improvement regularly.
- brundolf 6y ago
  Yes! I follow them on Twitter to keep up with the updates, it seems like there's a new feature every week Edit: Not sure why you're getting downvoted for making a positive, relevant, and factual statement. Sometimes I just can't figure out what goes on in people's heads when they downvote something.
- Xylakant 6y ago
  As one of the managing people at Ferrous Systems, I’d like to mention that the pace of development is very much only possible because of the sponsors of the project, both individuals and corporate and some paid for feature development. This allows us to spend constant engineer hours on the project instead of what’s just left over as well as pay some money to contributors as well. A big Thank You to all of them.
  - brundolf 6y ago
    I'm curious how much your architecture also plays into it? I read a blog post you did a few months back comparing the big-picture architecture to others like IDEA, and it sounds fantastic. I've worked on observables-based/unidirectional data-graph style projects before (not compilers), and at least in my experience that paradigm really opens up head-room for productivity
    - Xylakant 6y ago
      I sincerely cannot comment on technical matters of RA, I wish I could. I’m just the guy that needs to balance the budget :)
      - brundolf 6y ago
        That's fair! Keep up the great work :)
    - matklad 6y ago
      The higher order bit here is indeed funding: ides are deep and complex, they need a lot of focus. The internal architecture (or rather culture) of making the thing easy to work with is also an important factor. For example, this very document is a part of intentional “architecture for ease of development”. The fancier stuff like incremental compilation with salsa are liabilities: Rust is a complex language, so we have to pull complex tricks to make IDE works. This slows development down, so we compensate by focusing even more on build time, isolating complexity, and reducing interdependencies.
kuschku 6y ago
Rust analyzer gets really close to what the IDEA family of IDEs provides, but it's just not there yet. Personally I'd have preferred more community investment in an IDEA plugin.
- ibraheemdev 6y ago
  The benefit of the LSP is being able to integrate with any text editor. Focusing on an IDEA plugin would leave behind the many developers who prefer VSCode, Vim, Emacs, etc.
  - kuschku 6y ago
    The LSP means every single language server has to reinvent the wheel again and again. It’d have been much more useful to build bindings for IDEA plugins so they could be integrated into arbitrary editors, especially as the IDEA plugins for most languages even after several years of LSP development are still superior. All in all it’s like the whole JVM vs. WASM, Java vs Electron story again, with someone deciding to reinvent the wheel but worse. There’s even bindings like https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server or https://plugins.jetbrains.com/plugin/10209-lsp-support https://plugins.jetbrains.com/plugin/10209-lsp-support to glue it all back together. It’d have been much simpler to reuse an existing ecosystem from the start.
    - brundolf 6y ago
      Presumably IDEA plugins have to be written in JVM languages, and use specific language-level bindings, and I would bet they're not very well decoupled from IDEA itself (which would make it really hard to write adapters to other editors). Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.
      - kuschku 6y ago
        Sure, but imagine if the LSP designers had, as first project, just written a binding for IDEA. Then VSCode could've immediately had all the advantages of IDEA, and we'd be able to use both interchangeably.