So. There's a lot here. Yesterday and today I sat down and re-read through all the comments on this thread. Let me say up front: @dikaiosune, your summary comments are invaluable, thank you so much for that!
One thing I noticed is that a lot of the ideas here already fall under some of the existing priorities (which is great). In many cases you can see that from the summary that @dikaiosune wrote, where he linked things to [root]. I think there are also a lot of cases (e.g., "Rust needs to continue improving ergonomics") that he didn't link to [root] but which (to my mind) are already covered (e.g., under "improve learning curve").
Digging deeper into some areas
In terms of moving the discussion forward, I wanted to try a thing. I branched off a thread to dig deeper into the needs for embedded development. I would like to see threads branched off for a few other areas that I think merit some deeper attention:
- Productivity: learning curve and expressiveness
- I think we all agree this is important, but I've been wanting to start some threads trying to expound on the right ways to do this, and in particular with a focus on "positive sum" outcomes where we don't pit new vs experienced users against one another
- HPC / numerical computing.
- Seamless FFI.
- Game development, perhaps? I didn't see a lot of citations here.
- Windows development needs (I hear mixed stories here?)
- Dashboard and visibility
- visibility into the state of things has been very much on our minds, and part of the point of the roadmap process was to help lay the framing for that
- @dikaiosune and @brson have been doing great work here with http://rusty-dash.com/
- First contact: @nrc mentioned ways to make it easier to experiment with Rust and cited React/Angular, I'd like to hear more about what he has in mind
I am going to try and fork off some of these threads, but I may not get to all of them today. Feel free to start up a thread yourself. I think the main thing is that it would be really helpful if we can focus on the most burning problems and also on categorizing the space. A lot of domains (cough HPC, embedded cough) are really enormous and varied. What is a blocking requirement in one case may be a non-issue in others, and it's helpful to clarify some of these distinctions for us noobs.
One thing I want to say: I feel like these threads are useful irrespective of whether we add some text about that particular topic to the roadmap. It's awesome to dig into these areas in depth.
Possible non-goals
Now, one thing I also want to bring up are non-goals. I did see a number of topics raised that I think don't rise to the level of "Rust project goals". There are a couple of different reasons for this:
- Often, the idea itself may be sound, but it is presented without motivation. I think we really want to focus on the problem we are trying to solve.
- Sometimes, the idea doesn't seem to require "community focus", but might better be pursued independently.
- Finally, some things just don't seem as pressing as others.
Here are some candidates that I found. I'll just quote from @dikaisune's summary:
Rust needs to have a more expressive type system. (type level values, CTFE, variadics, HKT)
This is a classic case where I think we need more motivation and less mechanism. I don't want (e.g.) HKT for HKT's sake. I want to know what we plan to do with HKT (which may well affect the precise design of it). Basically I think these kinds of language extensions don't belong on the roadmap, but the problems we aim to solve with them may. Anyway, my take on some popularly floated proposals:
- const generics and CTFE seem like a valuable avenue for unlocking many high-performance applications (e.g., HPC, small vec, embedded spaces); we should aim for something minimal. @eddyb has already been pursuing a lot of the important refactoring as well of course work by @scott and others on miri.
- HKT: the application heres are potentially widespread, e.g.,
Iterabletraits, being generic overRcvsArc, but HKT as found in Haskell may not be the best solution (and raises a lot of open questions). I like RFC 1598 by @withoutboats quite a lot. It's not HKT, but it's a relatively small, natural extension to the language that can express HKT, and would address things like theIterabletrait and so forth. Not sure how to prioritize this: digging more into the applications may help! - variadics: the primary motivation to pursue variadics for me has been making it possible to implement the
Fntraits. I think we can do this in other ways (e.g., adding syntax likeimpl Fn() for T) that would let us punt this a little further down the road. Given that I would want said syntax anyway, I'm sort of inclined to do that. =) (But maybe a good variadic solution is not so much work, not sure). In any case, I'm not sure just where this falls on the roadmap tbh, but I could imagine more power vis a vis Fn traits affecting a lot of areas a little bit (e.g., @carllerche raises this point to me regularly).
Rust needs to have data-driven feature prioritization.
The basic idea here is polling for what features people need etc. I am very much in favor of trying to get numerical data on what people are using and also trying to find out what people want. But I would not want to drive our decisions based on a purely numerical basis. For one thing, good polling is hard (citation: world events) -- as soon as you turn "polls" into (effectively) "votes", you raise incentives for people to do things like twitter-based vote drivers for their pet feature and so forth. I would rather that we try to evaluate things on the merits. But I do think that broad-based surveys are really useful for bringing things to awareness that were flying under the radar.
Rust needs a clearer specification of its semantics.
I think that as part of servicing other goals -- e.g., mature ecosystem and tooling -- we should focus on specifying the areas most urgently needed: unsafe code guidelines and grammar. Trying to formalize and specify all aspects of the type system seems like a big endeavor with very little payoff. It doesn't seem to rise to the level of a roadmap priority for me.
That said, I am very interested in making it easier to be more formal in RFCs. We've done some academic collaborations (e.g., this formalization of the trait system done at UBC and of course the ongoing Rust Belt project), but these efforts tend to lag and subset the language. What is needed to help with RFCs is something much more complete. I think improving and simplifying our trait implementation would be a great starting point. I've been toying with ideas here and would love to dig into them (ah so many half-written blog posts).
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
This seems important, but I don't know that it rises to the level of a roadmap point. Basically, if we find a good way to do it, I think we should just do it. But is hashing what's really preventing Rust from making in-roads? (I guess maybe?)