🪴 Anil's Garden

The Rust RFC process does not seem as amazing as I initially thought

02 Apr 202523 min read

I am a relatively new rust programmer, so this opinion might not hold a lot of weight but this is how I feel after I have gone through some RFCs.

Initially the Rust RFC process seems very welcoming. Anyone can open an RFC as long as the idea has merit and is well fleshed out. People develop and refine the idea over time, RFC gets accepted, implement in nighty, further refining, go through a stabilization period lo and behold you have added a new great feature to the language. The language in the rust contribution walkthrough makes it seem amazing.

Initially on my time learning Rust and looking for some features, when I found RFCs that address it, I would be happy because it means it is possible they might get added some time in the feature. But now, I just give up hope of that happening anytime soon.

This seems like a particularly egregious example Delegation. This seems so important because everywhere everyone seems to beat it over your head of how Rust prefers composition over inheritance and how amazing that is. But as a newcomer it seems like the language does not make it easy to do composition. Without proper delegation you have to manually write implementations for newtype methods and traits, when a delegation syntax would be extremely helpful to remove the boilerplate especially when you have so many methods. It seems like a tremendous effort has been put into this RFC and seems to be reasonably popular.

But after 3 years stuck in limbo it was closed because the lang team does not have the bandwidth. They apologize for letting it languish, and I appreciate that and acknowledge how busy they are. They suggest to bring it up again:

We would like to encourage folks to discuss it when the time comes for us to discuss our upcoming roadmap (one of the procedural changes we have in mind is to make it clearer when we’d be open to bigger proposals).

But how is one supposed to know when they are open to bigger proposals? By then it is very likely that the original author has already lost motivation and a lot of momentum is lost when someone else creates a brand new RFC and starts the whole process again.

There are a few more examples I can bring up, but, in general to me it seems like unless you are a lang team member or one of them is willing to champion your RFC, might as well give up hope on it and prepare to be disappointed.

Would be interested in hearing any alternative perspectives. Do you have examples of a successful significant RFC that was not proposed by a lang team member?

Comments

kono_throwaway_da • 46 points • 2022-09-19

It’s not the first time (and it happened more than a few times!) that I found myself wanting for feature X, saw someone proposing exactly that feature in an RFC, and the RFC got postponed due to various issues, such as limited bandwidth as mentioned by the OP.

So yeah, I do agree that it’s disheartening sometimes to see various RFCs postponed. It’s even worse when your favorite RFC is postponed and last updated more than a year ago…

coderstephen • 31 points • 2022-09-20

Often though, RFCs are postponed due to issues that are legitimate. We can’t just have RFCs accepted while they still have big issues, no matter how much people want it, as that is a fast track to having lots of deficiencies in future Rust. There’s no easy way out: Either people are willing to put in the work required to perfect an RFC to make it acceptable, or it does not get accepted.

That said, not every RFC has an “acceptable” state. Plenty of RFCs will never be acceptable due to some fundamental, inherent problem with the concept. That’s how you keep bad ideas out of the language. So we also cannot promise that an RFC will be accepted even if you do put a lot of work into it.

[deleted] • 87 points • 2022-09-19

Do you have examples of a successful significant RFC that was not proposed by a lang team member?

I mean here’s just a few I found.

unless you are a lang team member or one of them is willing to champion your RFC, might as well give up hope on it and prepare to be disappointed

The lang team is responsible for approving proposed RFCs. If you can’t get someone to champion your RFC to the rest of the lang team, it seems very unlikely to me they would ever approve it to begin with.

I think the thing that needs to be mentioned is https://lang-team.rust-lang.org/initiatives/process.html which describes how to figure out if they are open to bigger proposals.

I would also look at their Priorities list though which, IMO, delegation doesn’t really fit into. As someone who uses Rust professionally, I don’t really feel much pain from not having some kind of first-class support for delegation but I absolutely run into problems related to the topics on their priority list so I agree with their current priorities.

lookmeat • 67 points • 2022-09-19

Also we should look a bit more at the problem with delegation. The issue with one example, is that it’s easy to ignore why it failed, when compared to others.

The problem with that PR is that it actually has huge effects and interacts with a lot of features, but the PR doesn’t quite cover all of them. The dev teams weren’t against the idea, but considering the implications it adds some layers of complexity.

