What features would you like to see in a Rust IDE?

I was working on a Rust-native IDE when the most recent version of the IntelliJ Rust plugin came out, and, along with the past few versions, it implemented almost all the previously-unavailable features that I was planning on implementing. I still have a few left, but not nearly enough to justify a whole IDE. Yet, I still would very much like to write a successful IDE for Rust, so I'm wondering what feature(s) you all would like to see and be able to use.

9 Likes

Instead of reinventing the wheel with an entirely new IDE (which is, by the way, an enormous task - I don't think a one-man project can even get close to commercial IDEs like IDEA.), I'd much rather see more contributors on the Rust plugin for JetBrains IDEs, or rust-analyzer.

12 Likes

first of all IntelliJ,Netbeans or Eclipse and also Visual Studio has been very bloated and they are requiring more and more resources each time. i have used QT creator and its very native and its very fast even on my old laptop. its may be a time to start creating a new native IDE

4 Likes

What libraries you are using? The integration with rust analyzer would be must as it will be included in rust compiler in future.

Robust refactoring is something I want out of a Rust IDE. One of my pain points in refactoring is with lifetime syntax - having to either add or remove a new lifetime from all impl Foo instances where I can't use '_. Regex find/replace is okay, but sometimes not good enough.

5 Likes

Some nice to haves would be(it's not must or important but I believe would finally bring us at parity to the best IDE tooling for any language),

  • Fast and responsive to use
  • Basic autocomplete with proper type hints, and origin markers(multiple traits having the same function can make things confusing)
  • Fast warnings, and error highlighting.
  • Quick documentation viewer, it can use in-source docs or just open the linked doc HTML pages(cargo docs have the issue of not being able to build docs for multiple crates of the same name or same crate with different versions)
  • Easy to use debugger support
  • Integration with Version Control System(just Git works for me(for now.))
  • Maybe? a lifetime graphical visualizer... (many people pointed this out on Reddit)
  • Likely! Rustfmt, Clippy, and integration with other stuff.
  • Preferably a solution for macro autocomplete
  • Also, preferably not depend on the Rust ecosystem too much. (Maybe it a future goal, I wish we could have a separate compiler just for IDE maintained parallel to rustc someday)
  • Most importantly, Dark Theme

At the moment IntelliJ is the closest, rust analyzer is getting there but has minor issues, things there break sometimes in new builds have to keep things updated. Still, I prefer RA because IntelliJ is just too slow/heavy.
So maybe you can just use rust-analyzer, well. And implement additional features in the editor, who knows...

4 Likes

I think the most important tool of an IDE is a debugger. If you want to look at some nice-to-have features of a debugger, look at a Smalltalk debugger or to an Elm debugger.

6 Likes

That is often true.

But I'm wondering if a debugger is anything like as important with Rust. Because:

  1. All the type correctness and memory/thread safety of Rust makes a huge amount of bugs one normally needs a debugger for impossible.

  2. Rust's simple to use facilities for creating tests makes using a debugger for checking if ones logic does what it should a lot less pressing.

I'm not a great user of debuggers even in C/C++. Typically when I get so desperate finding the cause of a problem a debugger does not help and often hides the problem.

In what situation would a debugger in Rust be crucial?

1 Like

I think it was the only way I would have found that I had inadvertently shadowed a variable. I'm stepping along, and all of a sudden the value of an immutable variable changes. What? Must be a compiler bug! Nope, just me accidentally reusing a name I shouldn't have.

Ah, interesting.

At first I was horrified that shadowing was allowed.

Subsequently I found that when I shadowed names I got type errors. That's OK, quickly found and fixed.

Then I found shadowing is actually a nice thing. A conceptual thing can change it's type, from a string to an integer for example, shadowing means I don't have to think about a different name for it.

I imagined having tests in place would quickly find cases of incorrect shadowing.

1 Like

Shadowing is a nice thing, but only if you do it on purpose :smiley:

The test showed that a message was going out on the wrong port. Type checking would have helped if the newly defined and shadowed variables had different types, but they were both valid port numbers. The port number I wanted to use was clear as day in the method signature. The shadowing happened in a block of code half way through the method. I must have looked at it 100 times but never saw I was reusing the name. But when the value of an immutable variable changed while single stepping, I knew exactly where to look and saw it.

Obviously plugin system is the most important. That will allow people to extend your work without messing around with your code. Also if you support other plugin formats like that of vs code you can get a lot of functionality for free. Despite that :
Find reference (variable, struct/function/whatever rust have language object)
Fuzzy search (global, local, for function/class/struct/enum etc only)
Bookmarks
Debuger
google sanitizers (obviously they work only on linux) valgrind too
If you not plan to base you ide on existing text editor like neovim which will be good ide (at least support like plugin) you can implement multi line edit and fast navigation
Good suport of the build system and the tests
I can thing of anything else I hope I was useful good luck have fun do your best no mater the result and do not listen to people who tell you to leave your project to work on something established. It's your time it's your choice

Typically, when a Rust test assertion fails, I just see some lines printed on the console. How can I detect what was the cause of that error? Using a debugger, when a test assertion fails, the debugger shows a list of all the function calls that led to that assertion (call stack); clicking on one item of that list, I can navigate the data structures defined in that function, and I can evaluate expressions on-the-fly (an interpreter is needed). I find it priceless.

2 Likes

All my need is an Interpreter.
with Interpreter, I can debug rust program without compiling it.
It is quite useful since sometimes a program can not even be compiled.
(For example, losing a semicolon may produce an error[E0618])
If an interpreter is provided, such error could be detected earlier and easier.

error[E0618]: expected function, found `{integer}`
 --> rust/fuckif.rs:2:11
  |
2 |        let a=if 2<3 {
  |   ___________^
  |  |___________|
  | ||
3 | ||         4
4 | ||     } else {
5 | ||         5
6 | ||     }//losing semicolon here.
  | ||_____^
7 | |      (1+2).iter().for_each(|x|println!("{}",x));
  | |__________- call expression requires function

error: aborting due to previous error

For more information about this error, try `rustc --explain E0618`.

I use VSCodium with rust-analyzer. When I'm typing code to solve a problem described in the problems console, dozens of syntax errors appear because I'm not done, all the page gets underlined in red or commented, it blinks, takes a lot of CPU and makes the interesting problem disappear. But I needed to read it because it contained useful information!

The perfect IDE should not scream at you that you are doing wrong before you've finished. The solution may be to separate trivial syntax errors from other errors, and to allow pinning an error so it cannot disappear until unpinned.

Auto backup is a good feature too. It is useful in VSCode, because it crashes very often.

2 Likes

There's a couple of features I'd like to see in an IDE that no production IDE to date has managed to offer yet:

  1. Computation of the asymptotic runtime behavior of the fn/method I'm working or hovering on, expressed at least locally in terms of the inputs, both implied (eg free variables captured by a closure) as well as explicit. One big challenge I see here is integration of I/O i.e. the things that don't really have a place in the measurement (or even assignment) of asymptotic runtime behavior as it stands in 2020.

  2. Using the parser to improve the UI of the editor/IDE by making it impossible to enter grammatically invalid input. Again a feature I haven't seen in any production IDE. But this one would, implemented in an ideal fashion, replace the current textarea-like input boxes we currently use for input with something more targeted. It would also improve discoverability enormously, by giving programmers an explicit list of things that could validly be input at the place their "cursor" happens to be.

2 Likes

Is it even possible to compute the asymptotic runtime behavior of a function? Even a simple thing like computing if a point is a member of the Mandlbrot set can take so close to forever that we generally cut it off prematurely. Or what about the Collatz Conjecture? And so on?

The only system I have ever worked with that had any idea of run time was the Lucol language used by Lucas Aerospace for avionics control systems. In such a system ones code has to run in some strictly specified length of time, say 10ms, any overrun of your time slot is a failure. Lucol could compile huge programs out of many modules and at the end of compilation it would report how much of you time budget it would consume.

Lucol could do this because the language had no way to create loops. No loop constructs, no way to "goto" backwards. If you wanted to iterate you had to maintain state as to where you had got to and one iteration would happen every time you were called. This way it could calculate the path of longest run time through the module and transitively through all the modules in the program.

As for not allowing syntactically invalid input I have only seen that once. An MSc student was tasked with writing an assembler for some processor architecture a group had been designing. He created a graphical assembler, you could select instruction from a list and proceed with selecting source/ destination registers, variables etc.

It was kind of wizzy but being assembler was no help in ensuring your program might run sensibly at all.

1 Like

In general probably not, but with some facilities to annotate the problematic cases it still could be of help.
Look at it this way: some correct information is better than none.

I can imagine, both the wizziness and it not being of much help, precisely because it was assembly, all dialects of which have an almost trivial grammar.

I'm not talking about assembly though. Rather I'm talking about full-fledged higher level languages, and deriving the input possibility space directly from the grammar. This should be fully possible with more than acceptable performance, and it wouldn't just be a quantitative bump but a qualitative leap in the quality of the development experience of programmers.

I thought intellisense and such did what you are asking for, suggesting grammatically correct ways to continue. As seen in many IDEs to some degree or other.

Compared to what I'm suggesting, those are half-measures at best.
One big difference is that AFAIK intellisense and the like don't make grammatically incorrect input impossible.