From bf8611e9576127aecde2cdba4ba932fbf8309cdd Mon Sep 17 00:00:00 2001
From: Aaron Turon <aturon@mozilla.com>
Date: Mon, 29 Jan 2018 16:13:13 -0800
Subject: [PATCH] roadmap 2018

---
 text/0000-roadmap-2018.md | 412 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 412 insertions(+)
 create mode 100644 text/0000-roadmap-2018.md

diff --git a/text/0000-roadmap-2018.md b/text/0000-roadmap-2018.md
new file mode 100644
index 00000000000..a1d5a0870ef
--- /dev/null
+++ b/text/0000-roadmap-2018.md
@@ -0,0 +1,412 @@
+- Feature Name: N/A
+- Start Date: 2018-01-23
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+
+This RFC sets the *Rust 2018 Roadmap*, in accordance with [RFC 1728](https://github.com/rust-lang/rfcs/pull/1728). This year's goals are:
+
+
+- Ship an epoch release: Rust 2018.
+- Build resources for intermediate Rustaceans.
+- Connect and empower Rust’s global community.
+- Grow Rust’s teams and new leaders within them.
+
+In pursuing these goals, we will focus particularly on four target domains for Rust:
+
+
+- Web services.
+- WebAssembly.
+- CLI apps.
+- Embedded devices.
+
+# Motivation
+
+This proposal is a synthesis drawing from several sources:
+
+
+- The [2017 survey](https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html).
+- [Nearly 100 blog posts](http://readrust.net/rust2018/) written in response to [our call for roadmap thoughts](https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html); these posts are quoted liberally throughout the RFC.
+- The core team’s overall sense of the zeitgeist and project management.
+
+The motivation and detailed rationale of each piece of the roadmap proposal is explained in-line throughout the RFC; the closing section covers the high-level rationale.
+
+# Guide-level explanation
+> [I believe that Rust has the potential to be an exceptionally empowering technology for people writing programs. I am trying to focus on providing the ‘last mile’ of user experience to take the core technological achievements of Rust and make them generally ergonomic and usable by working programmers.](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) (@withoutboats)
+
+This year will be a focused one for the Rust community, with two overall technical goals, and two social ones. Here we’ll give a brief overview of each goal and some overarching themes, and in the Reference section below we’ll provide full detail.
+
+
+- **Ship** ***Rust 2018***. We will ship a major marketing (epoch) release in the final third of the year, with the unifying message of *productivity*. We will polish and stabilize a number of already-implemented language features like `impl Trait`, generators, non-lexical lifetimes and the modules revamp—and very few new ones. We will also drive critical tools (like the RLS and rustfmt), libraries, and documentation to 1.0 status. We will overhaul the http://rust-lang.org/ site to help market the release and to support programmer productivity.
+
+
+- **Build resources for intermediate Rustaceans**. We will write documentation and build examples that help programmers go from basic knowledge of Rust’s mechanics to knowing how to wield it effectively.
+
+
+- **Connect and empower Rust's global community**. We will pursue internationalization as a first-class concern, and proactively work to build ties between Rust subcommunities currently separated by location or region. We will spin up and support Rust events worldwide, including further growth of the RustBridge program.
+
+
+- **Grow Rust's teams and new leaders within them**. We will refactor the Rust team structure to support more scale, agility, and leadership growth. We will systematically invest in mentoring, both by creating more on-ramp resources and through direct mentorship relationships.
+
+To make our product successful, we should build and market it with an eye toward *specific user stories*, ensuring that we have a coherent and compelling end-to-end experience. Thus, investment in ecosystem, marketing, and feature prioritization will emphasize the following four domains in 2018:
+
+
+- **Web services**. The predominant domain for current production usage.
+- **WebAssembly**. An emerging market where Rust is strongly positioned for success.
+- **CLI apps**. A place where Rust’s portability, reliability, and ergonomics come together to great effect.
+- **Embedded** **devices**. A domain with a great deal of potential that is not yet first-class.
+
+Looking at the year as a whole, with our second marketing release of Rust, @nrc perhaps put it best:
+
+
+> [At the end of the year I want Rust to feel like a really solid, reliable choice for people choosing a programming language.](https://www.ncameron.org/blog/rust-2018/) (@nrc)
+
+# Reference-level explanation
+
+## Goals
+
+### Ship Rust epoch 2018
+
+
+> [Aiming for a major product release gives us an opportunity, as a community, to come together and do something](http://aturon.github.io/blog/2018/01/09/rust-2018/) [big](http://aturon.github.io/blog/2018/01/09/rust-2018/) [that goes well beyond the usual six week cycle.](http://aturon.github.io/blog/2018/01/09/rust-2018/)
+>
+> [Releasing “Rust 2018” gives us a chance to say to the world that “Rust has taken a major step since 1.0; it’s time to take another look”.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon)
+
+The Rust epoch 2018 release encompasses every aspect of the work we do, so we’ll look at each area in turn. **This RFC is not intended as a** ***promise*** **about what will ship, but rather a strong (and realistic) intention.** The core team will ultimately oversee the precise timing and feature set of the release.
+
+It’s important to keep in mind two additional factors:
+
+
+- “Shipping” features in this context means they must be *stable*. We may land additional unstable features this year (like `const` generics), but these are separate from the Rust 2018 product. **We will stabilize features individually as they become ready,** ***not*** **in a rush before the epoch release.**
+
+
+- The intent is to ship Rust 2018 in the latter part of the year. The tentative target date is the 1.29 release, which goes into beta on 2018-08-02 and ships on 2018-09-13. That gives us approximately six months to put the product together.
+
+**These two factors together suggest that Rust 2018 will ship largely with** ***language*** **features that are already in nightly in some form today.** Other, faster-moving areas of the product will be developing new material throughout the year.
+
+As always, we will continue to push out new Rust releases on a six week cadence, so a given feature missing the epoch release is by no means fatal. On the other hand, we need to carefully coordinate the work so that the features we *do* ship sit together coherently across the compiler, tools, documentation, libraries and marketing materials.
+
+#### Language
+
+
+> [Rust 2018: Consolidation (](https://deterministic.space/rust-2018.html)@killercup)
+
+The most prominent language work in the pipeline stems from [2017’s ergonomics initiative](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html). Almost all of the accepted RFCs from the initiative are available on nightly, but polish, testing, and consensus work will take time:
+
+[](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/)
+> [I’d like to reach a final decision to ship or drop all of the ergonomics RFCs that were accepted. I hope to see this completed over the next several mont](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/)[h](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/)[s . . . I hope we can have a clearer (and more spaced out) schedule for this so that their FCPs are staggered.](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) (@withoutboats)
+
+Among these productivity features are a few “headliners” that will form the backbone of the release:
+
+
+- **Non-lexical lifetimes**. Currently in “alpha” state on nightly, with work ongoing.
+- `**impl Trait**`. Nearing readiness for stabilization FCP.
+- **Generators**. “Beta” state on nightly, but some design issues need resolution.
+- **Module system changes**. Largely usable on nightly; will need testing, feedback, and bikeshedding.
+
+In addition, there are some other headlining features which are nearing stabilization and should ship prior to the epoch:
+
+
+- **SIMD**. The core SIMD intrinsics are nearing readiness for stabilization, and with luck we may be able to stabilize some vendor-agnostics primitives as well.
+- **Custom allocators**. TODO
+- **Macros 2.0**. This feature is implemented and working, but stabilization will require us to reach a comfort level with the handling of hygiene and a few other core issues.
+
+Between generators and macros 2.0, we will have *some* support for async/await on stable Rust (possibly using macros, possibly some other way).
+
+Finally, there are several highly-awaited features that are **unlikely to ship** **in the Rust 2018** **epoch release** **(though they may ship later in the year):**
+
+
+- **Generic associated types**. This feature will almost certainly land in *nightly* in 2018, and may even stabilize during the year. However, enough implementation work remains that it’s unlikely to be stable prior to the epoch release.
+- **Specialization**. Stabilization is blocked on a number of *extremely* subtle issues, including a revamp of the trait system and [finding a route to soundness](http://aturon.github.io/blog/2017/07/08/lifetime-dispatch/). We cannot afford to spend time on these issues until after the epoch release ships.
+- **const generics**. This feature is likely to land in *nightly* in 2018, but will not be ready to stabilize this year given the substantial work that remains.
+
+#### Compiler
+
+
+> [Give me non-embarassing compilation speed!](https://matthewkmayer.github.io/blag/public/post/rust-2018/) (@matthewkmayer)
+
+Compiler work will center on:
+
+
+- Completing and polishing the language features mentioned above.
+- Continuing to improve compile times. By the end of the year, recompilations on large crates should be around 30s.
+- Another push on improving error messages.
+- Epoch tooling: adding an epoch flag and building `rustfix`, likely by leveraging lints.
+
+#### Libraries
+
+
+> [It is often stated that rust’s ecosystem is immature. While this is somewhat true, the real issue is in](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [finding](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [and](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [using](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [the pieces you need.](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) (@vitiral)
+
+
+> [Obviously, we cannot force people to choose one project over another, but it would be great if we could somehow focus our collective resources on fewer standard high-quality crates](https://llogiq.github.io/2018/01/09/rust.html). (@llogiq)
+
+
+> [We need more 1.0 production-ready crates to get people productive.](https://deterministic.space/rust-2018.html) (@killercup)
+
+
+> [The core team should participate in prioritizing and implementing quality crates for productivity needs.](https://medium.com/@nimtiazm/rust-and-crate-of-wishes-for-2018-1258f6977d42) (@nimtiazm)
+
+In preparation for the epoch release, we will continue to invest in Rust’s library ecosystem in three ways:
+
+
+- **Quality**. Building on our 2017 work, we will bring the API Guidelines to a 1.0 status and build out additional resources to aid library authors.
+- **Discoverability**. We will continue to work with the crates.io team on discoverability improvements, as well as push the Cookbook (or something like it) to 1.0 status as a means of discovering libraries.
+- **Domain-specific content**. We will work with library authors in the four domains of focus this year to sharpen our offerings in each domain (elaborated more below).
+
+#### Documentation
+
+Documentation plays a *critical* role in the epoch release, as it’s often an entry point for people who are taking a look at Rust thanks to our marketing push. With regards to the epoch specifically, this mostly means updating the online version of “The Rust Programming Language” to include all of the new things that are being stabilized in the first part of the year.
+
+We’ll also be doing a lot of work on Rust By Example. This resource is both critical for our users and also slightly neglected; we’re starting to put together a small team to give it some love, and so we hope to improve it significantly from there.
+
+There are two additional areas of vital documentation work for 2018, which are not *necessarily* tied to the epoch release:
+
+
+- **Resources for intermediate Rustaceans**. This topic is covered in detail below. It’s possible that some of these resources will be ready to go by the epoch release.
+- **Overhauled rustdoc**. There’s ongoing work on an RLS-based edition of rustdoc with internationalization support, and the ability to seamlessly integrate “guide” and “reference”-style documentation. As a stretch goal for the epoch, we could aim to have this shipped and major libraries using it to provide a better documentation experience.
+
+#### Tools
+
+As part of the Rust 2018 epoch release, we will:
+
+
+- Ship 1.0 editions of the RLS and `rustfmt`, distributed via `rustup`.
+- Distribute Clippy via `rustup`.
+- Stabilize [custom registries](https://github.com/rust-lang/rfcs/pull/2141) for Cargo.
+- Implement and stabilize [public dependencies](https://github.com/rust-lang/rfcs/pull/1977) in Cargo.
+- Revise Cargo profiles.
+
+Beyond these clear-cut items, there are a number of ongoing efforts, some of which *may* ship as part of the epoch:
+
+
+- **Xargo/Cargo integration**. Alternatively, this can be viewed as allowing `std` to be treated as an explicit dependency in Cargo, which has long been a requested feature and which is very helpful for cross-compilation (and hence for embedded device work).
+- **Build system integration improvements**. Seek to incrementally deliver on the [work laid out in 2017](https://github.com/rust-lang/rfcs/pull/2136). It’s unclear what pieces might be ready for stabilization prior to the epoch release.
+
+And a couple of goals that are probably a stretch for 2018 at all, let alone for the epoch release:
+
+- **Custom test frameworks**. There’s been [a lot of interest in this area](https://internals.rust-lang.org/t/past-present-and-future-for-rust-testing/6354/1), and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018.
+- **Compiler-driven code completion for the RLS**. Today the RLS still uses a purely heuristic approach for auto-completion. If the compiler’s new “query-based” architecture can be pushed far enough during the year, it maybe become feasible to start using it to deliver precise auto-complete information.
+
+#### Web site
+
+Many, many of the #Rust2018 posts talked about improving our web presence and the marketing therein:
+
+
+> [Having a consistent, approachable, discoverable, and well designed web presence makes it easier for visitors to find what they’re looking for and adds signals of credibility, attention to detail, and production readiness to the project.](http://www.wezm.net/technical/2018/01/goals-directions-rust-2018/) (@wezm)
+
+
+> [Goal 2: Explain on rust-lang.org who the Rust programming language is for](https://jvns.ca/blog/2018/01/13/rust-in-2018--way-easier-to-use/) (@jvns)
+
+
+> [We think it’s time to trumpet from the mountaintops what the Rust community has known for a while: Rust is production ready.](http://integer32.com/2018/01/05/more-rust-in-2018.html) (Integer 32)
+
+
+> [We should have a polished web site that works for both engineers](http://aturon.github.io/blog/2018/01/09/rust-2018/) [and](http://aturon.github.io/blog/2018/01/09/rust-2018/) [CTOs, offering white papers and directing companies to sources of training, consulting, and support.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon)
+
+
+> [Promote Rust as a language that makes large codebases maintainable.](https://deterministic.space/rust-2018.html) (@killercup)
+
+
+> [I suggest in 2018, we kick the idea of wrestling with the Rust compiler to the curb and focus on how it helps us rather than the idea of it beating us down.](http://www.jonathanturner.org/2018/01/how-we-talk-about-rust-in-2018.html) (@jonathandturner)
+
+As part of the 2018 epoch release, we will **completely overhaul the main Rust web site** with:
+
+
+- **A new, striking visual design**, which will eventually be used across all of our web sites (including crates.io).
+- **Vastly improved marketing materials**, including dedicated pages for all four of this year’s “user stories”.
+- **Much more extensive resources** useful for being productive with Rust, e.g. dedicated pages for Rust’s tooling story that make it easy to discover the state of the art and choose the best tools for you. Also links to various media resources (videos etc.)
+
+### Build resources for intermediate Rustaceans
+
+
+> [We, as a community, should work on creating the next level of learning resources to help folks deploy Rust to production with confidence.](http://integer32.com/2018/01/05/more-rust-in-2018.html) (@integer32)
+
+
+> [This includes discussions on how to structure big projects in Rust and Rust-specific design patterns. I want to read more about professional Rust usage and see case-studies from various industries.](https://matthias-endler.de/2018/rust-2018/) (@mre)
+
+
+> [Once you have a grasp of what knobs do what in the language, how do you learn what’s considered “proper”, or what structures people have found to make future maintenance easier?](https://quietmisdreavus.net/code/2018/01/10/not-a-layer-cake-analogy/) (@QuietMisdreavus)
+
+One of the strongest messages we’ve heard from production users, and [the 2017 survey](https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html), is that people need more resources to take them from understanding Rust’s concepts to knowing how to use them *effectively*. This roadmap will not stipulate exactly what these resources should look like — [probably there should be several kinds](https://quietmisdreavus.net/code/2018/01/10/not-a-layer-cake-analogy/) — but commits us as a community to putting significant work into this space, and ending the year with some solid new material.
+
+The [post by QuietMisdreavus](https://quietmisdreavus.net/code/2018/01/10/not-a-layer-cake-analogy/) offers a wealth of ideas.
+
+### Connect and empower Rust’s global community
+
+
+> [“Additionally, more venues should be created to work with production users to gather regular feedback in a convenient, scalable way.”](http://integer32.com/2018/01/05/more-rust-in-2018.html) (Integer 32)
+
+
+> [We should ask how to improve support for local meetups to strengthen community cohesion](https://llogiq.github.io/2018/01/09/rust.html). (@llogiq)
+
+
+> [Mentorship does a lot to help underrepresented groups of people.](https://medium.com/@blackdjikstra/rust-in-2018-d6c0be87cba8) (@blackdjikstra)
+
+
+> [“What can](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/) [I](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/)[, or other people not one the core team, do to help stabilize Rust?”](https://willmurphyscode.net/2018/01/18/how-can-i-help-stabilize-things/) (willmurphyscode)
+
+
+> [Rust is very new and most of the documentation coming out is probably going to be in English because it is the most widely used language. However, we have to acknowledge that we don’t only have english speakers in the rust community and it would be great if some of the text was translated to accommodate non English speakers.](https://medium.com/@blackdjikstra/rust-in-2018-d6c0be87cba8) (@blackdjikstra)
+
+**This year's community team focus is building capacity by growing leaders and empowering new communities.** At a high level, by the end of 2018, the Rust Community Team should have:
+
+
+- Clearly defined **processes for engaging with, joining, and growing one’s role** within the team
+- Onboarded **new members from communities around the world**
+- Grown existing **members into leaders** of new and existing initiatives
+- Run, supported, and/or facilitated **events in a diverse set of communities**, including industry trade fairs, colleges and universities, and geographic locations that are currently underserved by technical events
+- **Expanded accessibility** of Rust resources (including Internationalization!)
+- **Organized data** for assessing and analysing progress on the above goals
+
+You can read more about these goals in the [2018 Community Team Goals RFC](link needed).
+
+### Grow Rust’s teams and new leaders within them
+
+
+> [I'm convinced, that by improving documentation and mentorship, we can grow the number of contributors significantly and stabilize many highly-anticipated features this year.](https://matthias-endler.de/2018/rust-2018/) (@mre)
+
+> [We need to Think Big when it comes to Rust’s teams.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon)
+
+> [Initiatives like the libz blitz put the libs team within the community and put the community within the libs team. I think the shared sense of ownership over the Rust project is what keeps it moving forward.](https://gist.github.com/KodrAus/953e8182e81d8d9147cd32822748665f#a-libz-blitz-retrospective) (@kodraus)
+
+Last year saw a lot of growth in Rust’s teams, and we’ll need to keep that up in 2018 if we want to accomplish everything we’ve set out above! To do that, we will:
+
+- **Revise the subteam structure** by breaking up and delegating tasks from the current teams to new teams that they manage, as appropriate. This will allow us to expand the number of people working on the teams overall, while keeping each team at a manageable size. So, [for example](http://aturon.github.io/blog/2018/01/16/libs-mission/), the Libs Team can form child teams dedicated to `std`, API guidelines, discoverability, and more. Also, as with the [impl Period](https://blog.rust-lang.org/2017/09/18/impl-future-for-rust.html), we will feel more free to spin up “working groups” to target some specific concern, often with a clear-cut end goal. This RFC creates a few such working groups; other team changes will be decided on and announced by the relevant teams.
+
+- **Create more contributor resources**, like the [new book](https://internals.rust-lang.org/t/so-you-want-to-hack-on-the-rust-compiler-a-plan-for-a-book/6497) focused on compiler contribution.
+
+- **Systematize mentoring**, by improving tools like [findwork](https://rustaceans.org/findwork) and developing best practices for mentoring across teams.
+
+## Domains
+
+With many of the goals listed above, we have some choice about what use-cases to focus on. To help ensure that our Rust 2018 product has a coherent story, we will focus on four target markets that have either already seen Rust uptake, or where we believe that Rust has significant potential.
+
+We will spin up a separate working group for each of these domains, reporting to the core team, and tasked with looking after the end-to-end experience in that domain and making recommendations to other Rust teams with decision-making power.
+
+### Web services
+
+
+> [I think network services are a great opportunity for Rust](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/). (@withoutboats)
+
+
+> [I think it’s very important - especially for network programming - to see generators and async/await stabilized in Rust.](https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/) (@withoutboats)
+
+
+> [Tokio needs a lot of work.](https://www.reddit.com/r/rust/comments/7syxw4/rust_2018_core_embeddedsimd_intermesiate/) (@nicoburns)
+
+Rust sees heavy production use in the web services domain, both in implementing services directly and in providing [related infrastructure](https://buoyant.io/products/#products-Conduit). The domain was also a major focus in 2017. This year, we will push hard on making the end-to-end user experience in this domain solid and stable.
+
+### WebAssembly
+
+
+> [I believe that WebAssembly is about to take off in a big way.](https://dirkjan.ochtman.nl/writing/2018/01/14/rust-in-2018.html) (@djc)
+
+
+> [We're poised to be](https://mgattozzi.com/rust-wasm) [THE](https://mgattozzi.com/rust-wasm) [language of choice for wasm.](https://mgattozzi.com/rust-wasm) (@mgattozzi)
+
+Late in 2017 [we added](https://github.com/rust-lang/rust/pull/45905) the “wasm32-unknown-unknown” target, making it possible to emit pure WebAssembly binaries from Rust, without any extra toolchain hassle. The interest has been explosive, with [some JS bundlers now offering Rust support out of the box](https://medium.com/@devongovett/parcel-v1-5-0-released-source-maps-webassembly-rust-and-more-3a6385e43b95). This is a brand new market with no incumbent and for which Rust is *extremely* well-positioned (read [@mgattozzi’s excellent post](https://mgattozzi.com/rust-wasm) for a comprehensive argument). We will work this year to make integration, tooling, and the library ecosystem as polished as we can manage. An informal working group is already coordinating [on GitHub](https://github.com/aturon/rust-wasm/).
+
+### CLI apps
+
+
+> [Rust is a fantastic language for writing a Command Line Application (CLI). For the ergonomics of hacking, it has one of the best argument parsers ever, has seriously the best serialization library ever and it compiles to almost any target and goes](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [fast](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) [when it runs.](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) (@vitiral)
+
+Rust has also seem some production update in the CLI space, for which it is very well-suited. This is a space where Rust’s portability, reliability, and ability to produce static binaries make it extremely attractive. We also have a number of excellent libraries already. This year, we will improve this ecosystem and pull it together into a polished, coherent package for people checking out Rust. Read [@vitiral’s post](http://vitiral.github.io/2018/01/17/rust2018-and-the-great-cli-awakening.html) and [@killercup’s crate](https://github.com/killercup/quicli) for some inspiration!
+
+### Embedded “bare metal” devices
+
+
+> [In 2018, I simply wish [the embedded community] could switch to beta or even stable!](https://medium.com/pollenrobotics/rust-for-robotics-and-embedded-systems-in-2018-96e9be8464) (Pierre Rouanet)
+
+
+> [I'd also like to see the core team think a little more about #[no_std] development.](http://railwayelectronics.blogspot.com.au/2018/01/i-recently-picked-up-embedded-project.html)
+>
+> [Let's make 2018 the year Embedded Rust goes mainstream!](http://railwayelectronics.blogspot.com.au/2018/01/i-recently-picked-up-embedded-project.html) (@thejpster)
+
+There’s always been simmering excitement around using Rust in the “bare metal” space, but among the domains we want to target, it’s needed the most work in terms of language features to fully support. While we cannot hope to stabilize *everything* needed for embedded development in 2018, we can step up our game and begin to treat the market as more mainstream. This intersects nicely with the WebAssembly work, since WebAssembly presents a very barebones machine model and will thus interact deeply with the `no_std` ecosystem.
+
+Check out [@japaric’s roadmap](http://blog.japaric.io/embedded-rust-in-2018/) for a plausible way forward.
+
+## Schedule and structure
+> [I want to see [2018] as an extended impl period.](https://manishearth.github.io/blog/2018/01/10/rust-in-2018/) (@Manishearth)
+
+The remainder of the year will be broken up into four chunks:
+
+
+- Feb — Mar: **Design and early work**.
+- Apr — July: **Buckling down**.
+- Aug — Nov: **Fun**!
+  - August 2: **Epoch in beta**
+  - September 13: **Epoch released**
+- Dec — EOY: **Reflection**.
+
+**Design and early work**. Coming off of the impl period, for the start of this year we’ll take some time to process RFCs, to plan, and to spike any late-breaking design ideas that could possibly ship in the Rust 2018 epoch release. We will, of course, continue to push on implementation and stabilization work at the same time. By the end of this period, we should have a very clear picture of what we will ship in the epoch, and what needs to happen to do that.
+
+This period culminates with the Rust Team All Hands in Berlin at the end of March.
+
+**Buckling down**. Structured much like the impl period, we will be laser-focused on making the epoch release as good as it can be. It will be a community-wide effort. Little to no design or RFC work will happen during this time. RustFest Paris and a Mozilla all-hands will happen during this time, and we will likely try to host “impl days” similar to last year.
+
+This period culminates with cutting the beta epoch release at the beginning of August, with RustConf following shortly after.
+
+**Fun**! Having pushed hard up to this point, for the remainder of the year we will relax our tight focus and allow for more exploration, as well as work on fun features like const generics, GATs, and specialization. Rust Belt Rust will happen during this period.
+
+**Reflection**. We’ll leave the month at the end of the year for retrospectives and 2019 planning, with the hope that we can start 2019 with a roadmap already in place.
+
+# Rationale, drawbacks and alternatives
+
+Here’s a high level rationale for the two major themes this year: shipping and community.
+
+## Shipping
+
+The data and discussion quickly coalesced around one of the basic contours for this year: a sense that a lot of important improvements are in the pipeline, and **what’s needed this year is a strong focus on** ***shipping***. As @nikomatsakis put it:
+
+
+> [We did good work in 2017: now we have to make sure the world knows it and can use it.](http://smallcultfollowing.com/babysteps/blog/2018/01/09/rust2018/) (@nikomatsakis)
+
+Or, in @nrc’s more provocative phrasing:
+
+
+> [I want 2018 to be boring.](https://www.ncameron.org/blog/rust-2018/) (@nrc)
+
+This sentiment is the foundation for this year’s technical work, and there’s a striking similarity to the spirit leading up to Rust 1.0. While shipping what’s already in our pipeline may be “boring”, it’s not easy. One of the hardest challenges for us as a community is the same one we faced with 1.0, one that @skade voiced succinctly:
+
+
+> [I’d like us to stabilise imperfect things.](http://yakshav.es/rust-2018/) (@skade)
+
+Shipping requires the discipline to say “no” to exciting new ideas, and to say “yes” to delivering on ones we fear are flawed. We have to iterate toward perfection, providing useful snapshots along the way.
+
+## Community
+
+Our work in 2017, especially during [the impl period](https://blog.rust-lang.org/2017/09/18/impl-future-for-rust.html), was the clear result of a community-wide effort. To do the hard work of “[polishing new things into great things](https://www.ncameron.org/blog/rust-2018/),“ and to keep up with Rust’s continuing growth, we need to double down on our investment in our community. That’s a theme with several facets, including project leadership:
+
+
+> [Rust is a staggeringly large project with a huge and talented community, and we need its leadership structure to reflect that if we are to reach our full potential.](http://aturon.github.io/blog/2018/01/09/rust-2018/) (@aturon)
+
+
+> [I want the community leadership to feel like a well-functioning machine, and that the larger community feels well-represented and can trust the leadership teams.](https://www.ncameron.org/blog/rust-2018/) (@nrc)
+
+continued mentoring:
+
+
+> [I’d like to see a stronger focus [on] mentoring.](https://manishearth.github.io/blog/2018/01/10/rust-in-2018/) (@manishearth)
+
+growth and outreach:
+
+
+> [Rust should actively be seeking out diversity.](https://medium.com/@softprops/rust2018-75393b4a086f) (@softprops)
+
+
+> [While we talk about “the Rust community”, the reality is that there are](http://aturon.github.io/blog/2018/01/09/rust-2018/) [many](http://aturon.github.io/blog/2018/01/09/rust-2018/) [Rust communities, separated by geography and by language. We need to do much more to connect these communities.](http://aturon.github.io/blog/2018/01/09/rust-2018/)(@aturon)
+
+and corporate involvement:
+
+
+> [I’m also hoping for more companies to invest back into Rust.](https://manishearth.github.io/blog/2018/01/10/rust-in-2018/) (@manishearth)
+
+That’s a lot! But it’s work that immediately pays dividends back into the project, both in terms of adoption and development.
+
+# Unresolved questions
+
+TBD