Here’s a few things that weren’t considered:

  • Could you delegate to some method? delegate * to self.foo(); doesn’t sound so crazy.
    • If you can, can you delegate within a generic impl?
  • Does this affect the ability for a trait to add new methods with default implementation in a backwards compatible way? (especially when delegating for all methods *).
    • Sure the default is backwards compatible, but what if the impl you delegate to overrides with a new method that isn’t backwards compatible, or breaks assumptions?
  • What about return types? Does it make sense to use the return type of the delegate? Should there be a way to override it? How do you handle it, especially on the case of backwards compatible changes above?

And it adds complexity to the language, is it worth it? Are there alternatives? The RFC is pretty good, but the problem is much larger than defined. Which makes sense why it’s not that huge. And we haven’t even touched how we’d handle lifetimes (what if the field you are delegating to is borrowed? What if there’s lifetime constraints on the output, should we expose the inner lifetime? And how would that work?).

And while inheritance seems like a solid way to think of this, this isn’t inheritance, nor composition, but a way to build something like it. It’s more akin to prototype inheritance, but with the extra layers of a strong typing system. Point is, it’s hard to know if this is the most “rusty” way to do things. Delegation doesn’t work as “is-a” instead it works as in “generally works as if” kind of deal. It’s a tricky feature that could bite you in the ass in many ways, and force constant discussions where the “obviously right way” goes completely against the philosophy of the language and you end up with this overly complex solutions. All because you chose the wrong semantic model, some looking at higher level implications that don’t quite fit what it is at lower level, and others focusing on the lower level model which is limited in what you can do usefully when looking at “the big picture”. IMHO this is what has been happening with async, but only time will tell.

It makes sense to postpone this until the problem can be handled correctly. It’s not that the implementation is problematic or anything like that, but postpone doesn’t mean it won’t be done. It just means that it isn’t aligned with the priorities and would take from that. Also that it might make sense to wait for some features that were (at the time) still more ambiguous (like GATs) to solidify to see how they fit with everything, rather than guessing and then finding out you implemented a feature expecting certain door, and now find yourself locked in to certain semantics.

[deleted] • 3 points • 2022-09-20

Best answer/explanation here imo, thanks.

Also, as somebody who doesn’t know Rust well, what is in your opinion problematic with the development of async?

lookmeat • 2 points • 2022-09-20

Honestly nothing is too bad, but it’s just my opinion. I think that async is a concept that works well on higher level, but doesn’t quite fit on lower systems-level programming. Async is about hiding details you need to be aware of when coding in a systems design language.

Take, for example, what the hell futures are. In a high-level language you don’t care, all those details are hidden. In Rust though you do need to be aware: where do you put the memory, how do you allocate, what are the side-effects of this on the system. The easy solution is to just have a Box<async Future> but the whole point of Rust is that you can choose to use Box but you may choose not to (because your system can’t work with it). So you could end up with this massive feature, with huge implication on the language, and enforcement by other libraries, that you can’t use in certain environments (like embedded) because you don’t have any way to control what is happening with the memory.

I don’t think that the feature would have made it this quickly had Mozilla not have a huge investment in getting this in. The implications and effects on the rest of the language and runtime are huge. Something like GATs has way less of an implication in the system (in that it’s an entirely static construct with no effect on the runtime) and look at how long it took for that to shrink down to a reasonable subset that was a good enough solution. And when you think about it GATs where the way that Rust decided to explore adding higher kinded types, but reaching that conclusion and deciding it was the right one, took years. Hell async forced certain decisions around GATs before they were stabilized!

That said I don’t have a better solution. It may be that all of these issues do have a fix, and it’s simply my view of async that’s too limited to high-level abstract thinking.

[deleted] • 1 points • 2022-09-20

Well, have you look at the way C++ did the Coroutine (framework)?

lookmeat • 1 points • 2022-09-21

Yeah but that’s also a bit too runtime heavy, IMHO.

Personally I’ve been thinking a lot about this. My conclusions is that there’s interesting ideas, but not enough battle testing to go for it. There may be no better solution at the moment, I can’t really say. But I suspect there is some that could be better.

