There are probably various IDEs, but is there a standard IDE that many people use?
I'm particularly interested in:
- For Windows
- VSCode vs RustRover
There are probably various IDEs, but is there a standard IDE that many people use?
I'm particularly interested in:
Longtime VSCode user here. I can recommend it. Many useful extensions available. The rust-analyzer extension is a must. Co-pilot is integrated and active by default (can be easily deactivated).
Tools - Rust Programming Language lists a few.
There are others, of course, such as Lapce, which is itself written in Rust.
I'm a VSCodium user and am plenty happy with the experience. Any modern IDE or editor shouldn't have a hard time supporting Rust thanks to the incredible work on rust-analyzer though, so if you're already particularly comfortable with an editor, I'd say start by seeing if you can just keep using what you already have.
I use Rust Development Studio for Windows, Linux and Mac. It's the web based. But, I do not belong to many people.
If you're not worried about breakage and feel adventurous, I'd recommend Zed. It's under development but has worked fine for me for a good while. I use an API key for Claude through OpenRouter for when I need to ask for help (you put the key directly into Zed). Has a Vim mode and a bunch of neat features, very customizable and so on. Feels light and fast, at least for my hobby projects.
I downloaded Zed to experiment with, but never really did anything with it. I'm still a Rust beginner, but for what I do, VSCode is fine.
RustRover is an interesting alternative as they do their own analysis instead of using rust-analyzer. This means it's the anti-answer of a standard Rust IDE, but if you do find issues with the way others do analysis you might find you prefer RRs.
Oh, I haven't heard it before. Thank you.
What do you mean by "standard IDE"? Something made by the Rust project or just something that is most widely used?
I use the Zed editor. It provides all the features of an IDE I need and is very fast and fluid. It has good Vim like behaviour. Zed is written in Rust, how standard can we get? ![]()
Otherwise I just use Vim.
I think the Rust tool with Vim like behavior is the Helix editor? But most people might not call editors like Helix, Zed, or Lapce a true IDE.
Note that your first sentence seems to contain two errors -- I guess it should be "made", and "that" instead of "the". Well, perhaps you added them by intent, to prove this post is not AI generated ![]()
I think another notable difference between RustRover and Zed is that Rustrover is really more something of an IDE in terms of available options, also as far as I’ve experienced it, you can do literally anything with an extension. This also means that it can takes over 10s to launch. In contrast, Zed doesn’t have nearly as many options / integration with Rust (tooling), also you can only change themes and add language support via Zed extensions and nothing more, but I guess they’re working on it. But I do consider it insane how fast Zed launches, mostly takes less than half a second or something.
(I am not 100% sure to which degree the launch time is tied to the analysis, idk if it takes so long to open the project selection)
For people familiar with those tools, you might have a look at IDE and editor support - Rust for C-Programmers. As I am not using that tools, I tried to collect that information from the Internet -- I think it is correct, but please let me know if something is wrong or missing.
Well spotted. I fixed my slop. I must remember not to post before my first morning coffee.
I question the need for a "true IDE". IDE's were convenient when text editors were not so good for code and even code editors were not so good for code. IDE's provided their own "project" definitions and build systems which was perhaps nice in a world where C/C++ etc did not have such things (yeah we had "make" on Unix but not on Windows for example so Visual Studio streamlined all that project config and stuff.). Micro-controller vendors were famous for shipping their own IDE for their chips. Always slow and painful and trying to lock you in to something you don't like.
Now I edit in Zed or Vim, build and run in a terminal. Quick and easy.
I will never use one! Often I still use Gedit, which is really not that great. For Helix, Vim, or NeoVim, my memory is too bad for more than 3 to 5 commands, and I don't see the real advantage of modal editors. On Youtube we can often see use of the VSCode IDE, with the popping up auto-completions. I will never learn to use that.
But I might use Zed, I have already played with it a bit.
Actually, I tried Claude Code this weekend. I was already subscribed to GPT and to Gemini, but never tried their agentic tools Claude-Code and Gemini-cli. So I subscribed additional to Claude, and created a space-invaders in a few hours. These agentic tools are really excellent. Space-Invaders is of course very simple, and we might guess that they just copy stuff from GitHub. But it is much more. I ask them to start with a basic skeleton, using a Bevy version they know well. So they created a plain Bevy v0.14 version. Then I asked for various improvements, and to finally upgrade to latest Bevy v0.17.3. They downloaded the Change-Logs, and did all the updates, without any issues. I have done Bevy updates manually in the past, it is hard. And Claude did all that perfectly. They compile the code, fix errors, run clippy, fix warnings, suggest improvements, and all that. For all that, the only problem was, that initially playing sound was not working. I think the problem was the wav file format, which needs a Bevy feature. I never used sounds in Bevy before, so I initially fixed it by finding an example in the Bevy documentation for playing an ogg file -- later I discovered that just the wav feature was missing. I will ship the invaders game in the next days, it is funny to play a game again that we have played decades ago as children on the Comodore C64. Conclusion: The time of traditional manually programming is over -- perhaps with a few exceptions.
Well, I have hardly written a line of Rust in three months. An ongoing experiment with LLMs generating Rust has worked out really well. Producing a handful of tools our team needs, not so big or essential to our operations but some quite complex, real-time GPU accelerated 3d data visualisations using WGPU that run-on Linux, Mac, Windows and in the browser.
The good thing is that Rust is so fussy about types, lifetimes etc that the LLMs cannot sneak hairy memory issues bugs into the code that might not show up for a long time.
However I now worry that I have many thousands of lines of code that I hardly understand and when will said LLMs not be able to handle it if things get too big. Then what do I do? So for now I'm not betting the farm on LLM's. But the experiments continue...
So, in a sense, my Warp terminal is my IDE recently.
That, obviously, since there is no IDE made by the Rust team. And the answer is VSCode (might change in the future).
I don't know why some saw this post as an opportunity to promote their favourite Vim-like hard to use for a newbie basic editor that is not even close to an IDE. I mean, I like Kate and it works for Rust, but if someone asked me to recommend and IDE, the answer would still be VSCode, because it support features like VCS integration, test runners (and code coverage), debugger and many more. And these features are usually integrated, not just screwed on via some cumbersome interface like menu items.
To be fair to myself I was not trying to promote a Vim like interface, only pointing out that Zed has it as an option for those whole like that. Otherwise Zed is a simple to use editor like VSCode. I would not class Zed as "basic editor" even if it does not have all the bells and whistles of an IDE like VisualStudio.
Bottom line is people should try different editors/IDEs and find out what they like, what works for them.
I still wonder how useful a debugger in an IDE actually is. I never really used one, even while I bought one for Amiga Oberon some decades ago. I had always the feeling, that for really hard bugs, carefully thinking and use of print-like statements is the best way of debugging. For example, a year ago I had a stupid bug in my chess engine, related to the use of entries from the transposition table pre-calculated using alpha-beta prunning. Took me more than a week to find, understand and fix it -- and I don't think that a debugger could have helped. Or, some years ago, I knew a very smart compiler developer, who said that they rarely used a debugger, but typically just plain echo() calls. Perhaps for beginners an IDE with an integrated debugger might be a nice toy, e.g. to step through some code slowly.
I have never been much of a debugger user. Since decades ago I found that when I was desperate enough to fire up a debugger to help with some unfathomable problem it just hid the problem.
I have noticed many say that they use a debugger to verify that their code is doing what they expect. But hey, that is what unit tests are for. With the advantage that a unit test is always there, you don't need to go through the debugging session agin of you make changes. All the unit test is a permanent document of what you expect not a fleeting "trust me bro, I stepped through it, it works"
More interestingly others have said they have used debuggers to see what an existing, working code based does at run time. Rather than having to study all the code to see determine the usual flow of things. That sounds more reasonable.
For me the debugger is mostly a "why did this line get hit" tool, where you can navigate back up the stack and figure out what the heck happened a lot quicker than adding a million log messages everywhere you can think of. It's still pretty rarely useful nowadays though.
I'll never begrudge someone being happy with a minimal editor, but I'm just too used to things like refactoring tooling and live error reporting, and I'm not willing to spend the time Is need bludgeoning neovim into functioning the way I'm used to (for example last I tried I couldn't even get typescript import path completion working, which is a showstopper by itself)