Brson's "someday" list


Sounds like you should be able to just run cargo template quickstart my-new-project and get a project setup to use error-chain.


Neat. Should it work in conjunction with this PR for cargo or some other way?


I believe my intent was to make compatible with, in anticipation of compatibility with your cargo PR in the future.


Templating was merged into Cargo yesterday.

The following project can be used as a quickstart template (I made a PR to use {{name}} and {{author}} templates:


Thanks @ehiggs!


@ehiggs What is the cargo command to instantiate the error-chain directly from the error-chain repo ( I’d like the error-chain docs to say something like

To get started run:

$ cargo template whatever

(Obviously fill in with the correct syntax)


$ cargo new --template whatever

Currently there is a bug in that particular template where the name and author aren’t actually templated but I have a PR to fix it.


Here’s some commentary about the ‘simple crates’:

16:32 simple crates - there are a number of unbelievably common functions i end up reimplementing a lot 16:32 and poorly 16:33 copy_dir is just a recursive directory copy. not sure if there’s a good crate for this yet 16:34 sometimes one needs to do a copy but ignoring dotfiles. i open code this with walk_dir 16:34 but there should be a common copy_dir that covers most cases and just works 16:34 remove_dir_all is broken in std on windows 16:34 so people always reimplement in 16:34 *it 16:35 while it should be fixed in std, in the meantime somebody should just publish a working version 16:35 dojob is a common routine that cargo, rustbuild and rustup use to create process groups on Windows for killing multiple processes 16:35 but they all implement it diferently and some are missing fixes 16:36 symlink_dir would be a crate that creates symlinks to directories correctly on windows, using directory junctions 16:37 homedir would be an implementation of std::env::home that uses cargo/rustup’s definition. I consider std incorrect when it considers HOME on Windows.


I’ve updated the list with:


  • document interfaces that are not-really stable
  • port cargobomb to windows
  • add stdx ci testing
  • install more things in cargobomb docker container


  • run custom shootout server with additional nightly benchmarks
  • write hello.exe size test
  • switch default rustup to -gnu
  • do analysis of servo crash fixes vs firefox crash fixes
  • propose proprietary Rust testing service


why proprietary?


It’s not the service itself that is proprietary, but a service for regression testing proprietary Rust projects, to give us visibility into the ecosystem where we are lacking it. It would be a formal structure for setting up NDAs and compensation for running cargobomb and similar future efforts on closed-source projects.


As a once and future (hopefully with rust) "Enterprise Software Developer"™, I think this could go a long way towards reassuring companies that they could rely on rust for their development future.


@brson I would like to help with

  • weekly compiler-perf report;

What does it actually entail? Hope explaining what it entails doesn’t take as long as actually doing it. :slight_smile:

From the single line, I assume it has to do with measuring performance of the compiler over its development history. Sounds related to continuous integration/testing/benchmarking. Would this use gperf? Which benchmarks would you use to measure this?


@pmatos The main idea is just to get information about the performance of the Rust compiler in front of people on a regular basis, to build a sense of accountability. At the time I would have said to examine to extract a sensible story about what happened last week, and just write it up in a consistent way, with key metrics. At the moment though perf.rlo is not working…


Templates was pulled out pending an RFC. The feedback in a pre-RFC thread suggests that people don’t want it in cargo but would rather an external cargo tool like clippy.


I updated the op with the following:


  • update platform support page with richer info about which are tested
  • teach cargobomb to print rustc version in every run
  • fix skeptic linkage issue
  • solicit cargobomb help
  • upload libz blitz videos to youtube
  • create 1.0 crate scoreboard
  • conduct research project on structuring projects for contribution



I updated the op with the following.

This is pretty massive list of things that I think should be done, but mostly without much info about what that something is. If any of these look interesting and you want to take a stab at it I can try to help you get going.

Presently I’m finding myself completely overwhelmed with projects I want to advance, but without the time or means to get them moving myself.


  • finish anthology
  • start rust on fuchsia project
  • update cargo crusader so it works again
  • outline possibilities for getting more rust funding
  • teach cargobomb to print rustc version in every run
  • fix skeptic linkage issue
  • solicit cargobomb help
  • create 1.0 crate scoreboard
  • write irlo post about triage opportunities
  • initiate project to serdify crates
  • find somebody else to do release milestone predictions
  • write release checklist
  • switch rustup to use the win-msvc host by default
  • do panic_fmt stabilization rfc
  • update smoke in terms of cross
  • extract cargo_home / home_dir into their own crate
    • update rustup, cargo, cargo-index-tool
  • look for project management assistant
  • solicit ‘this release in rust’
  • ask for help running cargobombs
  • advance ‘train the trainer’ idea
  • solicit help on cookbook design
  • help budziq with cookbook recipe ideas
  • write fast scrypt library
    • corrode the fastest c scrypt implementation and convert it to safe rust?


  • do a new “annotated std”
  • work on rust-timeline (timeline of rust history)
  • rebrand ‘thanks’ thread
  • write a post about rust jobs
  • conduct research project on structuring projects for contribution
  • upload libz blitz videos to youtube
  • update platform support page with richer info about which are tested
  • run emscriptenized tests under cargobomb
  • do standard library survey
  • getopts 1.0
  • do a linux distro rust/cargo/firefox packaging summary
    • status of all three packages in many distros
    • upstream package urls
    • get updates from packagers
    • irlo thread
  • cfg-ize servo to remove js, opengl, etc.
  • run bloaty mcbloatface on rust stuff
  • teach rustup to install with no toolchain
  • update basic-http-server to use modern crates
  • set up better tracking of regressions - use version-specific tags?
  • create a local (non-Send) alloc/collections crate
  • update research papers on the forge
  • update rust highlight definitions for benchmark game


@brson I would love to help on the Rust on fuchsia project <3

  • initiate project to serdify crates

Is this about the eradication of rustc-serialize from dependency chains throughout I went and looked at dependent crates for rustc-serialize, it seems like a lot of the top crates already only have it as an optional dependency (not sure if “optional” includes both on and off by default or only the former) or a dev-dependency, which seems like the most important part. I also did a quick drive-by PR to move the dependency to a dev.dependency in one of the top downloaded crates (from page 3 or so of the results).

  • solicit cargobomb help

What kinds of help are you looking for?


@goyox86 great! I think the most important thing to do is to just start building visibility and momentum. My rough plan here was to

  • Learn how to build hello world on fuchsia
  • Blog about that and post it to /r/rust
  • Start a thread on users.rlo asking how best to get community momentum

It would be great to have somebody leading the charge on Rust on Fuchsia (that could be you!). That somebody probably needs to get involved in the Fuchsia community and begin to understand where the opportunities are. We could then probably come up with a set of really neat projects to solicit contributions for, maybe start a org, do some hackathons, etc.

I suspect some big opportunities are:

  • hardware drivers - Fuchsia is a microkernel with userspace drivers, which makes them fairly accessible. It’s a new architecture, so there’s need for a ground up rebuilding of the driver ecosystem. There’s lots of hardware in the world to write drivers for. Having a big set of Fuchsia Rust drivers would firmly entrench Rust in the OS. We could pick some really cool SBC and aim to get Fuchsia working on it via Rust drivers.

  • coreutils - This is a pretty neat project that is developing slowly. Would be awesome to port it to Fuchsia. Not sure the state of coreutils on Fuchsia.

And … I don’t really know what else. Somebody needs to be in closer contact with the Fuchsia community. I know @cramertj has been poking at porting tokio and would be a good ally in the Fuchsia effort.

cc @raphlinus