I think that, if I felt like doing a language, one of the ideas I’d explore is how to set that. But that’s a very long post for another day.

[deleted] • 1 points • 2022-09-21

Well, the way C++ coroutines work depends entirely on how the types were implemented.

But well, anything which has to do with asynchronous programming (from IO to just waiting for a job) requires some form of runtime.

lookmeat • 1 points • 2022-09-21

Yeah I get that, the thing that I meant with high runtime cost that my dependencies control. If I take library A, and library B, each with their own coroutine runtime solution, I’ll have to host both. Rust at least lets you set the executor, so libraries can target async as guidance on how to do parallelize things and do concurrency, and the main function chooses which executor to use. In theory at least…

[deleted] • 1 points • 2022-09-21

Well, C++ coroutines are so general, that depending on coroutine you may not even need an executor.

Also, there is the whole executor proposal (which will probably miss the next standard again).

WormRabbit • 24 points • 2022-09-19

I think it’s notable that half of those accepted RFCs happened around Rust 1.0 (a few months before or after). The trait alias rfc was accepted, but the implementation has stalled for 6 years and looks more likely to be removed than stabilized. Field init it a very trivial sugar feature (no semantic effect, simple syntax, simple implementation), so it’s not very surprising it got through.

Fact of the matter is that accepting lang RFCs did become much harder over the years. Plenty of fun stuff was proposed and accepted at the beginning, but now getting anything accepted is almost impossible. That’s somewhat understandable, since the language has grown considerably, many more people depend on it, and many previously accepted features became stalled or removed (e.g. type ascription was recently de-RFCed and removed, never type and stabilization have ground to a halt).

Also note that the Priorities page you linked is heavily outdated. It was last updated 2 years ago, and even lists withoutboats for many topics, even though he has left the project around that time if not earlier.

The async project really took a toll on everyone. Many people have left, the lang team shrunk in half, and it became almost impossible to make any meaningful change to the language.

theZcuber • 7 points • 2022-09-20

never type … have ground to a halt

Well…it has been stabilized three times I believe, just reverted because critical bugs were found. Progress is still being made on this front — the never type is far from dead.

llogiq • 4 points • 2022-09-20

I’ll add some RFCs I did, and I never was a lang team member:

JoshTriplett • 18 points • 2022-09-20

With my lang team hat on: yeah, this is entirely fair. We had a period around that time where we were feeling overloaded, and we ended up deciding to punt quite a few things to the future. That included things we were actually quite enthusiastic about, such as delegation.

We did a poor job of communicating when we felt like it’d be possible to bring such things back up. Illusion of transparency applies here; we didn’t know, at the time, that this would be an issue, but with hindsight the statement in the thread obviously doesn’t give enough information.

Relatedly, while we’ve tried to make the process more approachable via initiatives, that has not had the intended effect, and we need to come up with a better solution there. In practice, initiatives have made the process less approachable, more intimidating, and more uncertain.

That said, you definitely don’t have to be a lang team member to get a lang RFC accepted. It is true that you need a lang team member to be excited about your RFC, somewhat by design. You also tend to need to have a degree of persistence and willingness to explore and catalogue the space; the degree to which that will be needed is not always obvious when you first set out to do an RFC.

If you look over the list of successful RFCs, you might get the impression that you have to be a member of some Rust team in order to get an RFC in, but that’s not true either. Rather, the degree of persistence and design and comprehensiveness required is such that many people who propose an RFC and successfully shepherd it to completion end up also becoming a member of a Rust team (whether as a result of the RFC or unrelatedly). It’s a great path for getting involved; RFC 1444 was how I ended up joining Rust.

A few examples of successful RFCs:

1vader • 33 points • 2022-09-19

Why is this an issue with the RFC process? I don’t see any other process that would have made this better?

It’s just an issue of the Rust team’s priorities not aligning with yours or I guess in part also there not being enough core Rust contributors. Proposing stuff is always easy. Figuring out all the details and implemenenting it is where most of the real work is.

vikigenius • -9 points • 2022-09-19

I didn’t say it was an issue with the RFC process. Obviously it was designed by people way smarter than me and for good reasons. I just was operating under a very hopeful/naive mindset that Rust was way more contributor friendly than it actually was.

