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.
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.
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.
The whole idea of a "language server protocol" is relatively new. And it's why VSCode is absolutely killing it in a lot of spaces.
A "language server protocol" is ... kind of obvious? But it requires a lot of power behind it. It also requires languages whose grammars are optimized in such a way that they don't have to compile the universe to figure things out (see: C and C++)
How did IntelliJ handle things? Did they do something analogous?
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,
rustc already tries to do all of these strategies, but blows the latency budget because it still prioritizes correctness over everything else.
1) Parse all the code.
2) Assemble the set of all types.
3) Typecheck all the code.
4) Translate the parse tree into unoptimized machine code.
5) Optimize all that machine code.
This is oversimplifying things, as in practice there are intermediate representations between the parse tree and the machine code. And optimization itself usually involves multiple passes of different kinds. But anyway, the key point here is that, if you change any of the code, you have to run all of these steps all over again. (I'm oversimplifying again. Maybe you only have to rerun them for a given "compilation unit", but that's bad enough.) This is the opposite of what you want for an IDE. There, you want to say "I just changed this function. Please recompile the absolute minimum necessary to tell me whether my change works." To answer a question like that efficiently, you have to rearchitect the whole compiler from being pass-based to being query-based, so you can give it instructions like "please update the type of just this expression".
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.
Can’t wait for rust-analyzer to graduate as an even more fully featured LSP – it has the potential to really changes the daily life of thousands!
I played around with Rust these days and found it a bit hard to reason about things, because I was using a simple editor.
Thinking back to some of the RLS blogposts about the need for something like rust-analyser from about a year ago I'm pretty sure nrc (Nick Cameron) said it would take about 2-3 years to reach this point. However, I'd say rust-analyser has been usable and better than RLS for many months now.
As a newbie computer science major who "grew up" in the era of Eclipse/IntelliJ conversion, IntelliJ will never cease to amaze me in how much more productive I became with IDE tools and the general "power behind the compiler".
Mad props to the plugin interface JetBrains has provided and the novel solutions that have come out of this style of thinking that far outpaces the experience in something like Xcode.
For Rust I'm now using CLion and that's been wonderful as well. Kudos to the plug-in authors.
However I think its editor is subpar and not very customizable. I also dislike its simple vim mode.
I really wish I could pay for IntelliJ's backend with my desired editor. It's a shame IntelliJ didn't embrace LSP and work with the standard. I think eventually this will come to hurt them, because it just motivates those who want a better editor to build their own LSP backends.
I have already dropped IntelliJ for almost every language because the LSP servers have gotten so good. The only languages I'm unable to avoid are the big JVM languages (except for Clojure). But one day someone is going to build a great JVM LSP and then I'll drop my IntelliJ subscription once and for all.
I've been hoping that the scala guys tackle this issue soon:
> I was known for my annoying habit of stating how Smalltalk's IDE was better than anything I'd seen. No longer. For me IntelliJ was first leap forwards in IDEs since Smalltalk.
2 - No continuous indexing of source code, stuff is just there.
3 - During execution of REPL statements or debug sessions, an errors jump into the debugger, fix the issue and continue as if nothing had happened
4 - a REPL that integrates the code being written, with inline images and graphical representation of data structures
5 - The complete developer experience is available to the developer and can be customised at any time without rebooting it.
6 - Code components can be integrated into other documents as live objects (this is where OLE and Taligent got their ideas from)
I do think that the REPL workflow is way underappreciated and missing in Intellij. What I like about it is that it still focuses on working on semantic intent rather than editing text. In this way, it's similar in some sense to the idea of working on S-expressions rather than text.
After all I was asked for 5 and wrote 6, could keeping writing a few more.
(I'm managing the open collective and I'm so happy for all the support, in money or just in kind words)
I've been playing with Rust for the past couple of weeks, and I've really enjoyed the working with the language. The documentation and community are top-notch. The biggest downside from moving from a language like Java or Typescript (which I use in my day job) is the IDE experience. Things like code completion for other crates (which you'd take for granted in some of the other languages) don't seem to work.
I've also seen huge improvements in the plugin over the past couple of years, such that most stuff just works now. Still some issues with macros (a hard problem in general, limited refactoring support, and occasional analysis failures, but I find it's a hugely productive environment.
(Also, as a bit of history, Aleksey Kladov who was the main developer on the intellij rust plugin went on to create rust-analyzer.)
Don't know how to get around this :/
I was very hopeful about the bright future of language server, and its ability to solve that N^2'd problem between editors, addons, and languages. But, if it can't provide truly great experiences outside of Typescript (which has been my unfortunate experience), it does not bode well for the project.
I personally don't believe that NxM is a real problem. If you have an editor, which has bespoke APIs for providing completion, and a language server, which speaks bespoke protocol, binding the two together is not hard. A single person can do that and if, say, at least 1000 people use editor X with language Y, it doesn't seem like a waste of effort to me.
The problem is that writing a language server that works is hard. "Rewrite your entire compiler from scratch" kind of hard. Before LSP, only JetBrains delivered these kinds of compilers consistently. Notable non-JetBrains tools from before LSP era are Roslyn and Dart Analyzer.
The Dart Analyzer project is particularly interesting -- it's the same "separate server process speaking JSON" kind of architecture. The details of protocol are different (as it predates LSP) and it doesn't try to be language agnostic. Dart support in IntelliJ is powered primarily by this server.
In my mind, the main value of LSP is social: it pushes language designers and compiler writers to think about editing and refactoring incomplete code, which is a very different problem from compiling mostly correct code.
RLS was implemented using the compiler as a library, which meant it inherited the compilation model of the compiler, which isn't really well-suited for IDEs. That was done in full knowledge of that drawback.
The advantage for RLS is that it has perfect parity with the language.
This may be fixed by using rust-analyzers libraries within the compiler. RFC here: https://github.com/rust-lang/rfcs/pull/2912
> We build the rust-analyzer binary, an implementation of the language server protocol, which can provide a basic IDE experience for Rust today.
Also at times, when adding a new crate dependency to Cargo.toml or installing a rust-analyzer update, it seems necessary to reopen the VSCode project (not restart VSCode itself) to get it to work again.
This said RA has been indispensable over the last few months, thank you to the authors!
Installing and running should be as easy as activating the plugin, or at least the error message should be clear.
* Uninstall RLS
* Install Rust-Analyzer
* Reload Workspace
* Click prompt to install rust-analyzer-server
* Start Coding
And one from 2018: https://news.ycombinator.com/item?id=18699627
Not saying it's a bad submission, by the way—and I hope that including those links didn't make it seem that way.
Nah, it was the title change. I'm a super big fan of the previous discussion links; I know they have a weird controversial history on HN, or at least they did a long time back, but I've always thought it was a nice touch.
Very excited to give this a try in WSL2.
I really hope that Rust team will focus on developer experience more, it's astonishing how thinks like code completion or hot reload improve the enjoyment of writing code.
Improving UX requires them to restructure the compiler and add new features (like NLL) while maintaining backwards compatibility. This is hard and takes time!
Also note that C# is twenty years old and backed by one of the largest corporations in the world. It's pretty rare to get an OSS analyzer that can compete with the likes of Intellij!
Edit: fix typo.
I can't speak to CLion. I use the Go debugger daily and I don't have 'GoLand' perse, just the plugin.
My company is good about buying us tools, so they got me CLion (or, rather, the entire Jetbrains Ultimate Pack or whatever it's called). CLion has made Rust development almost infinitely better than it was just using the Rust plugin on IntelliJ (and this is coming from someone who just uses the Python plugin in IntelliJ even though like 50-75% of his code is Python). I'm a JVM dev masquerading as a Python dev and using Rust for some stuff that Python just isn't up to snuff on (and using the super sweet pyo3 package to make native python modules for it, too). The point is, I get the <3 for IntelliJ; I pay for the super ultimate edition for home use just because I like it _that_ much. But CLion and debugging has made my life so much better than doing it with the Rust plugin in IntelliJ or using VS Code.
Some people are content with log statements, but I'd rather stab myself than debug via logs. It's just not my jam!
Edit: I just thought to note that the CLion + Windows + Debugger game is weaksauce. There may be a way to get it to work in windows, but I don't know a single thing about the Visual Studio build tools or how to get everything to play nice or whatever that might be necessary, so I tried to get it to work through WSL. It worked sometimes, and not others, and I got so frustrated I picked up a Mac for my work refresh rather than another surfacebook, mostly because I was tired of having to jump through hoops to sometimes have a mostly working eventually kinda debugger.
So yeah - nevermind about CLion! I do think it works better than IntelliJ, but it's a subtle, not-easily-quantifiable thing, and it's probably not worth buying it if you're just dabbling and also have IntelliJ Ultimate.
This varies from language to language and IDE to IDE, but Idea does not support C++/Rust debugging, even with the language plugins. Only CLion supports them.
I’ve found this true across multiple languages, hence why I bought the full toolbox subscription and use the language specific IDEs where possible. It’s cut out a lot of rough edges from when I tried to just use Ultimate.
Perhaps VSCode can be combined with Rust-analyzer to give language support on par with IntelliJ-rust, but also a msvc debugger? That would basically make windows development "feature complete" (and free!).
If not currently, is it planned?
This could be wonderful!
Like, how does the ownership model interact with an env with as unclear scoping as a REPL?
Also some others exist like https://crates.io/crates/papyrus but I didn't try this one.
Every time I install an extension, I first "Disable" it, which is global. Then I switch to the workspace that needs it and choose "Enable (Workspace)". That way you only have the extensions you need per project.