Setting our vision for the 2017 cycle

[pepp]

Let’s run another survey with a list of frequently asked features with following options for each of them:

1. Absence of this feature is really blocking my adoption of Rust
2. I am constantly working around this feature, it would make my life so much easier
3. It is nice-to-have feature but not very useful for my work
4. I don’t care for this feature

At least the first two options can show priority features pretty well.

[gnzlbg]

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.

I guess that ought to be possible. The main reasons are that it is easier for us to:

• statically link against the networking and file I/O libraries, but dynamically linking should also work.
• just pass -march=native to the compiler in the supercomputer and let it figure out the flags rather than hardcoding them,
• sometimes you really need to debug in the supercomputer, so having edit-compile-run there is handy.

All of these look like problems that we could work out on our side (dynamically link, add the -march=native flags to our build system, and do something like edit-compile-ship-run instead).

I guess I’ll give it a try with a small toy crate and see how that goes.

[josephDunne]

I already use Rust in production for some tasks and love it. I can’t build full server systems yet and the reason for me has nothing to do with the libraries. Coming from erlang I am use to not having nice libraries for things. If Rust is serious about servers and reliability I would like to see Joe Armstrong’s thesis and the mantra “let it fail” be taken seriously as a language concern. Before I will use rust deeper in my organisation I need to be able to sleep easy at night knowing that if some part of my application panics its ok because it was isolated behind simple_on_to_one supervisor or similar mechanism.

[gnzlbg]

We are talking about developing 100kLOCs of infrastructure that needs type level integers. It can be done. But using typenum or shoggoth would feel like a hack and I am afraid compile times wouldn’t be that good.

[wuranbo]

I think a programming language’s sucesses can not leave the market. The old market that it will take a shot, and the new market which not have so many competitors. I advise checking out IOT(internet of thing), which may(just may be) need more and more new programmers. May Rust can give a better choice to programming on the embed system?

[Azerupi]

Rust’s compiler should be significantly faster Bottom line, the edit-compile-test cycle in Rust takes too long

Stabilizing -Z no-trans in some way, make it work with crates that contain both a lib and binaries and assign a simple cargo command like cargo check to it, will significantly improve edit-compile-test cycles. This seems a relatively low-cost/high-gain improvement.

[pcwalton]

Having a dashboard that shows what RFC’s have been accepted, which ones are actually being worked on, and target dates would go a long way for Rust.

An RFC dashboard would be fine, but the “target dates” part is edging close to asking for release dates, which (as we all know) is difficult for software and extra-difficult-to-impossible for open source software.

[aturon]

But why shouldn’t this roadmap include a high-level item for organizing those efforts? “Rust should significantly grow its commercial user base.”

To me, this is effectively the meta-goal for all the vision statements (see the discussion at the beginning of the original post). I don’t think it makes a great vision statement itself because it’s not directly actionable; the work of this discussion is all about finding more concrete, actionable issues we can address that will support Rust adoption.

In other words, I think this goal is so important that it should be the standard to which all of our more specific vision statements are judged.

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 agree, personally. We originally had this as one of the vision statements, but as you say connecting it back to e.g. adoption is a little tricky. IMO, there is some balance between direct investments toward adoption, and improvements to the community/project itself that grow our total bandwidth (like mentoring). Solid infrastructure may be an important prerequisite to other goals (like expanding platform support) to the point that we want to call it out as a dedicated goal.

[petrochenkov]

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.” ?

By the way, does @edunham still work on the project? IIRC, she was hired to maintain the infrastructure, but I haven’t seen any traces of her activity for months and all visible infrastructure work is still done by @alexcrichton and @brson.

This intersects with my next question, is any hiring planned to complete the listed tasks? It may be unrealistic, but I have a feeling that the project need at least few times more people working on it full time to achieve planned goals. People working on Rust as a hobby in their free time (like me ) are generally not very predictable / reliable and tend to do whatever is fun and whatever they like and not what is critical for the project.

[vitiral]

we need to stop saying “rust is not for beginners.” Rust is far easier to learn than C, has a helpful compiler, excellent documentation and an ultra-simple build system. Rust is for beginners. Anyone who wants to know how to program AND how computers actually work should pick rust as their first langugage.

Edit: on that note, our primary target for documentation should be only three groups: dynamic language programmers, systems language programmers and beginners. And we should focus on beginners. The rust book should be changed to have chapters that are ultra-beginner friendly – instructing about the very basics of computers and on up.

[pcwalton]

Rust is far easier to learn than C, has a helpful compiler, excellent documentation and an ultra-simple build system. Rust is for beginners.

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.

[steveklabnik]

Anyone who wants to know how to program AND how computers actually work should pick rust as their first langugage.

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.

he rust book should be changed to have chapters that are ultra-beginner friendly – instructing about the very basics of computers and on up.

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.

[vitiral]

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

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.

[vitiral]

we’ll never reach the state of “you don’t have to think about the lifetime of your data at all”

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

[cuviper]

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

[kennytm]

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"](https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md) 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 )

[steveklabnik]

Maybe it shouldn’t be you then?

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

the best resources are often videos

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

[jntrnr]

@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 http://perf.rust-lang.org/table.html?kind=rustc&date=Wed%20Aug%2031%202016%2019%3A56%3A15%20GMT%2B0000%20(UTC)

(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?

[camlorn]

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.

[edunham]

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!