It’s not just important for the idea to be useful, popular, well fleshed out and actionable, but it should also align with the lang team’s vision of what the immediate priorities are. In that case is it really much more friendlier than contributing a proposal to say C++? (I have contributed to this and it is incredibly hard and frustrating)

1vader • 34 points • 2022-09-19

Well, your post title is literally “the RFC process does not seem as amazing as I thought”.

I don’t really have much experience with the C++ process but as far as I understand, it definitely seems quite different. All the discussions happen out in the open and are easily accessible.

As others have already pointed out, this is a huge idea and feature which means even though the RFC is relatively detailed, it’s still not really completely fleshed out and immediately actionable.

And as others have pointed out as well, just because the idea isn’t disliked, doesn’t really mean it’s super popular as a priority. I think it’s a nice feature but I can certainly live without it. There are still many features that I’d much rather have and that are much more important for most people so I think the lang team is simply prioritizing correctly, focusing on the things that actually matter instead of the things that everybody finds cool but doesn’t really actually need right now.

And proposing an idea isn’t really the same thing as contributing. Rust is quite contributor friendly. But that doesn’t mean you can just come along, propose something, and expect others to implement it.

coderstephen • 8 points • 2022-09-20

Depends on what you consider “contributor friendly”. Is it unfriendly to not accept everyone’s RFCs? Language design is inherently hard, and no matter how friendly you are to contribution, that in and of itself doesn’t make it easier for a contributor to actually do language design well. In other words, we can try to remove every artificial barrier to contribution using something like an RFC process, but we cannot remove inherent barriers that make it difficult to do the design work.

WormRabbit • 4 points • 2022-09-19

Getting stuff into the language was very easy pre-1.0. Features were handed out like candy! Around 2019 people got burnt on many of those previous proposals, so the processes stalled. Also, the Rust team has shrunk considerably in that timeframe. I think Mozilla layoffs may have been a major cause for that.

coderstephen • 5 points • 2022-09-20

I’d say that the standards changed. Pre-1.0 we did not have to worry about backwards compatibility nearly as much, and the shape of Rust was still malleable. Post-1.0, the overall shape of the language has now hardened into what we now know as Rust. It is natural to now be much more cautious about what gets added and how it gets added.

turingparade • 32 points • 2022-09-19

Tbh it seems like the process is working exactly as it should.

Getting a feature accepted would/will never be an easy task, regardless of what language/framework you are suggesting it for.

Badel2 • 3 points • 2022-09-19

If you read the post, the complaint isn’t about the RFC process. OP is suggesting that given the limited resources of the core team they always prioritize RFCs created by internal members rather than external contributors.

turingparade • 5 points • 2022-09-19

I dunno if that’s right. It seems like a complaint that they have but not the overall point of the post. Though I may just have interpreted it improperly.

vasilakisfil • 3 points • 2022-09-19

While I see your points, to be honest I prefer the core lang team to work in a healthy schedule and let the proposals marinate/brew a bit before getting accepted. Designing a language, and especially a language with a strong type system is vastly more difficult than designing, say, a system architecture. And in general, it’s better if we take things slow, but towards the right direction than taking things fast and make mistakes on the way which will bloat the language and create unnecessary/confusing/hard to maintain features. So yeah RFCs are not the fastest process, but I think it works for now OK. The most important thing as I said is the core team does not feel overwhelmed because things can take a really bad turn for Rust design decisions then.

DramaProfessional404 • 2 points • 2022-09-20

I’m also relatively new to rust. I have no issues with the RFC process taking time. Rust is already a BIG language and every new feature has a cost in terms of language complexity. Personally, I prefer the focus be on making existing features work with fewer rough edges (eg async) rather than adding in more features.

Making Rust even more complex is easy. Making it more powerful AND simpler is hard but higher value.

insanitybit • 8 points • 2022-09-19

delegation feels like exactly the sort of thing to punt on - it’s syntax sugar for something that is frankly not a big deal, it saves you maybe one or two lines of code that you can’t get wrong anyway.

vikigenius • 9 points • 2022-09-19

Hmm maybe I am not very clear on why you just mean one or two lines?

Say I want to create a wrapper struct with the newtype pattern just to add some extra functionality for an external API. I would like to preserve all the existing functionality of the original struct. It’s basically an ideal is-a relationship. How would you deal with that when the original struct has lots of traits and methods?

