Setting our vision for the 2017 cycle

Agreed. To be clear, I think Rust absolutely is a modern, accessible, productive language. I only want to emphasize that we’ll never reach the state of “you don’t have to think about the lifetime of your data at all”, not that we shouldn’t focus on being as easy to use as possible.


My main problem with this is that we do not have good material for “I’ve never programmed before, let me learn with Rust.” Other languages have this, but we don’t.

I would love to do this, but there’s so much work to do, and I’m not sure that it’s the right call right now. See above looong comment about reactive vs proactive, this would be a fantastic proactive step.


Maybe it shouldn’t be you then? Someone else could write the “begineers guide to programming with rust” and you could just link it in the book. Or maybe people should take things off your plate so you can be more proactive :smile:

Something that should be noted is that for true beginners, the best resources are often videos – there is something about the human brain that needs to see others doing something to believe they are possible and easy. A book is often not enough. When I was first learning python, the google python class videos were invaluable. Watching that guy just hack away, give a quick project and then hack away some more could not have been replaced with a million pages of a book. I think having a sanctioned beginner’s video would be excellent for rust.


But I think the emphasis is that in C/C++ you also have to think about your “lifetime” – it’s just that the compiler doesn’t help you


In C/C++, you should think about lifetimes; in Rust, you must.


I think rustc's stage1 building speed needs to be significantly improved. Requiring 15 minutes to make -j3 rustc-stage1 is absolutely deterring contributions.

$ time make -j3 rustc-stage1
real    14m56.510s
user    22m38.593s
sys    0m45.972s
It also takes a long time to build anything depending on complex crates like syntex-syntax (~1 minute in debug, ~2 minutes in release), though it mainly just affect the first build of the project.([RFC 1681 "Macros 1.1"]( may deprecate `syntex` eventually, but not every syntax extension is about `#[derive]`-ing...)

RFC 1298 “Incremental Compilation” will help the edit-compile-test cycle, but we still need to improve the initial build time. (BTW why there is no tracking issue for 1298?)

For comparison, building D’s DMD takes only 7 seconds,

$ time make -f posix.mak -j3 AUTO_BOOTSTRAP=1
real    0m7.266s
user    0m11.712s
sys    0m1.855s

Building Go takes only 1 minute,

$ GOROOT_BOOTSTRAP=/usr/local/Cellar/go/1.7/libexec/ time ./make.bash
       67.74 real       136.49 user        15.95 sys

(No data for Swift, it insists on the beta Xcode 8 which I don’t bother to use now :slight_smile:)


I would love that. Nobody has yet stepped up to do so, though.

It really, really depends on how you learn. Some people do respond well to videos, but others cannot learn anything from them.

@kennytm - I couldn’t agree more, and it’s been a constant refrain since joining the team. Unfortunately, the solution is not so clear.

You can see what takes the compiler time pass by pass by looking at

(I just grabbed a recent build date)

Notice at the bottom across all parts of the compiler build and what pass takes the most time. Poking around, you’ll see the the compiler itself is actually pretty snappy, but a lot of time is spent in translation, linking, and - most certainly - the llvm passes.

As it stands today, the rustc compiler asks quite a bit from llvm, passing it all the specialized functions in order to get the absolute best performance in the output code. But it has a trade-off in terms of how long llvm will have to chew on what it’s given.

Am I making excuses? Absolutely not. I want us to be able to bootstrap at Go and D’s speed. The question is, though, how much can we shave that without cutting into the runtime speed of the output code?


So, my concrete use for it:

I’ve got a large C++ project that is basically WebAudio for desktop. It works by building a directed acyclic dependency graph of node base classes, each base class holding shared data like the dependencies of the node and some pre-allocated buffers. The base handles connection information like channel layouts, holding a mapping of integer keys to property instances, etc. Then, each derived node type comes in, provides a creator function, subclasses, and puts whatever data in it needs to have.

With specialization and fields in traits, this would be translatable to Rust, for the most part; without them, the things you have to do to make it work are decidedly not fun. Even with specialization and fields in traits (assuming fields in traits gets approved), you still can’t just say “here is my base object, I want to override this one method”. Instead, you have to jump through annoying hoops to set up a trait that contains the base field and implement it.

The logic in this project that allows it to integrate with Python’s GC then uses Any. I don’t think Any's differences from dynamic_cast are restricting in this case, though I’d need to read the extremely complicated GC integration thing I did to see if that’s true.

This is a pattern I see a lot with graphs. You want some sort of uniform interface with some sort of default implementation and some bookkeeping that’s done automatically, then you want to override the methods that actually do type-specific things.

I don’t believe in multiple inheritance, but single inheritance like this is an incredibly useful thing to have even in situations that aren’t OOP. Moreso if you can somehow bring in selected trait implementations of the base that you know are going to be correct because you don’t break their invariants.


I’m ops for all of Mozilla Research, and have recently been addressing infrastructure issues on Servo that we established were more urgent than Rust’s. Rust’s goals, especially as clarified by the community roadmap, are one of the things that guide where my time is allocated!


I like to add that the problem with Serde json/xml, to me at least, it is really a question off better reflection / introspection in the core language or in the macro system.

It would be so nice to be able to extract type info for struct’s and functions, in a static way, and of cause also to be able to call function using dynamically collected arguments (it will of cause be unsafe, and properly possible already, but I never came to that :-)). If that is possible we could map data at runtime using info the compiler gives us, and use Rust as our one and only IDL. It is i bit frustrating that this is possible in go and C++, ugly I admit but doable.

