The rust-analyzer team writes about the Rust language server, covering its architecture, parsing, macros, and project plans.
HN commenters recommend rust-analyzer as an excellent, open-source IDE experience for Rust and cite the blog page listing companies that funded its development.
Yes, the language there is Zephyr ASDL [1]. I actually changed this:
Dict(expr* keys, expr* values)
to
Dict(List[expr] keys, List[expr] values)
in our fork for https://oilshell.org/ , and it made a lot more sense to contributors.
It's funny how "sticky" syntax is -- two contributors ALSO read * as "pointer" ! So I changed it to be consistent with MyPy syntax earlier this year, and now I think I should have done that a long time ago.
(It would also make sense to change it to keys: List[expr], as that's the Python 3 syntax for types)
---
The funny thing is that while the web page says "Abstract Grammar", I would not call Zephyr ASDL a grammar.
Python has a separate Grammar/Grammar file, that is distinct from this file Python/Python.asdl.
A grammar describes a set of strings, and that's not what ASDL does.
It describes the data structure that the valid strings get transformed to after parsing, and there is not a 1:1 correspondence (e.g. due to the difference between a CST and AST, and other post-parsing validation).
I mentioned that here: https://www.oilshell.org/blog/2016/12/11.html#it-describes-a-data-structure-not-a-language
(Pretty sure "ungrammar" from rust-analyzer is nodding at this -- https://rust-analyzer.github.io//blog/2020/10/24/introducing-ungrammar.html -- it's "ASDL for concrete syntax trees", i.e. it's not a grammar because it doesn't describe strings; it describes trees)
[1] https://www.oilshell.org/blog/tags.html?tag=ASDL#ASDL
On paper, but it sure doesn't feel like it when trying to use it.
It's nearly impossible to find out which of the umpteen repositories contains the source for the class you're trying to understand, and MSDN won't be of much help. Much of the standard library also has a bunch of decoy source files that only contain signatures and/or mocks, so it's a pain to find the real version.
OmniSharp has a "go-to-source" option, but you only get the real source if it's in the same solution. Otherwise you only get signatures. Try giving Metals[0] or Rust-Analyzer[1] a shot, this stuff is night-and-day.
The official debugger (vsdbg) only works in VS and VSCode (and explicitly not in FOSS builds of VSCode). There is netcoredbg[2], but I still haven't figured out how to convince Emacs to use it. This wouldn't be as much of a problem if the culture wasn't so hostile to printf debugging (for example, ~nobody bothers to implement helpful ToStrings).
There is a heavy cultural bias towards MS libraries, regardless of their merits (ASP.Net Core, DI hell, EFCore, etc). See [3] for an.. interesting example.
OmniSharp has a habit of giving up randomly, giving useless error messages, and most GH issues consist of people repeating "+1", until there is a one-liner about how an update fixed it. Root cause analysis, what's that?
[0]: https://scalameta.org/metals/
[1]: https://rust-analyzer.github.io/
[2]: https://github.com/Samsung/netcoredbg
[3]:…
I’m curious, given salsa’s[1] so-far quite-effective use of the incremental computation (Adapton/Incremental/Bonsai), if you could elaborate on some of the pitfalls there for UI specifically. The primary salsa use case so far (in rust-analyzer[2]) is obviously fairly different from the pure UI use case, as it’s allowing other things to do the work on the UI and is using it purely for the incremental computation of compilation results, which are a very different set of constraints from UI painting. But at that point, my own knowledge runs out: thus the question.
[1]: https://salsa-rs.github.io/salsa/
[2]: https://rust-analyzer.github.io/
This is particularly of interest to me because I work day in and day out with what is to my knowledge the only application of the incremental computation approach to browser UI,[3] and colleagues and I have talked about what it would take to reimplement in Rust—what the tradeoffs would be, where the problems would emerge, etc. I suspect part of the issue is that the constraints of using the DOM informs a lot of the design considerations in the space, whereas implementing from scratch gives very different tradeoffs?
[3]: https://v5.chriskrycho.com/journal/autotracking-elegant-dx-via-cutting-edge-cs/
Good questions. Clear, organized. Please share what you find as you compare existing languages.
Regarding (F) -- this is partly about (a) the language's interop story and partly about (b) building a community of people that gets along, get things done, and strikes a balance being independent enough to generate something useful and different while being open to compromising for industry adoption (which often means "slowing down" and stabilizing when the time is right).
(a) There are a lot of great ways to ease editor integration. One is to build/maintain language server / analyzer. See https://rust-analyzer.github.io. Another is to share and maintain a formal grammar.
(b) I've been very pleased with my interactions in the Rust community in this regard. There are certainly many ingredients to mix in ways that make sense for a particular community. In my view, the key aspects are (i) be clear about what your language community stands for; (ii) strike a balance between fairness, transparency, and privacy in how you get there; (iii) build in accountability and feedback loops
Just to make the MVP simpler.
I note in the caveats that the current approach is to recompute everything whenever even one file is changed. But that’s probably not sustainable, as I admit myself in https://azdavis.net/posts/pl-idea-tooling/ :
> As an example, it would be unsustainable if, every time we changed a single function’s body, the language server had to re-typecheck the entire codebase. This might work for an initial proof-of-concept on a small codebase, but for large ones, the responsiveness of the language server would drop precipitously.
If I get around to addressing this, I’d probably use salsa and/or follow along this post: https://rust-analyzer.github.io//blog/2020/07/20/three-architectures-for-responsive-ide.html
I tried helix a few months ago. Before that, I gave it a try several times. The editor is fine, but I always go back to vim and vscode for these reasons:
- In vim, I can use vim-fugitive [1] to easily run git add and git commit. Not sure if helix has that level of integration with Git (I like the gutter, though). I know that we can use tools like lazygit within Helix, but I think :Gw and :Git commit are more ergonomic.
- I prefer vscode to code in Rust because of rust-analyzer [2]. That plugin gives me type type annotations along each variable. Helix can also provide some hints, but not that many as rust-analyzer.
[1] https://github.com/tpope/vim-fugitive
[2] https://rust-analyzer.github.io/book/vs_code.html