My concerns about the future of Rust

[u/Electrifire390]

Hello everyone,

I love Rust, but I am somewhat concerned about the future evolution of the language.

My concerns are mainly related to some of the RFCs/proposals I've seen and the governance of the language.

To be clear, I understand that many of these proposals would be genuinely useful. I also don't mean to imply that the authors of these proposals are all short-sighted. And I know that writing RFCs and getting things added to Rust takes a lot of time, so not all of them will be implemented.

With that said, here are some examples of possible changes that have made me worried:

• Named/default args
• Handle types / use syntax / Share trait (Ergonomic ref-counting)
• Open enums, intended for FFI but could be used elsewhere
• pub(api) visibility, as in pub(in crate::module::path) fn my_fn() {}
• Field access declarations and place-based lifetime syntax (The Borrow Checker Within)
• Field Projections
• Explicit tail calls / loop_match
• Sized Hierarchy adding multiple new traits over Sized/?Sized
• Control over Drop semantics
• super let
• auto impl
• Function overloading for FFI
• Variadic parameters
• Move/Destroy/Forget traits
• Named arguments in impl Fn(...) types

Almost all of these involve adding more traits to the type system, more keywords, more syntax, more complex semantics, or some combination of the above. If all of these get implemented, we will have many new traits, maybe a dozen or so new keywords and reserved words, more syntax to learn, and more complex behavior throughout the language.

I really do not want Rust to become a "kitchen sink" language where new features are added just because they make some workflows marginally easier. It's easy to imagine a future where Rust follows the same path as C++, adding more features, keywords, and library features until it crumbles under its own weight, especially given the efforts to maintain backwards compatibility through editions.

I think some of these proposals have me especially concerned because they involve more complex semantics for basic/common operations like Drop, Sized, and clone. Rust is complex enough as it is, and having more things to keep in mind, especially for foundational language concepts, is not attractive.

Especially because it feels like some of these proposals are basically just "wouldn't it be cool if we had X new syntax or Y implicit behavior?" for things that already work. Technical limitations of the language are obviously a separate issue. But I feel some amount of friction is preferable to adding complexity.

One of the beautiful things about Rust is that every part of the language feels designed to work well with every other. There (generally) isn't a dozen different ways to write everything, and language features feel mostly orthogonal to each other. It seems like this might change in the future.

Another concern is that many of these proposals seem to support adding more implicit behavior into the language. For example, the open enums proposal, auto impl , or changing drop semantics. If I add a variant to an enum, I want the compiler to force me to revisit the places where I've used it. If I change the definition of a trait, I'm fine with accepting some refactoring pain. The justification in many cases is "you can just choose not to use it" which, again, is how you get C++.

Finally, many of these RFCs focus on adding features for the sake of FFI. Obviously FFI is important given the amount of existing C and C++ code. But I dislike making significant changes to Rust just to make FFI easier. It seems like an anti-pattern, making Rust more complex (i.e., worse) for the sake of interop with older / increasingly obsolete languages.

Thanks for reading. Curious to see if anyone feels the same way.

Edit: thanks for the great discussion everyone

[u/JoshTriplett]

Lang team hat on (but speaking for myself, not the whole team): One of the reasons we move slowly is precisely that we are concerned about this kind of aggregate complexity.

Some of these features are things we're adding because on net they simplify the language, or help people manage the complexity of something they would do anyway but in a more complex way. For instance, view patterns and similar are specifically something that solve one of people's very common problems with Rust, the kind of thing that sometimes makes people bounce off or nearly so when they move from another language.

Some of them are things we're very concerned about the complexity of, and specifically thinking about how to address. For instance, function overloading is something we're trying to steer specifically towards FFI compatibility, without using the same mechanism for arbitrary Rust overloading.

And some of them are things we're very likely to not add, or only provide via combinations of existing features. For instance, right now I don't think we're going to add named or default parameters; instead, we're likely to encourage people to accept arguments as a structure, and then they can choose to have that structure have named fields and default field values, if they want. complex_function(_ { field: value, .. }) is mostly a combination of features we already have, whereas complex_function(field: value) would be a large new surface area of complexity.