If we had real introspection, we could runtime check and map, remote RPC (json/xml/asn1) and keep nice static testing internally and use the really cool type system in Rust, without paying for it at runtime. This would make Rust the natural server language, together with proper parallelism as std.

I am not sure how it would be done in Rust (I have mostly been flirting with it, and I really like most of it), but I know that the compiler knows all kind of stuff, and C++ variadic could be a way to go, or something like that. The important part is that the compiler could “leave” some hints in the code we the could use to make dynamic argument collecting.

In the meantime, I have to stick to C++ (no go for me sorry, I hate its GC and related blackouts) :frowning:

From a game development perspective, if I wanted to write a game engine in Rust I think the main pain points right now would be:

Compile times - already covered here. Compiler plug-in stabilisation - e.g. serde issues already covered here.

Fine grained control over memory allocation and alignment. This is covered by Tomaka’s Vulkano troubles document Specifically I’d call out stabilisation of placement new syntax and fine grained control over alignment (of stucts, members, and heap allocations).

I think game dev needs are similar to embedded but not the same. Gaming platforms are pretty powerful these days and a lot of the time high level constucts are OK, but low level control is still necessary for performance. E.g. it’s common to use special purpose allocators. Dealing with graphics devices requires specific alignment and padding and so on.

This is actually much farther along than expected! There’s some patches that need to be sent in for the standard library, but it’s largely in a “someone needs to do the work” phase rather than the “super far away” phase.


One thing I didn’t see on the list that I am really hoping for is higher-kinded types, or in general more ways to express to the compiler what is desirable or allowed and what is not. I grant that this actually goes the opposite direction from making Rust more accessible, but in Scala a delicate helping of this is essential for helping me be both safe and productive in larger code bases. It’s possible this is different in Rust (I haven’t worked on a project large enough so that I desperately miss it), but I doubt it. My sense is that if you express this capability in terms of type lambdas with syntax very similar to regular value lambdas / functions, most of the “it’s a function!” concepts transfer over nicely.


‘discoverability’ as a high level goal would be interesting (elsewhere in the thread I think someone mentioned how they choose crates from - rather than ‘pick the biggest downloads number’, good discoverability would be useful here, as well as for finding crates in general areas of interest), but I’m not aware of a language community with a good solution (maybe aside from very targeted languages like Julia? I’ve never used it). It’s probably made more difficult by the variety of uses you can put rust to. For example, I never realised I needed manual lightweight userland context switches to stacks at custom locations in memory until I saw a post on reddit yesterday. I’d likely never find any use for such a thing in Python…but anything useful in Python probably has value in Rust - the set of discoverable things is bigger.

On the subject of the vision, something else I saw hinted at above (the “compile-time code generation” in @dikaiosune’s most recent summary) is the dependency on nightly in general. I’d love to be on nightly because I enjoy living on the edge, rather than because there are very nice features in nightly or because there are libraries I need that require nightly or because there’s a great library but it’s a compiler plugin rather than a macro so I need to be on nightly. There are always going to be cool things to try out on nightly, that’s one of the points of it, but I cringe at the thought of the papercuts that I’d feel at moving to stable. I can see that this line of thought is mentioned in the 2016 survey post and it arguably falls under “Rust’s core ecosystem should be maturing” in the OP of this thread. In which case, I’d suggest adding “reducing ecosystem reliance on nightly” to “Some potential avenues:” of that heading.

My main points:

  • Fixing bugs in rustc and core libs.
  • Stabilization of APIs. There are essential crates which need rust nightly. Even a performance test needs rust nightly.
  • Stable SIMD support
  • More performance improvements. C is still faster.
1 Like

Great question. Others have mentioned having sections in the documentation for people coming from other languages, which would be a great place to document how to extend those languages using Rust. Helix and Neon (for Ruby and JS) already seem to live on the org, but the website doesn’t seem to work. Collecting all the other bindings like rust-cpython, maintaining them, and giving them visibility from the documentation and website would be a good start.

Rust needs a good set of “batteries included” stable libraries and some easy way for people to find them. This might require serde and some form of specialization to work on stable.

Rust’s type system is really missing integer generics, through we don’t know the implications of it. Looks realistic for EOY 2017.

Our tools team needs to have more people than just @alexcrichton (with @petrochenkov and @jseyfried cleaning up our frontend, our compiler is starting to look fairly well - great work! We need something like that but for rustdoc and our metadata loader). Get the FFI story done with!


I don’t disagree, but any proposal here would have to make sure to address the failures of the platform proposal, and answer people’s objections to it.

I definitely agree here, Rust could absolutely be taught to beginners.

However, I’m not sure I agree wth this, at least at this stage. Beginners aren’t going to get Rust more widely adopted in production, which I feel should be the higher priority right now.