As a response of https://blog.rust-lang.org/2018/12/06/call-for-rust-2019-roadmap-blogposts.html for tooling improvement. Nice to see rust improved so much these few years on productivity but I think there is room for improvement. This would be my first post about Rust after hanging around for quite some time.
Issues
cargo is a nice tool for Rust despite the confusion that it is being separated from rustup (I did get confused by rustup +nigthly doc), I think I have heard something about rustup being merged into cargo. Wait, continue on, I am not discussing that in this post.
4 working groups have been formed this year and some interesting library have been coming up. Most library in specific domain area are interesting but most of them come at the expense of setting up redundant code from scratch by reading the tutorial or guide such as rocket web framework.
This may be a good approach for beginners to get started but not for those who want to try out a framework or simply want get things bootstrapped fast. Hence, the rise of some repository that people could get online to bootstrap their project such as Rust-webpack-starter. The same goes to CLI working group and others.
As of today, cargo provides two way to bootstrap a project. Either cargo new --lib or cargo new --bin even though there are previous attempt to fix this problem as in https://github.com/pwoolcoc/cargo-template. Looking from the standpoint of a huge package manager for node (npm and yarn), despite their success people still tries to implement similar function for easy update such as ng update (from Angular).
Maybe
Just maybe… the one proposed above looks quite interesting though. I wish that there are cargo new --template=rocket for bootstrapping project and such that was maintain by the community maybe under a mono repository validated by the community (I forgot that crate)? Haven’t think much about that though. Maybe we would not stop just here yet, most projects took it further ahead.
What about automated scaffolding like vue create or angular schematics? Could we make use of it to reduce build time dependencies. Here is a real world example, starting a project with quicli but only utilizing clap and serde? Maybe just taking zero-cost ahead, reducing the compilation time and avoiding unnecessary installs.
Discussion
If it were to be implemented, there are problems that would arise based on existing framework. Such as updating the current project for a template (as in Rust 2015 -> Rust 2018), maybe an integration with rustfix would be nice so the transition may be smoother, some people might not know if they should add edition = '2018' to Cargo.toml or run cargo fix first.
What about template discover-ability? Maybe there is a some methods to list or search for template? As for most of the Javascript framework that I used, the templates are simple just scattered around and hard to find like those *-loader or *-plugin.
What about updating the project with the same template? When I was developing angular projects and trying to keep them up-to-date, the most often approach that I would use is that I create another new project and then diff both of them, then manually modify the base files.
Oh, I just noticed that cargo template have been removed from one of the issue after writing this article. Maybe this might not be the best to start from cargo? Like similar approach to the rust project taken (inspired by #[async]). Let it be a community crate for experimentation (or taking over the existing crate?). 