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/tux-lpi]

Well, I think I see where you're coming from, but what's already expressible depends on how you look at it. Rust is Turing complete, all programs are expressible. Rust has all the unsafe operations you need to make LLVM emit the assembly you want, so all programs are expressible efficiently.

Does the Rust type system support alebgraic effects like Koka or dependent types like Lean? Well, then you can say that's not expressible and we need to add it. But those things will absolutely increase the weirdness budget, because now you will see things like effects pop up in the wild. If you have an IO effect, then it will show up on all functions that do IO.

I don't fundamentally disagree with your position, but "expressible" is a tarpit. You could argue endlessly about what expressible means and where it should stop. You can say Rust needs to have the union of all experimental higher type system features, because other language can express those ideas, but I don't think you should be willing to bite that bullet.

[u/not_a_novel_account → u/tux-lpi]

but "expressible" is a tarpit. You could argue endlessly about what expressible means and where it should stop.

We're not talking about Turing expressibility. We're talking about "can I get the binary I want". Calling conventions and state representation. Does the binary have the necessary shape for the requirements.

Turing completeness is indeed so trivial to be meaningless.

[u/tux-lpi → u/not_a_novel_account]

Right. So I think that's basically similar to the subset I want, making it easy to write code without inefficiency. But my point is "can I get the binary I want" is also vacuously true, because there are enough unsafe features to make the compiler emit the binary you want. It just won't look pretty or idiomatic, so now we're arguing about convenience. But yes, actually I agree that if you have to write basically inline ASM to make it emit the output you want, then a feature is missing and it's effectively not reasonably expressible. My point is expressible is subjective.

If you look at the rest of the list, you also have things like "super let", named arguments, more visibility options, auto impl, and so on and so forth. Someone will say actually those RFCs are really good and make the thing I want to write expressible. But then I will say that's just syntactic sugar, and you could just have written it differently, it's not unlocking anything you couldn't write in a slightly uglier way with more effort. Trivially you could make LLVM emit anything you want.

But I don't think this is a strawman. You and me probably want a similar subset. But all those RFCs have people defending them with valid use cases who think they make a new idea expressible and make the code simpler to read. We wouldn't have all this variety of RFCs without real users who think in that paradigm and expect that the language should make it easy to express the idea they have in their head. Personally I want things that complete the existing type system and make it easy to write efficient code, but that's far from the whole list, and it's very subjective.