I currently edit with gedit and build with cargo, on Linux. I'm considering using GitHub CoPilot. What do I have to run on desktop to edit to use CoPilot? Is there some simple editor, or something that understands Rust project layout, short of going to some IDE?
No idea about CoPilot but I'm using the Zed editor (written in Rust by the way) which has some kind of AI integrated. CoPilot is an option. Which I have never used. Copilot x Zed
I build with Cargo in the Warp terminal (Written in Rust you know) which has some kind of AI integrated: Warp vs. GitHub Copilot - Comparison with Pros & Cons | Warp. Which I have used to good effect on occasion.
1 Like
Visual Studio Code has a pretty good integration of Rust.
I did try Sublime Text, Neovim, and Zed.
Everything seems a bit more natural to me in it.
One thing that you want to do is install the extensions for Rust.
It gives you:
- Type annotation
- Debugger integration.
It doesn't seem like much, but a debugger is really a superpower.
As for the A.I. integration. I don't use Copilot, but I have installed Continue, and I use it from time to time.
One thing I love about it is the possibility to use a local A.I, like mixtral with VScode.
Nah, what? On the occasions I have felt the need for a debugger they have actively got in the way of finding the bug I was looking for.
With the anal type and memory use checking Rust does at compile I find even less need for a debugger. Putting a few tests for tricky bits of code reduces it even further.
We can probably debate endlessly on the value of a debugger. It's more a personal preference than something objective.
I agree with you that with Rust, I have a lot fewer complicated bugs and a lot more type errors. That can't be fixed with a debugger.
I think the reason we don't use a debugger much is the Linux culture of having:
- a text editor
- one terminal
- compile & run
And in this setting, a debugger is another tool you have to learn.
In Cgdb is not integrated and difficult to use. So it's not the first choice, and printf does the job most of the time.
In this setting, debuggers are mostly used as a last resort.
But when the debugger is easy to use, it's a very practical tool.
When I have some complicated code, I find it's very useful to have a debugger.
Sometime I just run the code I have just written in a debugger to make sure it does what I think.
And when I have a data structure that gets a bit complex, I find it invaluable to execute the code step by step.
There is the thing. That can of course be very convenient. But my view is if you do that you are in effect testing your code. I find it far better to do that testing by writing an actual test or three. Typically that will take about as long to do and has the great advantage that you don't throw your work away, those tests are there forever to be run again whenever you might tweak something. Basically tests are automating the debugging, who does not like to automate away tedious tasks?
Also, many would argue that if your code is complicated enough to require use of a debugger to find out what it actually does it's time to try and simplify things and make them testable with simple tests.
Where I have really needed a debugger is in developing real-time embedded systems. But then they let me down. Even actual in circuit emulators have failed me.
1 Like