Should "cargo new" default to applications?

[djc]

Going all meta: build opt-in telemetry for cargo, so we can make data-driven decisions on this stuff.

[retep998]

Yes please.

[jntrnr]

Telemetry is definitely interesting, but it feels like a whole conversation in itself. I’m afraid if we say “let’s wait for telemetry”, which may not come any time soon, we’re giving months/years to the current default and building up people’s muscle memory for it.

Right now cargo is not yet 1.0, and after it reaches 1.0 we shouldn’t be changing defaults (or perhaps only rarely at semver boundaries). Now is the time to make the adjustments when we can.

[withoutboats]

Its actually unclear to me what cargo’s semver story is right now. For example, a change that could cause cargo build to start failing for any crate is likely unacceptable. That’s a whole other conversation, and I think this change is fine, but I’m just saying its not 100% certain we can make this change.

[dan_t]

Why not forcing the user to make a decision?

cargo new bin foo
cargo new lib foo

[jntrnr]

@dan_t - I saw @withoutboats mention a similar idea. We can do that, but it has the same breakage as changing the default, as “cargo new foo” would no longer work (assuming I understand you correctly).

I personally kinda like that “cargo new something” isn’t all that much to type, so I’m kinda leaning towards keeping it around if we can.

In case anyone is curious, the current version of the patch introduces a new --lib and also prints out a status when it’s done so you can see what kind of project you created. I’m hoping that even if we don’t end up changing the default, this will help users discover the other project type(s).

[jntrnr]

@withoutboats - agreed that different subcommands of cargo feel change-able but others don’t. This one is kinda borderline for me since it’s unlikely to be part of someone’s build script. That said, I didn’t want to change it without first reaching out to see what other Rust folks thought.

[cswords]

In case anyone is curious, the current version of the patch introduces a new --lib and also prints out a status when it’s done so you can see what kind of project you created. I’m hoping that even if we don’t end up changing the default, this will help users discover the other project type(s).

If we aren’t going to change the default, it would be incredibly helpful to introduce a command to quickly swap the setup. Maybe something like cargo add lib/cargo add bin to automatically patch up a miscreated project.

[withoutboats]

Looking at the PR, I am really surprised there wasn’t already a --lib flag! It definitely seems like it should be possible to be explicit about that.

I’m really interested in the idea of crate templates, I’ll keep thinking about that space and try to come up with a more detailed proposal.

[Yohanesu75]

Default to bin and --lib flag seems more logical to me (because I always make the mistake of creating a lib when I intend to create a bin…)

[ahmedcharles]

My perspective is that (successful) programming is about building libraries and then combining them with a small amount of ‘glue’ code to turn them into a binary. So, in that sense, lib is the right default. Though, this doesn’t suggest that there won’t be more invocations of cargo new using --bin, however. I suppose it’s a very nuanced choice and I don’t see a compelling argument for changing it.

Not everything should be reconsidered over and over, forever. At some point just going forward with what you have is best.

[brson]

I think --bin makes sense as the default purely for the newbie experience of playing with Rust, even if --lib is more common (which I think we don’t have any data about).

[anp]

Sounds like a good use of that GitHub on BigQuery data.

[withoutboats]

I agree. In the lifetime of a Rust programmer, creating a new crate is a rare occurrence, and so it is not very important to optimize for an average Rust user’s experience. In contrast, a user who has less than 30 minutes of experience with Rust is very likely to a) create a new crate, b) want to run that crate (to see ‘hello world’ or whatever else). It makes a lot of sense to optimize for the early user’s experience here, since having to fix their mistake of not passing --bin would be a frustrating and maybe confusing distraction.

[gavinb]

+1 for defaulting to applications. I’ve been using Rust for a while and I still forget to add the --bin flag and end up having to delete and re-create the project. It’s simply not intuitive, and also seems inconsistent with most other similar tools.

[llogiq]

We use cargo new in teXitoi/benchmarksgame’s Makefile.

Just one data point.

[DenisKolodin]

I’m agree. I used to prefer bin when I was new with Rust. Now I prefer lib. To play I use lib tests with --nocapture flag.

[jntrnr]

So the leaning so far seems to be something like:

• As a new user, you’re likely to want to start by making applications
• As you mature as a Rust programmer, you switch to creating more libraries
• Since advanced users know flags better, and we want to make the new user experience simpler, it’s okay to switch ‘cargo new’ to applications
• There will be some breakages if we do this (like @llogiq points out)
• We’d also like to start thinking about opt-in telemetry to get a better understanding of how rust/cargo is used in the future. Obviously this has its own set of complexity, so best to start a new thread.

Does that sound like a fair synopsis?

[Ericson2314]

Cabal has a dialogue for basic questions including lib vs bin. This might be the most friendly to new users. The flags can still be kept as a “batch mode” for more experienced users.

[kevincox]

I definitely like the idea of it being explicit. A number of times I have deleted and recreated projects because of this mistake. Then it is worth discussing if the action with no explicit pick is a wizard for new users or a nice clear error message.