+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.
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.
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?
1 Like
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.
3 Likes
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.
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) ?
Maybe rather than an undo button, a way to toggle between (or at least easy access to instructions to do so).
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.
If this is done, it should probably go something like this:
- Add a
--libswitch to explicitly state you want a library. - Allow the default to be changed from a config file.
- Add a warning if neither
--libnor--binis 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. - Bonus: add a
cargo new --set-defaultswitch or something to do this for the user. - Wait a while (maybe two+ cycles) for the change to propagate, so everyone using
cargo newin scripts can change to explicit switches. - Change the default.
- 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.
2 Likes
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.