Rust's 'Vision Doc' Makes Recommendations to Help Keep Rust Growing (rust-lang.org)
- Reference: 0180432207
- News link: https://developers.slashdot.org/story/25/12/21/0341243/rusts-vision-doc-makes-recommendations-to-help-keep-rust-growing
- Source link: https://blog.rust-lang.org/2025/12/19/what-do-people-love-about-rust/
— Enumerate and describe Rust's design goals and integrate them into our processes, helping to ensure they are observed by future language designers and the broader ecosystem.
— Double down on extensibility, introducing the ability for crates to influence the develop experience and the compilation pipeline.
— Help users to navigate the crates.io ecosystem and enable smoother interop
> The real "empowering magic" of Rust arises from achieving a number of different attributes all at once — reliability, efficiency, low-level control, supportiveness, and so forth. It would be valuable to have a canonical list of those values that we could collectively refer to as a community and that we could use when evaluating RFCs or other proposed designs... We recommend creating an RFC that defines the goals we are shooting for as we work on Rust... One insight from our research is that we don't need to define which values are "most important". We've seen that for Rust to truly work, it must achieveallthe factors at once...
>
> We recommenddoubling down on extensibilityas a core strategy. Rust's extensibility — traits, macros, operator overloading — has been key to its versatility. But that extensibility is currently concentrated in certain areas: the type system and early-stage proc macros. We should expand it to coversupportive interfaces(better diagnostics and guidance from crates) andcompilation workflow(letting crates integrate at more stages of the build process)... Doubling down on extensibility will not only make current Rust easier to use, it will enable and support Rust's use in new domains. Safety Critical applications in particular require a host of custom lints and tooling to support the associated standards. Compiler extensibility allows Rust to support those niche needs in a more general way.
>
> We recommend finding ways to help users navigate the crates.io ecosystem... [F]inding which crates to use presents a real obstacle when people are getting started. The Rust org maintains a carefully neutral stance, which is good, but also means that people don't have anywhere to go for advice on a good "starter set" crates... Part of the solution is enabling better interop between libraries.
[1] https://blog.rust-lang.org/2025/12/19/what-do-people-love-about-rust/
How to Make Rust Grow (Score:2)
The easiest way to have growth is come up with a way to get the benefits of Rust without unnecessarily diverging from C/C++ so much. The answer isnâ(TM)t Rust, but probably yet another language or a âsafeâ(TM) subset of C/C++.
For âoeRust's design goalâ weâ(TM)re well aware of the one that says to take a less ideal aspect of C/C++ and do the opposite design decision, even if the âcureâ(TM) is worse than the âdiseaseâ(TM). This is what makes Rust a nonstarter
Re: (Score:2)
That's not even the problem, the biggest problem is it doesn't reach its own goals. You should be able to use Rust without using Unsafe , otherwise it doesn't solve the problem it claims to solve (or rather, it solves them in a "good enough" fashion, the same as smart pointers in C++ and there's no reason to switch from one to the other).
Re: (Score:2)
This is nothing particularly new. Mircosoft tried this already in the 2000s with [1]Managed C++ [wikipedia.org]. It didn't turn out well. People didn't care for safety features and memory management then either.
The Rust people are learning this lesson too. You don't break code that works. You don't rewrite adequate code just for the new shiny. If you want to stay in business, that is.
[1] https://en.wikipedia.org/wiki/Managed_Extensions_for_C%2B%2B
Re: (Score:2)
I also seem to remember there was [1]D [dlang.org], although I haven't heard of it in a while...
[1] https://dlang.org/
Re: (Score:2)
The problem is that without allowing some "unsafe" operations in Rust or any other language it is impossible to do any I/O or interface with foreign languages like C. It would be totally useless. Certainly no use as a "systems programming language".
So Rust allows "unsafe" in such way that it is clearly delimited and limited to tiny areas of the code that the programmer has to pay special attention to. This is a far better solution than having the entire code base be unsafe as in C and other languages. I fi
Growing like C++ does? (Score:2)
As I read this I see Rust turning out as just a big mess as C++ with all kinds of additions and changes over the years (and multiple similar ways to do something), especially when trying to do it all at once.
It's time to begin on Rust--, which only has the minimum set of types, operators, and functionality to build everything else with without causing ambiguity (looking at you, operator overloading). Like a hardened version of C.
Re: (Score:2)
A hardened version of C would be the way forward, not Rust--.
Re: (Score:2)
What would your hardened version of C look like?
I think that any harder version of C would detract from the C we all know and love.
Also I think a hardened version of C would end up looking like Rust.
In effect Rust is that hardened version of C. With a lot of other nice features on top.
Re: (Score:1)
it's doing that to attract c++ devs.
c++ devs looks down upon simpler languages where everything is straightforward and easy.
Re: (Score:2)
We've been burned by Java.
Complexity (Score:1)
Just having transitioned from high level scripting languages python/ruby/php style, the rust community should put some energy into making life easier for such people. Having &str and String, sometimes putting .to_string() there, sometimes not, is unnecessary cognitive overload.
Just one example of several.
Please make it a ->systems- language that fells like a scripting language. That would be a promise i hope for. Make the language easier, not more complex.Reduce cognitive overload where possible. Let
Re: (Score:2)
I don't know Rust, I just had to use AI to see what the difference was between &str and String. To be fair, it seems unnecessarily complex that they are both types, yet in totally different formats. Why &str? Why not at least String and &String to make it more consistent. Or DynamicString and LiteralString. The standard inconsistency would drive me nuts too. Seems not well thought out.
Re: (Score:2)
No need for lifetimes and stuff like that for "mortal" programmers...
You say there's no need, but why not? So far the known solutions are:
1. GC (large overheads, eliminates Rust from the spaces it's trying to occupy)
2. C-style #YOLO!!
3. C++ style: take the C model, automate away a lot of the complexity but with quite a few nasty holes around the edges remaining
4. That new C++ compiler that adds memory safety at the cost of overhead. Can't remember the name!
5. Rust: explicitly mark out everything that's impl
Re: (Score:2)
We need a new programming language! I suggest to name it WD40...
Re: (Score:2)
It is not. Rust is a fungal disease in plants.
Re: (Score:2)
> Why would you name your new - at the time - language after a corrosive reaction?
It's an edgy name! Would you rather name your new programming language something safe like "Condom"?