Hacker News Reader

Comment by dahfizz | Hacker News Reader

Maybe it's just because I am more familiar with C/C++, but I disagree.

Cargo is very opinionated, forcing upon you certain directory structures and even a default VCS. If you have a large project, cargo makes you jump through hoops. Building multiple binaries and libraries from one project is a pain, and has to be done exactly as cargo wants.

In terms of being able to "just get started", I think `gcc app.c` is way easier than using cargo. But that's not really important. You're not going to replace a million line C project with Rust just because "getting started" was a few seconds faster/slower.

View on HN

You can `rustc app.rs`, and do all the C Makefile stuff that way too (example in the kernel: https://github.com/Rust-for-Linux/linux/blob/rust/rust/Makef...). Nothing is forcing you to use Cargo except for convenience.

> Cargo is very opinionated, forcing upon you certain directory structures

No, it expects source code in `src` like most C/C++ projects anyway. Then it's `lib.rs` or `main.rs`. The opinionated directory structure (`pkg.rs` or `pkg/mod.rs`) is rustc not cargo.

> even a default VCS

Because it's the one used by most projects. Anyway, nothing prevents you from using mercurial, svn, ...

> Building multiple binaries and libraries from one project is a pain

Have you heard of Cargo workspaces? Because I've had no troubles with it.

> I think `gcc app.c` is way easier than using cargo

Agree to disagree. Because really soon, you'll want to manage dependencies.

> it expects source code in `src` like most C/C++ projects anyway

In C/C++ there's no expectation of the code being anywhere.

> Because it's the [VCS] used by most projects.

I don't see how a VCS being popular is a reason to require it. It's not even "essentially all projects", just "most projects".

> I don't see how a VCS being popular is a reason to require it [...]

Neither do the authors of cargo:

`cargo new --vcs none`

> In C/C++ there's no expectation of the code being anywhere.

That's not what I said. I said that most project do it this way anyway, regardless of any expectations. So who cares?

> I don't see how a VCS being popular is a reason to require it.

It is not required.

And linking? Dependency management?

C & Rust come from different eras of easy-getting-started, IMO:

C - I just want to get shit done, I'm not taking on any dependencies, I'll just write it myself and sure it won't be the best but it'll do what I need and keep it simple;

Rust - I just want to get shit done, surely there's a lib for this and that, I can just glue them together.

So with Rust that's no harder to do than doing anything at all; with C it's quite a bit harder but also a bit easier if you don't.

Agreed that's not going to hold any weight in deliberating switching a million line project, but I do think it matters what hobbyists/spare-timers are using, what people want to work with, etc. Slowly.

(E.g. my day job is mainly python; if we needed something highly performant or embedded or whatever I'd be way more comfortable in Rust than ropey university-C.)

That's Cargo's by-convention auto-discovery. You can manually specify the same information in Cargo.toml if you prefer to customize it.

https://doc.rust-lang.org/cargo/reference/cargo-targets.html...

Does Cargo have the equivalent of Maven’s archetypes? Eg, project templates to generate a particular directory structure, some default files, etc.

Currently, it has two built-in ones for `cargo new` and `cargo init` (--bin and --lib) and there are third-party tools like `cargo generate` which provide for more, but they haven't accepted anything into the main distribution yet.

https://github.com/cargo-generate/cargo-generate

Reply on news.ycombinator.com