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.
- All packaged crates (e.g., on crates.io) should include this information so that rust upgrades never break type inference for dependencies.
- Rust could also store this information in the
targetdirectory 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] (https://blog.rust-lang.org/2015/08/14/Next-year.html).
As as rust beginner, I am most concerned about is the [Non-lexical lifetime] (https://github.com/rust-lang/rfcs/issues/811) 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.
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:
- 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.
Let’s run another survey with a list of frequently asked features with following options for each of them:
- Absence of this feature is really blocking my adoption of Rust
- I am constantly working around this feature, it would make my life so much easier
- It is nice-to-have feature but not very useful for my work
- I don’t care for this feature
At least the first two options can show priority features pretty well.
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=nativeto 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.
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.
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.
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?
-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.
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.
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.
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.
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.
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.
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.