Setting our vision for the 2017 cycle


One thing that I discussed with @aturon a while ago would be building the fundamentals for a scientific Rust stack. It’s not a lot of effort to get the initial core fundamentals out, but once it’s there it would be a central place that other disparate projects could build upon. Think NumPy ndarrays for Python, the Julia NDArray, a subset of Eigen, etc.

The core primitives could be:

  • a core ndarray abstraction
  • BLAS wrappers on top of these
  • scientific functions on these arrays (e.g. the vector operations in MKL/Accelerate/NumPy)

Some inspirations from the C++ side (that are probably overly generic but are reasonable) are Eigen and mshadow.

With these, the scientific Rust ecosystem would have a central place to build upon.


This is the most important thing for me. There are things which I am currently incapable of binding properly in winapi due to a lack of FFI features. Things like unions, #[repr(align(N))], #[repr(packed(N))], bitfields, COM calling conventions, dlimport, static-nobundle, unsized types with thin pointers, and more. In fact, I don’t think Rust has had a single FFI feature implemented since 1.0 (the most useful thing for me that did happen since 1.0 was making glob imports actually work). Several of those features I listed even have accepted RFCs, so I have hope, but seeing them take so long to be implemented, nevermind stabilized, is really demoralizing.

This is also hugely important, not just for me but for everyone. I’m going to some fairly extreme lengths in winapi just to minimize the amount of code that has to be compiled so compile times can be fast: getting rid of almost all trait impls, making enums simple integer constants, and abusing cargo features. I only have about 10% of the code currently compiling in winapi 0.3 but it already takes 4 seconds to build. So, when I do eventually get everything updated, should I look forward to 40 second compile times?


I think it would nice to have a few thorough guides that cover features that many older mainstream languages have but rust doesn’t.

Just a few things that come to mind:

  • Working with generics.
  • How todo OOP in rust.
  • Working with Iterators.
  • How to do error handling without exceptions.


One thing we’ve talked about quite a bit but never quite gets off the ground is a single “derive” for common data-types.


// equivalent to
#[derive(Copy | Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug)
// what about Default and Zero? Should Data include them if possible?


This is a beautiful example of the kind of curve-bending that the Rust community has gotten so good at. Instead of just assuming that some ostensible tradeoff is a hard tradeoff, identify ways to get many of the benefits of both solutions at the same time.

That shrinks down the set of cases that aren’t reasonably handled by the default (in this case, codebases with both fast-hash requirements and significant code size limitations), which makes the justification for escape valves much easier for users to understand.

Help wanted: fast hash maps in std

One thing that could be improved with #[no_std] is getting some of the core crates (like alloc) stabilized.

I’m a little confused about that one in particular – are we likely to be changing alloc::heap::allocate in the future? It seems pretty basic to me.

[Roadmap 2017] Needs of no-std / embedded developers

I don’t know a lot about this, but I’m curious why you would not want to use cross-compilation, e.g. with something like a MUSL target that has basically zero dependencies.


It feels like we have a body of data now – it’d be good to know what sets of traits are commonly implemented together. I feel like one of the problems with a shorthand like that is that I fear everybody has a slightly different subset in mind.


Doesn’t at least somewhat cover this for now? (I admit, native support would be nicer).




For 2017 I would like to see two things.

  1. Serde json should work out of the box on stable release channels with no customizations to my build for code gen. This has been a sour spot in the past year as the community transitioned off of rust serialize to serde where rust serialize worked out of the box and serde required build assembly. Effortless Json support is kind of a bid deal when it comes to network services. We should make rust more seemless to get up and running with a good json lib on the stable channel.

  2. more ferris. Or to somehow make ferris more official. It’s weird there’s an unofficial mascot and an official logo. I’ve personally seen this cause confusion. Rust should have a consistent branding. It deserves it! 2017 could be the year of ferris. Let’s make it happen.


I was one of those people who bounced off Rust. It has a lot of things I like, so I keep checking back to see if it has what I need yet. I’m glad you’re looking into usability and learning curve. We evaluated Rust vs Go at my last company, and a couple of us found that after 2 days learning Go we were productive, and after 2 days learning Rust we were fighting it. I feel like I need a few things: better error messages, an IDE that can tell me “what type is this expression”. The hardest thing was the type system and especially around the reference checking types. I got stuck between the difference of “what type needs to go here” and “what type is the expression I just wrote”. Error messages got better lately, more of that please! I hope the IDE support comes along soon too. (I like Emacs, but could see switching to Sublime). Thanks! I hope Rust keeps growing.


