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.
2 Likes
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.
4 Likes
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.
2 Likes
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
2 Likes
In C/C++, you should think about lifetimes; in Rust, you must.
5 Likes
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 
)
2 Likes
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 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?
4 Likes
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.
2 Likes
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!
15 Likes
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) 
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 https://github.com/tomaka/vulkano/blob/master/TROUBLES.md. 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.
2 Likes
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.
2 Likes
ādiscoverabilityā as a high level goal would be interesting (elsewhere in the thread I think someone mentioned how they choose crates from crates.io - 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 https://github.com/rustbridge 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!
3 Likes
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.
3 Likes