Should "cargo new" default to applications?


#12

@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).


#13

@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.


#14

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.


#15

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.


#16

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…)


#17

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.


#18

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).


#19

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


#20

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.


#21

+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.


#22

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

Just one data point.


#23

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.


#24

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?


#25

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.


#26

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.


#27

Strong -1 on requiring an explicit action and/or dialog. I think requiring any decision is super beginner unfriendly. And deciding on bin vs lib is particularly difficult, because not every language has this distinction.

From my personal experience with project creation wizards, I’ve recently tried to play with OCaml, and oasis quickstart was suuuuper confusing to me.

A number of times I have deleted and recreated projects because of this mistake.

Hm, perhaps this is the problem we should target? It’s better to provide an undo button than to ask for conformation. And it seems to me that switching between bin and lib is simple at the moment (rm src/main.rs && touch src/lib.rs) ?


#28

Maybe rather than an undo button, a way to toggle between (or at least easy access to instructions to do so).


#29

I’m also for replacing the default.

I can remember that this was really unintuitive when I started with rust and I often created libs when I wanted to test something out in a bin.

A good alternative would be subcommands for lib and bin and have cargo just ask what it should do when nothing is specified.


#30

If this is done, it should probably go something like this:

  1. Add a --lib switch to explicitly state you want a library.
  2. Allow the default to be changed from a config file.
  3. Add a warning if neither --lib nor --bin is specified, indicating that it’s defaulting to a library, but that this will change in the future. Also point users to the config file to “lock-in” their default.
  4. Bonus: add a cargo new --set-default switch or something to do this for the user.
  5. Wait a while (maybe two+ cycles) for the change to propagate, so everyone using cargo new in scripts can change to explicit switches.
  6. Change the default.
  7. Patiently explain to the numerous people who complain at this point that they had plenty of warning that this was coming and that they should have updated their scripts and/or set a default ages ago and, really, it’s not that big a deal.

Personally, I’m fine with the default, since I create far more libraries than binaries. If I’m making a binary, I almost always make a library with the binary as a thin wrapper around it, anyway.


#31

Daniels proposal is very calm and reminds me of the git push/pull strategie change from 1.8 over 1.9 to 2.0. I think it is a good way.

From my point of view: In this forum should be way more people creating libs than anywhere else. So I agree with the switched default.