{
  "$type": "site.standard.document",
  "canonicalUrl": "https://deterministic.space/rust-2018.html",
  "path": "/rust-2018.html",
  "publishedAt": "2018-01-10T00:00:00.000Z",
  "site": "at://did:plc:x67qh7v3fd7znbdhauc45ng3/site.standard.publication/3mjcd2t6afe25",
  "textContent": "Instead of [fireflowers],\nthis year the Rust Team made a public\n[call for blogposts][cfbp],\nasking the community to write posts that\nreflect on Rust in 2017 and what they wish for Rust in 2018.\nWhat follows are some of the things I personally see as important,\nand that I'd love to prioritize on in the following months.\n\n[fireflowers]: https://brson.github.io/fireflowers/\n[cfbp]: https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html\n\nAs another Pascal wrote,\nif I had more time, I'd have written a shorter blog post.\nSo this is more a collection of thoughts and ideas\nthan a polished roadmap proposal.\n\nRust 2017\n\nBut first, let us look back at the last year of Rust.\n2017 was a year in which the Rust project made some great steps forwards.\nTo pick a few:\n\n- The first-ever roadmap RFC was used as a driving force\n  to focus on specific areas of improvement,\n  and a lot of RFCs were written and discussed\n  (from my subjective viewpoint, a lot of discussion was around the ergonomics initiative).\n- Four Rust conferences took place.\n  I went to the two RustFests\n  in [Kyiv] and [Zürich]\n  and really loved how enthusiastic everyone was!\n- The dev tools team was formed\n  – with me as a member –\n  and discussed a number of diverse topics\n  from the next version of rustdoc,\n  the future of rustup components (clippy and rustfmt, yay!),\n  to testing frameworks (very recent).\n  This teams also has a set of \"dev tool peers\",\n  who experts in specific fields\n  (and who in contrast to the core members only join some of the meetings).\n- The first-ever [\"impl period\"] took place,\n  where from September to the end of the year\n  a lot of (new!) people helped with\n  implementing and stabilizing features\n  (i.e., focus on implementing stuff instead of writing new RFCs).\n\n[Kyiv]: http://2017.rustfest.eu/\n[Zürich]: http://zurich.rustfest.eu/\n[\"impl period\"]: https://blog.rust-lang.org/2017/09/18/impl-future-for-rust.html\n\nRust 2018: Consolidation\n\n[Nick Cameron][nrc] wrote a really good \"Rust 2018\" post already,\nasking us to keep 2018 \"boring\":\n\n[nrc]: https://www.ncameron.org/blog/rust-2018/\n\n> I would like 2018 to be a year of consolidation on 2017's gains, of paying down technical debt, and polishing new things into great things.\n> More generally, we could think of a tick-tock cadence to Rust's evolution - 2015 and 2017 were years with lots of big, new things, 2016 and 2018 should be consolidation years.\n\nThis is something I can agree with\n-- there are a lot of project that are ongoing\nand I would love to see them become usable by a lot of people.\n\nRapidly reduce the number of in-flight unstable features.\n\nThe [unstable book] currently lists 113 language features and 155 library features.\nI think a lot of people have a few favorite features they've been waiting for.\nIn fact, I asked just this question at the Rust Cologne meetup yesterday,\nand – in addition to a great discussion about some of the features –\nwas reminded of some features whose RFC I've read years ago,\nbut that have not landed yet.\n\n[unstable book]: https://doc.rust-lang.org/1.23.0/unstable-book/\n\nI believe that\na lot of these features are not inherently complex,\nit just takes a lot of time and concentration\nto get them to a state where the team is confident\nthat they can be stabilized.\nI would love to see a team formed that,\nsimilar to the libz blitz initiative,\nfocuses on stabilizing features.\nI think that by having a team\nthat helps set the stage for a stabilization\n(by getting blockers out of the way,\nby documenting the precise requirements and process\nthat it takes to stabilize each feature,\nand by offering mentoring and guidance),\nshort-lived strike teams tackling singular features\nwill become viable.\nI think something like this is often already happening implicitly,\nbut having an official initiative will hopefully invite new people\nand making this scale a bit better.\n\nJust for the record, here are some of my favorite unstable features:\n\n- try_from\n- (advanced_)slice_patterns\n- associated_type_defaults\n- const_fn (and const_indexing)\n  – even if this is very conservative at first, let's get this [miri] goodness to the people!\n- (conservative_)impl_trait\n- generators\n- and of course proc_macro\n\nUpdate:\nRelevant thread on Twitter (started by Manish).\nAlso, I propose\nto call this effort to form small teams to stabilize features\n\"Rust Stabilization Meta Strike-Force\".\nIt should, however, only be written in its abbreviated form (RuStMeS).\n\nContinue doing and promote foundational work.\n\nIn addition to the concrete features listed above,\nI know of some projects that are more about foundational work\nand that enable a whole set of new features to be worked on.\nJust like MIR,\na refactoring of the compiler that happened over the last years,\nwhose goal was to pay off technical debt in the rustc codebase\nand to enable better codegen with custom optimizations,\nthe quest for incremental compilation has cause\na lot of work has been done in the last year\nto make the compiler more \"queryable\".\nThese efforts, as well as many others,\nare fundamental improvements that\nnot just increase the productivity of people implementing features\nbut hopefully also prevent people from no longer contributing\n(because they are frustrated with the code base)\nas well as invite new contributors\nthat are looking for \"applied computer science\" work.\n\n(I have to admit:\nI'm a huge fan on [Niko Matsakis' blog][babysteps]\n(his articles on Chalk are amazing),\nand would love to see more people talking and writing\nabout the theoretical aspects of Rust!)\n\n[babysteps]: http://smallcultfollowing.com/babysteps/ \n\nProvide a way to quickly find where you can help out and get mentoring.\n\nThere are some _huge_ RFCs that have been approved\nbut there is no implementation going on right now.\nAlso, there are some great efforts that exist outside of the usual issue tracker\n– e.g., the super interesting stuff happening in [chalk], [miri], and even [clippy]\nis not that easy to find if you're a newcomer to the project.\n\n[chalk]: https://github.com/rust-lang-nursery/chalk/\n[miri]: https://github.com/solson/miri\n[clippy]: https://github.com/rust-lang-nursery/rust-clippy\n\nIn addition, one thing that seems to have really made the aforementioned \"impl period\" a success\nwas that a lot of issues (and workgroups) had mentoring available\nto help people who have never interacted with the Rust project\nbecome productive real quick.\nSome of the open issues were collected\non the [\"find work\"][findwork] page of rustaceans.org\nwhich I've personally linked to a few times.\nWe should improve this page,\nand try to combine it with an overview of not only projects\nbut also RFCs\nand community efforts\nto give newcomers and long-term community members alike a place\nwhere they can see what's happening right now\nand where they can help out.\n\n[findwork]: https://www.rustaceans.org/findwork\n\nLand stable development tools.\n\n[rustfmt] and [clippy] are on their way to being available in a stable release\nas rustup components,\nand [RLS] is available as a preview.\nThese are huge blockers for people who want to use stable right now,\nand even though I don't think it's that big of a deal to use nightly,\nI'd love to have these tools available to as many people as possible.\n\n[rustfmt]: https://github.com/rust-lang-nursery/rustfmt\n[RLS]: https://github.com/rust-lang-nursery/rls\n\nMy own [rustfix] tool is a small shim\non top of the compiler's JSON output\nand the huge list of clippy lints.\nMy goal is to get a version of it that works in RLS\navailable this quarter.\n\n[rustfix]: https://github.com/killercup/rustfix\n\nAim for long-term stability of the library ecosystem.\n\nThe number of crates on crates.io almost doubled in 2017\n– but quantity isn't everything.\nThe [libz blitz] effort brought us [API guidelines]\nas well as improvements to a bunch of crates\n(cf. the [Rust 2017 roadmap review][rust-in-2017] post),\nsome of which have had 1.0 releases.\n\nUpdate: Aaron published a post about\n[Retooling the Rust Libs Team team for 2018][libs-mission]\nwhich touches some of the points discussed here\nbut from the perspective of the libs team.\n\n[libs-mission]: http://aturon.github.io/blog/2018/01/16/libs-mission/\n\nCommunity-maintained crates\n\nI really want to see this effort continued,\nbut I also want it to be expanded.\nI don't have a concrete proposal how to get this going right now,\nbut I'd love to see more community-maintained crates.\n\nThere is no reason why so many popular crates should live in user-repos\ninstead of in community-managed organizations\n(speaking in Github terms).\nWriting and then publishing a bunch of code as a crate one thing,\nbut maintaining it, fixing bugs, replying to issues and pull requests,\nthat takes up a lot of time as well.\nTime, that a lot of developers don't have,\nor don't want to invest.\n[cargo-edit], for example,\nwhich lives under my Github username,\nhas two wonderful maintainers,\nwho are more active than I am.\nBut should I create a cargo-edit organization and move the repo there?\nIf there was a good and definitive answer, which would\nneither make me deal with the organizational aspects\nnot result in accumulating lot of junk code,\nI'd be really happy.\n\n[libz blitz]: https://blog.rust-lang.org/2017/05/05/libz-blitz.html\n[API guidelines]: https://github.com/rust-lang-nursery/api-guidelines\n[Rust-in-2017]: https://blog.rust-lang.org/2017/12/21/rust-in-2017.html#rust-should-have-10-level-crates-for-essential-tasks\n[cargo-edit]: https://github.com/killercup/cargo-edit\n\nThis is also a people problem.\nTo establish Rust as an established language in the industry\nand to deliver and maintain production ready crates,\nwe need full-time developers\nwho can act as team leaders\nand maintainers for community-owned crates.\nAnd the next question is:\nWho pays these people[^like-me] to work on open source and Rust\nfor a large segment of their work time?\n\n[^like-me]: cough Did I mention I'm a freelancer with lots of Rust experience? cough\n\nUp",
  "title": "Rust 2018",
  "updatedAt": "2018-01-10T00:00:00.000Z"
}