There’s not going to be a rust-specific FOSS editor AFAIK (nothing like RustRover from JetBrains). However the Rust extensions are first-class experience on VS Codium, Neovim, Emacs, etc.
More importantly, unlike Java, C#, Kotlin, C++, or Python Rust doesn’t benefit all that much from a language-specific IDE. There’s no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages, an install command, and a build+run command.
Vanilla cargo.toml files are more akin to a requirements.txt than any of the others, which allow you to do things like set variables or create run scripts. However, vanilla cargo.toml files have some minimal Make functionality so it’s a bit more than just project dependencies. Each of those ecosystems has a slightly different approach to handling build tooling and dependency management. Rust puts the basic build and dependencies in one file with the assumption your system has the right Rust version, which is a lot simpler than others.
Also, it’s worth noting that cargo is a fairly good package manager all things considered. It has a native lock file format, unlike requirements.txt. Running code that’s built with cargo typically just works with cargo build. No futzing around with special build commands for your specific build tooling like in js. I can’t speak for maven since I’ve only used it a little bit and never used it enough to be comfortable with it… but cargo just doesn’t really have many major paper cuts.
Admittedly, cargo isn’t really special - it’s just a classic package manager that learned from the hindsight of its predecessors. It’s all minor improvements if any. There’s actually innovative build tooling out there: things like buck2, nix, etc. But those are an entirely different ball game.
Also, it’s worth noting that cargo is a fairly good package manager all things considered.
Yes, I’m familiar with Cargo. My point was to point out the absurdity and silliness of OP’s remarks on “no bulky management of a virtual environment, no make files, no maven, etc.” Once Rust fundamentalista take off their rose-tinted glasses, it’s clear that Cargo is just as good (or as bad) as any contemporary integrated build system.
There’s not going to be a rust-specific FOSS editor AFAIK (nothing like RustRover from JetBrains). However the Rust extensions are first-class experience on VS Codium, Neovim, Emacs, etc.
More importantly, unlike Java, C#, Kotlin, C++, or Python Rust doesn’t benefit all that much from a language-specific IDE. There’s no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages, an install command, and a build+run command.
In your perspective, what’s the difference between a cargo.toml and a requirements.txt, packages.json, pom.xml, etc? Is there any?
Vanilla
cargo.tomlfiles are more akin to arequirements.txtthan any of the others, which allow you to do things like set variables or create run scripts. However, vanillacargo.tomlfiles have some minimal Make functionality so it’s a bit more than just project dependencies. Each of those ecosystems has a slightly different approach to handling build tooling and dependency management. Rust puts the basic build and dependencies in one file with the assumption your system has the right Rust version, which is a lot simpler than others.So there is fundamentally no difference between cargo and any other contemporary dependency/package manager.
Also, it’s worth noting that cargo is a fairly good package manager all things considered. It has a native lock file format, unlike requirements.txt. Running code that’s built with cargo typically just works with
cargo build. No futzing around with special build commands for your specific build tooling like in js. I can’t speak for maven since I’ve only used it a little bit and never used it enough to be comfortable with it… but cargo just doesn’t really have many major paper cuts.Admittedly, cargo isn’t really special - it’s just a classic package manager that learned from the hindsight of its predecessors. It’s all minor improvements if any. There’s actually innovative build tooling out there: things like buck2, nix, etc. But those are an entirely different ball game.
Yes, I’m familiar with Cargo. My point was to point out the absurdity and silliness of OP’s remarks on “no bulky management of a virtual environment, no make files, no maven, etc.” Once Rust fundamentalista take off their rose-tinted glasses, it’s clear that Cargo is just as good (or as bad) as any contemporary integrated build system.