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.
Comment on Best free (preferably FOSS) Rust IDE for MacOS
lysdexic@programming.dev 1 year agoThere’s no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages
In your perspective, what’s the difference between a cargo.toml and a requirements.txt, packages.json, pom.xml, etc? Is there any?
thesmokingman@programming.dev 1 year ago
lysdexic@programming.dev 1 year ago
So there is fundamentally no difference between cargo and any other contemporary dependency/package manager.
IAm_A_Complete_Idiot@sh.itjust.works 1 year ago
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.
lysdexic@programming.dev 1 year ago
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.
dukk@programming.dev 1 year ago
Well, it is standard.
That’s probably the biggest thing to consider: you use Rust, you use Cargo. It’s unanimous.
It’s built right into the language ecosystem, so there’s no divide, and everything’s just easily available to you.
jeffhykin@lemm.ee 1 year ago
To get to your core point; I agree python without a virtual env, just raw python, is definintely not bulky. I’d argue its much more lightweight than cargo. My comment was because sounds like OP could be new-ish to programming, and, for a number of projects (ex; Android development), going from a big IDE to just a plaintext editor + command line commands can be a really painful jump. I remeber a Java course having a series of IDE tutorials and I could not for the life of me figure out the plaintext+commandline equivlent. The same can happen for certain python projects if a tutorial expects the editor to set the PYTHONPATH and the project has a venv, and the tutorial expects the editor’s terminals start already-inside python virtual environment. That kind of stuff can make 'python without an IDE" confusing and daunting to someone merely following PyCharm tutorials.
I just wanted to assure OP they likely wouldn’t have that kind of experince with Rust. AFAIK Rust tutorials rarely (if ever) assume an IDE.
Being not-bulky isn’t a rust specific thing, a half-decent package manager fixes it, but OP was asking about Rust and might not know.