I’m glad to see FFI included in these goals, and in particular the mention of seamless
#include support. In particular, that gives me hope for detecting library version issues at compile time rather than via runtime crashes. Right now, libfoo-sys crates declare the various C symbols they use, with no way of knowing if those declarations match those of the version of the library the crate compiles against.
I’m glad to see FFI included in these goals, and in particular the mention of seamless
Like @Eh2406 said - the rust-cpython bindings are actually really solid. I’m working on a blog post ATM about how to write extension modules for Python in Rust. Still, I agree that the story there can be improved, especially if the work on custom garbage collectors makes progress and the interop with Python’s refcounting can be worked out. I’ll need to take a look at how that can work with Cython too.
This reminds me: one of our perpetual problems is just making good stuff that exists more visible. We’ve added a lot of links within the web site, but it ends up being totally overwhelming.
How can we make it easier for people to discover things like Rust’s Python story?
One thing that I discussed with @aturon a while ago would be building the fundamentals for a scientific Rust stack. It’s not a lot of effort to get the initial core fundamentals out, but once it’s there it would be a central place that other disparate projects could build upon. Think NumPy ndarrays for Python, the Julia NDArray, a subset of Eigen, etc.
The core primitives could be:
- a core ndarray abstraction
- BLAS wrappers on top of these
- scientific functions on these arrays (e.g. the vector operations in MKL/Accelerate/NumPy)
Some inspirations from the C++ side (that are probably overly generic but are reasonable) are Eigen and mshadow.
With these, the scientific Rust ecosystem would have a central place to build upon.
This is the most important thing for me. There are things which I am currently incapable of binding properly in winapi due to a lack of FFI features. Things like unions,
#[repr(packed(N))], bitfields, COM calling conventions, dlimport, static-nobundle, unsized types with thin pointers, and more. In fact, I don’t think Rust has had a single FFI feature implemented since 1.0 (the most useful thing for me that did happen since 1.0 was making glob imports actually work). Several of those features I listed even have accepted RFCs, so I have hope, but seeing them take so long to be implemented, nevermind stabilized, is really demoralizing.
This is also hugely important, not just for me but for everyone. I’m going to some fairly extreme lengths in winapi just to minimize the amount of code that has to be compiled so compile times can be fast: getting rid of almost all trait impls, making enums simple integer constants, and abusing cargo features. I only have about 10% of the code currently compiling in winapi 0.3 but it already takes 4 seconds to build. So, when I do eventually get everything updated, should I look forward to 40 second compile times?
I think it would nice to have a few thorough guides that cover features that many older mainstream languages have but rust doesn’t.
Just a few things that come to mind:
- Working with generics.
- How todo OOP in rust.
- Working with Iterators.
- How to do error handling without exceptions.
One thing we’ve talked about quite a bit but never quite gets off the ground is a single “derive” for common data-types.
#[derive(Data)] // equivalent to #[derive(Copy | Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug) // what about Default and Zero? Should Data include them if possible?
This is a beautiful example of the kind of curve-bending that the Rust community has gotten so good at. Instead of just assuming that some ostensible tradeoff is a hard tradeoff, identify ways to get many of the benefits of both solutions at the same time.
That shrinks down the set of cases that aren’t reasonably handled by the default (in this case, codebases with both fast-hash requirements and significant code size limitations), which makes the justification for escape valves much easier for users to understand.
One thing that could be improved with
#[no_std] is getting some of the core crates (like alloc) stabilized.
I’m a little confused about that one in particular – are we likely to be changing
alloc::heap::allocate in the future? It seems pretty basic to me.
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.
It feels like we have a body of data now – it’d be good to know what sets of traits are commonly implemented together. I feel like one of the problems with a shorthand like that is that I fear everybody has a slightly different subset in mind.
Doesn’t shoggoth.rs at least somewhat cover this for now? (I admit, native support would be nicer).
For 2017 I would like to see two things.
Serde json should work out of the box on stable release channels with no customizations to my build for code gen. This has been a sour spot in the past year as the community transitioned off of rust serialize to serde where rust serialize worked out of the box and serde required build assembly. Effortless Json support is kind of a bid deal when it comes to network services. We should make rust more seemless to get up and running with a good json lib on the stable channel.
more ferris. Or to somehow make ferris more official. It’s weird there’s an unofficial mascot and an official logo. I’ve personally seen this cause confusion. Rust should have a consistent branding. It deserves it! 2017 could be the year of ferris. Let’s make it happen.
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.