FlamingSea3 • 21 points • 2022-09-19

If you’re just adding a bunch of associated functions I’d recommend an extension trait: Make a new trait with the methods you want to add, and implement it for the external type.

A popular example of this is the IterTools Crate, which extends iterators with a bunch of convenient functions.

Plasma_000 • 8 points • 2022-09-19

There’s already a bunch of macro crates for doing delegation, so the value add isn’t that great, especially since it can be an opinionated issue.

kohugaly • 6 points • 2022-09-19

How would you deal with that when the original struct has lots of traits and methods?

Macros, probably. For example this one, that was already made by someone else, published on crates.io and is actively maintained. If the feature is already possible in rust, but requires a lot of boilerplate, then macros are the answer 99% of the time.

Nearly all rust features start out as macros, and get merged into the language itself to improve ergonomics and standardization. Notable examples are async/await and try (?) operator.

WormRabbit • 2 points • 2022-09-19

You shouldn’t try to recreate the Pisa towers of inheritance via delegation. Split the functionality into separate components, implement new traits, or create special-purpose adpaters which add some functionality in a specific place for a specific purpose (so you don’t need them to delegate lots of methods, you just need to implement a couple that matter).

SweetBeanBread • 1 points • 2022-09-19

do traits Deref and DerefMut not fit?

kono_throwaway_da • 9 points • 2022-09-19

Some people may think of it as some sort of hack. Conceptually, for a “value type” (as opposed to “reference types” like str and &T, or “pointer types” like Rc<T> or Box<T>) a deref doesn’t really make sense.

Also, the std docs explicitly mentioned “Deref should only be implemented for smart pointers to avoid confusion” so there’s that.

SweetBeanBread • 1 points • 2022-09-19

i guess ya… so the correct way is to add a normal function to return a reference to the inner struct? and if the wrapper doesn’t need to store any extra data, i guess it’s possible to just impl one’s own trait on the existing struct.

ssokolow • 1 points • 2022-09-19

The main issue they’re talking about when they say “to avoid confusion” is how Deref interacts with the same method being implemented on both types.

insanitybit • 1 points • 2022-09-20

Well, per method. Delegation is just the impl block + the fn signature + the one line to dispatch. The impl block is still needed but you can save the signature and the line to dispatch.

I just don’t really see it being that big of a time safer tbh. I feel like blanket impls would be better if we had specialization or something.

kono_throwaway_da • 6 points • 2022-09-19

Delegation is one of the RFCs that I do think has real use-cases and one that will be used at least once by all Rust programmers. I am thinking about newtypes mainly.

For example, I would massively prefer to not have to copy and paste multiple functions/traits from f32 to the impl of Scalar(f32). It’s boilerplate-y, and more importantly it’s error prone because… well, copy-paste errors are a thing. Nothing is stopping Sub implementation of Scalar(f32) from erroneously returning self.0 + rhs.0. It’s either copy and pasting or writing macros, which leads to other problems such as maintainability and general readability (macro syntax is imho ugly).

ssokolow • 6 points • 2022-09-19

And, last I checked, the verdict was “We’re waiting to see people on crates.io iterate on the design”.

Imagine if lazy_static were what got accepted into std, as opposed to the once-cell adaptation that’s being worked on. Imagine if they hadn’t retired rustc_serialize before v1.0 in response to Serde arising.

714daniel • 0 points • 2022-09-19

Is there a reason you can’t deref/derefmut?

crusoe • 1 points • 2022-09-20

Well for the longest time deref has verbage saying it was only for smart pointers but everyone abuses it for delegation.

uraneko1F431 • 1 points • 2024-09-14

the RFC process sucks because it was designed to suck. It was designed to suck because it has to suck. It has to suck because it is a safety net put in place so that the language sucks as little as possible.

That is not to say that the delegation RFC was bad or the feature is bad, but we can all agree that designing a language is a very complex endeavor. If the lang team said it wasn’t aligned with their current objectives at the time, then that is a good enough reason, although I won’t pretend to know how frustrating it is.

edit: still, they should not have let it sleep for 3 whole years, but I’m sure they were acting in good faith.

Graph View

Backlinks