A fix for type inference regressions. It should be possible for crates to record fully qualified function names somewhere and use these when type inference fails.

  1. All packaged crates (e.g., on should include this information so that rust upgrades never break type inference for dependencies.
  2. Rust could also store this information in the target directory and provide an option to “fix” one’s code on upgrade. Alternatively, it could store it in some file analogous to Cargo.lock. That way, it could be checked into version control so that anyone downloading the code can benefit from it.

IMO, this would cover most cases. However, crater should probably turn this feature off so we can avoid introducing type inference regressions in the first place when possible.

This isn’t quite as straightforward as it appears as plugins aren’t deterministic however, most plugins use fully qualified function names anyways.


I think improve rust-lang self should be the highest priority task in a year or two, [Zeroing in: closing gaps in our key features] (

As as rust beginner, I am most concerned about is the [Non-lexical lifetime] ( and Plugins. I thinks rust’s lifetime system all are naturally (of course not easy) except lexical lifetime checker,but this key feature appears to be little progress. for compiler plugins,thanks Procedural macros 1.1, but Procedural macros 2.0 also seems couldn’t finish in a short time.


I don’t particularly want any language features. They’re nice to have, but I feel that the gain from adding new language features at this point is pretty marginal. You can see that in this thread: everyone really, really wants one different language feature. If we work on some language feature that one in 10 people wants, we disappoint the other 9 in 10 people.

In particular, I think that the importance of non-lexical lifetimes shouldn’t be overstated. It’s something I’d like for sure, but I’d caution against “we can compete with Go [or substitute any other GC’d language] if only we had non-lexical lifetimes” reasoning. We will never free the programmer from having to learn about lifetimes. We will never have as low a learning curve as Go/etc. in the memory management department. Competing there should be a non-goal. (That said, it’s absolutely worth making lifetimes easier to use, of course.)

Compiler improvements are welcomed; I’d love to see incremental compilation and MIR improvements.

By far, though, the most important thing to me is having a good story around servers. Right now, when you want to write a network-facing app in Rust, you have a myriad of choices, each of which with significant drawbacks. I’d like to see the futures/async I/O stuff finished, which would solve this problem in an elegant and Rusty way.

A meta-note: I’d like to humbly request that people refrain from further “I’m disappointed that X isn’t implemented yet” comments. They don’t move the discussion in any productive direction. Consider that “I’m demoralized” comments apply not only to you as a user but also to us as compiler developers. Let’s focus on the concrete use cases.


I agree. In according with the Scheme mantra I want to remove features, making things like destructors and Box less weird. It’s hard to articulate an end-user-centric motivation for tgis, and thus it’s not the highest priority. So given that progress on that front will be slow, less new features is the next best thing.


My own thoughts on this subject mostly center around one goal: getting more people and companies using Rust. I would very much like to see more than Rust 1 or 2 jobs advertised at the bottom of TWiR this time next year, and I would guess that I’m not alone.

Increasing adoption can happen a lot of ways, and I think many (if not most) of those avenues have already been raised here. But why shouldn’t this roadmap include a high-level item for organizing those efforts? “Rust should significantly grow its commercial user base.” ?

Also as I’ve spent time gathering data on Rust progress and infrastructure for the dashboard (although it has admittedly been slow going lately), I’ve seen that there is a significant amount of time spent dealing with testing/CI/release infrastructure. The number of @bors retries always seems rather high to me, as does the number of failed nightlies many months (although this month seems not too bad).

I admit some bias here, but perhaps it is worth focusing organization and efforts to continue improving Rust’s automation and allow stability without stagnation to move forward as quickly as possible? “Rust should increase the stability and utility of its infrastructure and automation.” ?

I think the second of my two thoughts here is harder to rally around (there are only so many people who can twiddle bits on the buildbots, for example), but tools like buildbot, crater, and bors seem to me to be pretty integral to much of the progress which Rust has already made and will continue to make.

EDIT: I should also throw in that from my perspective, better server/service tools are quite possibly the best bet for Rust to achieve greater adoption. It’s undeniable how much software is written these days to serve web or mobile content, not to mention the more bespoke high-performance server environments where Rust could really shine.


In the spirit of focusing this conversation on high-level, year-long goals, here’s an updated summary (with links to originating or related comments), sorted by number of comments I tallied. Please let me know if I’ve missed or misrepresented anything and I’ll fix it ASAP.

  • Rust should provide a more seamless FFI story root 16 38 44 48 49 50 53
  • Rust needs better answers (either guides, outreach, or new features) for teams & programmers coming from OOP – this seems very related to “Rust should have a lower learning curve” to me, but could be distinct if it covers type system features for inheritance? 3 6 8 14 26 54
  • Rust should have a lower learning curve root 4 6 9 54 63
  • Rust needs a better story for embedded development (re: no_std) 9 28 45 57
  • Rust should be well-equipped for writing servers root 9 66 68
  • Rust should have basic IDE support root 9 63
  • Rust needs better publicly available information and guides about improving performance for common programs (i.e. hashing), or it needs to refocus its efforts on providing fast-by-default tools in std and common crates 17 37 (I know I missed a few here, but it’s late)
  • Rust needs better testing and doc generation across conditional compilation directives 16 24
  • Rust needs cleaner integration with the system toolchains it depends on 30 33
  • Rust needs to better support HPC and other scientific applications. (type level values, proc macros, CTFE, variadics, HKT) 48 52
  • Rust should have 1.0-level libraries for concurrency and parallelism root 9
  • Rust’s community and processes need better visibility to “casual” participants and newcomers (e.g. RFC visibility and dashboards, also casual is a bad word for this, but I can’t think of a better one here) 9 61
  • Rust’s compiler should be significantly faster root 53
  • Rust’s support for compile-time code generation should be improved and stabilized, especially for those uses that are already encouraging many users to stay on nightly (custom_derive in particular) 9 62
  • Rust development should be fundable by the community. 16
  • Rust needs 1.0-level libraries for scientific computing (matrix manipulations, BLAS wrappers, vector functions) – see Eigen and mshadow 52
  • Rust needs clearer, more consistent branding. 62
  • Rust needs to define and execute better processes for improving documentation and guides across the ecosystem, but especially for core projects 21
  • Rust needs to grow its support for platforms other than x86 (and beyond ARM too) 28
  • Rust needs to improve discoverability of community projects and initiatives which address our goals. 51
  • Rust needs to improve its distribution story for environments without internet access. 48
  • Rust needs to simplify existing features, and potentialy remove ones that introduce complexity. 67
  • Rust needs to suffer fewer regressions (in type inference, for example). 64
  • Rust should improve its syntax for usability of common cases. 55
  • Rust should increase the stability and utility of its infrastructure and automation. 68
  • Rust should significantly grow its commercial user base. 68
  • Rust’s community should provide mentoring at all levels root
  • Rust’s core ecosystem should be maturing root
  • Rust’s ownership system needs to aid in modelling more complex systems (i.e. parent/child communication) 3
  • Rust’s tooling needs to be first-class to aid adoption (beyond IDE support, i.e. rustdoc) 16


At the risk of proposing solution statements instead of problem statements…

There’s a bunch of really important ideas here that look ripe for delegation, distribution, and documentation. Hey, if @steveklabnik can use producer-consumer as an analogy, then I can call these the fork and join model of open source project management. :smiley:

How about a light SIG (special interest group) model to coalesce and promote Rust work in particular areas, tentatively named “Rust Accelerators” so we have a noun to work with? Groups with immediate potential plucked from the top of my head:

  • Ruby
  • Python
  • JavaScript
  • Scientific computing
  • Bare metal (could call it “Embedded”, but there are some useful differences)

I haven’t included “server development” on this list because it’s far too broad a topic, but groups that focus on some aspect of server dev would be prime candidates, such as web dev.

Groups should be robust enough to changing or different needs within their domain, such as different approaches to creating bindings. Yes, it’d be nice if everyone used the same stuff, but diversity in evolution is also important. A good bit of Rust culture to impart.

These groups can also form the basis for future efforts such as the proposed SDK-style crate combos. Maintenance of meta crates could be given to the group leaders, etc.

What would a Rust Accelerator get?

  • A patron from the Rust team, prior to blessing the group as official and/or its leaders as Rust team members (this is a bootstrapping step, helps distribute the Rust culture, etc.)
  • A section or tag on the Rust Discourse instances
  • A tag on the Rust bug tracker, to indicate Accelerator interest in a given issue (does bors have a “this user can add/remove this tag” function?)
  • One page (only one!) to author and maintain in the Rust Book, to briefly introduce Rust in that domain and link to further info / docs
  • A link on the web site or pages on the wiki that come with implied project endorsement
  • Future stuff, such as administrative oversight of SDK-style crate aggregations, etc.
  • Responsibility to report on group activities to the core team, assisted with helpful project infrastructure such as forum / bug tracker tag summaries, crate updates, and so on (some of this exists for TWIR, but we could automate a lot more, give dashboards to groups)

Why do it like this?

Delegate: We want the Rust core team to have as much time as possible for hacking, merging, writing, problem solving, etc., so let’s build a structure to allow new folk to make decisions and herd cats in their areas of interest. Giving someone responsibility is a great way to encourage them to rise to the occasion.

Distribute: In the usual sense that work shared is work halved (assuming perfect scal– never mind), but also: Groups become ambassadors and contact points for Rust in other communities of interest, grow new contributors, etc.

Document: In the technical sense and the social sense. Each group provides (at the very least introductory) technical documentation about their domain, but the existence and structure of the groups provide a map of the Rust community for newcomers. New pathways and answers to, “How do I get involved?”

What do you reckon?


I think they were trying to list things that others in the thread haven’t said. Just because I haven’t asked for type-level integrals in this thread, it doesn’t mean I am not looking forward for them.

There are important features that will help Rust, beside type level integral values.

No one has asked every person in this thread to write down a complete list of all the features they need/desire. So you can’t use this thread to judge and conclude what features people want, or what they don’t want.