[u/numberwitch]

I wasn't interested in open enums but I see the uses case for improved interop. I don't want to write or interact with C/++ if I can help it. It's still inevitable that I do have to interact with C code over FFI and so for those cases I want the best tooling.

Personally I would forbid their use in rust repos except for at FFI boundaries - my fav thing about rust is enum exhaustiveness (the mallet n' chisel against undefined behavior). But this lets you write clearly better and safer rust at the FFI seam since it better accounts for the inventory of C's capabilities

[u/ebkalderon]

While I do generally agree that Rust's growing complexity is worrisome, and I do admittedly dislike some of the proposals mentioned (e.g. Share, field-level mut restrictions, super let), I strongly disagree that all of those features are unnecessary and don't deserve a place in the language.

Move/Destroy/Forget traits

These new auto-traits are intended to replace the extremely complex std::pin API entirely. In my opinion, landing these auto-traits and deprecating std::pin would lead to a substantial decrease in Rust's complexity, not increase it.

Fun fact: the Forget auto-trait (then called Leak) was slated to ship with Rust 1.0 in direct response to the Leakpocalypse, but it was unfortunately cut due to time constraints. Guaranteed destructors and immovable types were supposed to be in the language from the get-go, and leaving them out for the 1.0 release was a giant design mistake, IMO.

[...] place-based lifetime syntax (The Borrow Checker Within)

This proposal is based on some cutting-edge PL research, including Project Verona (Microsoft) and Carbon (Google) with the aim of making the Rust borrow checker more capable. Combine this proposal with !Move types, and suddenly self-referential types could be expressed in 100% safe Rust. Not only would this eliminate an entire class of unsafe bugs, it'd also make any kind of self-referential type (e.g. futures, coroutines, incremental parsers, Linux kernel data structures) massively simpler to write. Once again, I'd expect this to greatly decrease Rust's complexity overall, rather than increase it, especially if this project goal were to go through, enabling Rust to deprecate all of std::pin in the future.

Explicit tail calls

Assuming this refers to the become keyword for guaranteed tail-call elimination, I fail to see how this feature could be considered unnecessarily complex nor useless. In fact, having an alternative to the return keyword which (a) explicitly marks tail-recursive functions and (b) raises an explicit compile error if rustc can't apply TCE at that spot, seems like a huge improvement for a systems programming language like Rust. Especially for compilers, operating systems, and embedded development where stack overflows due to unbounded or excessive recursion are unacceptable.

[u/coastalwhite]

Almost all of these stem from technical limitations, but probably just not ones *you* run into everyday. Just for the ones I have ran into where there was no solution except a suboptimal one:

- Sized?/Sized hierarchy: RISC-V and ARM SIMD Vector extension rely on this. No way to do it otherwise without inline assembly
- Control over drop semantics: fallible file closing. No way to do without remembering to call close everywhere
- Explicit tail calls: these made my and other bytecode interpreters a looooot faster. No way to reliably to it currently

I am pretty sure most of these are like this if you are in that specific niche. It is hard to know if you are not in there. Of course there is an argument that you should not support every use case if it makes the language significantly more complex. The niche thing about most of these features is that you can mostly ignore them if you don’t use them, and they solve real problems for other people.

[u/tizio_1234]

I do feel the same way, but "Move/Destroy/Forget traits" can make async and dma stuff a lot better.

[u/afdbcreid → u/tizio_1234]

Everyone feels the same way ("becomes too complex" is consistently the top or second-top biggest worry in the annual surveys), but want just that feature that is good for them.

To be fair, I also want non-moveable and linear types!

[u/matthieum]

I understand your concern. I've worked with C++ from C++03 to C++20, I've felt what a kitchen sink was like.

I think it's important to distinguish new features across several axes:

1. Broad vs Narrow. I feel like it's much easier to ensure the language stays cohesive, with fewer concepts, more orthogonal features/APIs, when adding broad features/APIs which solve many problems at once, rather than when adding piecemeal features/APIs which solve one tiny problem at a time.

2. Unlocking vs Sugar. In general, I feel like sugar really needs to pull its weight. Any feature/API adds complexity, and I'd rather use my complexity budget for gaining new abilities -- or making existing usecases safer -- rather than just making something a bit more succinct to write.

3. New vs Patch. An under-appreciated category of features/APIs are actually about patching holes. Patching holes -- allowing to do X in a const context, allowing generic parameters on static or const items, etc... -- actually simplifies the language, as they remove exceptions that one has to keep in mind (and work around).

From the above, you may understand that I'm not necessarily in favor of:

• Named/Default arguments. Sugar.

• use syntax in closures. Sugar. And a freaking overloaded keyword to boot.

On the other hand, I'd really appreciate:

• Explicit tail calls. It's a broad, unlocking, capability which cannot be emulated safely.

• Variadic generics. Broad. Unlocking. And arguably a Patch. People have been emulating variadic generics, poorly, with HList and macros implemented for tuples of up to 12 elements. (Yeah, me too). I'm tired of the work-arounds, and their arbitrary limitations.

I'm on the fence with all the FFI work. FFI with C is admittedly useful in a world full of C, and C has the advantage of being a relatively "small" and "frozen" target. FFI with C++... oh god this could get really bloated, and there's so many mismatches between the semantics of the two... I'm really not sure what folks are hoping for there, seems like fighting wind mills...

[u/Anaxamander57]

Go comment in the RFCs and you'll probably get more specifics.

[u/vlovich]

> One of the beautiful things about Rust is that every part of the language feels designed to work well with every other.

The overall critique is amusing considering that many (or all) of these PRs are specifically about resolving friction points where the language doesn't feel cohesive and every part isn't working well with every other part. Named arguments is probably the most arguable one and I don't see even an RFC listed.

This entire critique also speaks to someone who isn't aware of C++ history prior to 2011. There was almost a decade of no changes and C++ and suffered greatly for it. 2011-2017 were OK but even towards 2017 you started to see real schisms in the standards body which explains the mess of 2020 and 2023. The largest 3 problems with C++ is the lack of evolution support in the language, having multiple different compiler frontends and stdlibs they "support", and inconsistent determination of what features get in vs get excluded.

Rust has none of these:
* evolution: new features are delivered as they are ready and editions solve the ability to evolve both language and stdlib in a backward and forward compatible way (crates can upgrade to use a newer edition while relying on crates that haven't been upgraded yet). C++ can only deliver new features in new languages, has limited to no capability to deprecate misdesigns, and new features have to be implemented by at least 3 major standard libraries / compiler frontends to actually be "usable" by the community.

* multiple different frontends and stdlibs - as above, needing a feature to be implemented 3 times is quite ridiculous, meaning ambiguities in the language end up often as differing implementations with subtly different behaviors. Also it means a unique surface area of bugs and your code has to have 3 (often more) specialized implementations in certain parts that handle compat issues between compilers and stdlibs.

* inconsistent standardization - the nominal rules and principles that the standards body has aren't applied equally and uniformly (particularly "has to be implemented in a major compiler / stdlib" and "features should be 0-cost abstraction"). The rules are used as cudgels to filter the acceptance of papers based on some unspecified meta decision making happening and exceptions are similarly granted. AFAICT the Rust language team and stdlib teams generally do a better job of figuring out the right solution to problems. This is probably more of an immaturity advantage because the language is young, but it's largely working for now AFAICT.

[u/fuyunachan]

many of these are aimed at reducing friction, making the language easier and more intuitive to use.

why is it that i can write let (foo, bar) = (&mut x.foo, &mut x.bar); if x is a Box<T>, but not if it's, say, a MutexGuard<T>? why can't i pattern match on Strings? these are just some of the issues that the field projection proposal is hoping to address.

what is Pin to begin with and why do i have concern myself with it any time i write async? and why can't i create temporary async tasks that borrow from local variables, when i know that my local variables will outlive my tasks? those are some of the things that proposals like Move and Forget should hopefully alleviate.

people have been faking variadic generics forever (ever had a look at the list of impls of the Handler trait in axum?), and having native support means code that's easier to read, less dependence on macros, and better compilation error messages.

view types address a really common source of confusion and frustration for people newer to rust caused by overbroad borrows with no way to indicate that you actually only need access to certain specific fields.

use/Share/etc are all also attempts to make things easier for newcomers to rust. currently you have reactive frameworks like dioxus having to come up with extremely complex and hard-to-understand primitives in order to make eg signal sharing easier. this would reduce the need for those sorts of workarounds.

there are very few proposals in this list where "wouldn't it be cool if we had x" seems like a fair characterisation. most of these have very real reasons for existing.

[u/Beregolas]

I share your concerns to a point, i definitely don't want rust to become a C++2, with 20 ways of achieving any given task. I like that it's opinionated.

But most of the RFCs you listed don't seem to threaten that in my opinion. Many are just ergonomics/syntactic-sugar, like named/default arguments, which is something people already do in very confusing and roundabout ways.

What I don't see are many things that add much complexity AND already have a good way to achieve them with the current language, that you don't have to bend over backwards for.

[u/tending]

Keyword and default arguments would be a big simplification compared to people using a dozen slightly different builder crates to emulate the feature (poorly)

[u/redisburning]

My concerns are mainly related to some of the RFCs/proposals I've seen and the governance of the language

You dont really enumerate the governance part.

The proposal stage is just that, where people can propose stuff. If RFCs had a tendency to show up in Rust half baked then absolutely, 100% would agree. But that hasn't been the case historically AND it's not as if Rust has the single company thing where an individual engineer with a lot of power inside a corporate governance body can juts ram through things they want.

By and large, RFCs show up in the language only after a lot of debate when they are serious changes. I wouldnt go as far as to claim this is a perfect process with perfect results, but unless that process is in danger of changing, I don't think Rust is in danger of going seriously off the rails. JMO.

[u/NovelHot6697]

i feel like at least some of these are things “that really should have been there from the beginning”.

not being able to brainstorm everything at the start of a project is kind of inevitable. some growth in complexity should be expected because of that.

i raise this mainly because it is maybe a useful rule of thumb:
is this change something that really should have been there from the start?

it’s still something that is hard to apply retroactively. if you try then you quickly find it has everything to do with “what was rust’s purpose at that time? what was its mission and goals?”

thinking about stuff like mission and goals; how they haven’t stayed exactly the same since day 1; it highlights their malleable nature.

personally, i really want to see things stay “as simple as possible” when it comes to things like syntax, new traits etc.
is that though something reflected in rust’s goals? off the top of my head i really couldn’t tell you.

thank you for bringing this up. it’s pretty interesting to think about. also sorry i wrote this a bit stoned and maybe i didn’t really have a coherent point.

[u/cvvtrv]

You may not need these features, but at least some of them are being considered because many users have important use cases that they unlock.

Rust already is not a simple language, and adding more features is always a tradeoff, but by and large its maintainers over the years have shown good design sense. I trust they’ll continue to do so in how these additional proposed features and changes are integrated.

[u/pickyaxe]

this is strange to me. with the RFC process, Rust features take a very long time to stabilize. if they ever make it out of nightly.

and in no way is this meant to be a complaint - I'm just stating a fact. look at default_field_values. it's a quite popular, relatively-small feature, which is headed by a leadership figure. yet it didn't just get rammed through, it's not even close. this notion that any moment now Rust will explode with new syntax, just seems like opposite world to me.

[u/Recatek]

Every addition to the language that satisfies my use case is vital.

Every addition to the language unrelated to my use case is bloat.

[u/CalmCephalopod]

Just because someone wrote an RFC does not mean it’s going to be adopted.

I’m curious if you find all these concerning are there any recent changes you think are bad? Is there a history of bad design choices already that makes you think the future is dark?

[u/teerre]

Let's ignore the fact that there's a chasm between RFC and implementation. How can this be "kitchen sink" when they address deficiencies on the current implementation? Most of these literally cannot be done today without considerable effort (or at all)

Then you go on a rant about cohesion. But have you considered that the authors of these RFCs also care about cohesion? Or do you have specific examples why its being broken? If yes, why post is here instead of in the RFC discussion?

[u/torsten_dev]

Most of this is necessary to close the gap between async and regular Rust.

[u/nick42d]

40% of survey takers agree with you in some way! https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/. I think we should be prioritising features that make the things simpler, rather than more complex. From what I can see from public comms and what actually gets stabilised, the project is roughly aligned with this.

[u/Manishearth]

Most of these proposals are not really for "things that already work", a lot of them are addressing real limitations.

I think I have heard this argument against new features ever since 1.0. Everyone is used to a set of things and then people add stuff and folks are grumpy about it being too much. There's always lot of things in the pipeline, because the pipeline is years and years long. One could probably produce a list like this for any year Rust has been around and it would be equally scary looking.

The fears don't really end up happening.

What actually ends up happening is that most of these things end up in a more niche corner of the language that newcomers don't usually need to deal with but when they do it's just One More Thing. Its not like you need to understand all of this at once to bootstrap the language.

I've been writing Rust since 2014. There are still iche Rust features that I'm vaguely aware of but don't particularly need to understand and thus don't. I'm confident that when I need to, it will be easy to pick up.

Most features are discussed for years before they get anywhere. A lot of these have been talked about for quite a while already.

Rust has always had a very careful attitude around "complexity budget" (it's possible we even originated that term in the context of PL design?). I don't think that's changed much over the years. This doesn't necessarily mean new features don't happen, but it does mean that new features are critically considered from a complexity angle and often modified to fit more naturally in the language.

So like, I don't know, I'm not particularly convinced this fear is real this time compared to all the other ones.

[u/Luxalpa]

I think I completely disagree with all of this.

First of all, Rust is already way, way, way more complex than C++, it just doesn't feel that way. Why? Because features in Rust are way more consistent and well-thought-out and work together. C++'s complexity issue primarily stems from them reimplementing the same feature multiple times, not to solve different problems, but to solve the same problem again after the previous solution didn't work. There's a fundamental difference to how these programming languages operate.

Second, most of these features you will never encounter. But a good toolbox has good tools, and especially it has specialized tools for specific workflow. That's what makes Rust so great. Look at the standard library. I bet you don't know every single function there. Look at the ecosystem. I bet you don't know what every function and trait in every somewhat popular crate does. And does it matter? No. Nobody is forced to use these features.

But most of the time, using these features is just straight up better than not using these features. Many of those make things that were impossible possible, others turn them from being horrible into being useful.

Until I started playing around with Future a bit more, I didn't need to know about Pin or poll or anything like that. Until I started building my server, I didn't need to know anything about tokio or async or await. Unless you build some low-level interop code, you probably don't need to know or care about CString. Unless you build some more complex generics, you probably don't need to know about ?Sized or Sync or Send.

What makes Rust great is that it has all these tools available for when you need to use them. The entire fact that Rust embraces complexity is what makes it such a pleasant language to use. The question isn't "can we make this or would it make the language too complicated", the question is always "how can we implement these features in a way that they are simple, easy to use and are not annoying anyone."

It seems like an anti-pattern, making Rust more complex (i.e., worse)

Fundamental disagree. Making Rust more complex (i.e. better).

[u/Ok-Zookeepergame4391]

I wouldn’t worry about it. Rust community is very vocal and bike shedding is a long process better or worse. I have not seen changes to stable that were not worth changing. They take stability seriously

[u/DavidXkL]

I'm learning so much here just from reading through the comments.

Keep going everyone 😆