Forgot your password?
Close
typodupeerror
Programming

Rust's 'Vision Doc' Makes Recommendations to Help Keep Rust Growing (rust-lang.org) 80

Posted by EditorDavid from the Rust-never-sleeps dept.
The team authoring the Rust 2025 Vision Doc interviewed Rust developers to find out what they liked about the language — and have now issued three recommendations "to help Rust continue to scale across domains and usage levels."

— 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.
This discussion has been archived. No new comments can be posted.

Rust's 'Vision Doc' Makes Recommendations to Help Keep Rust Growing More

Rust's 'Vision Doc' Makes Recommendations to Help Keep Rust Growing

Comments Filter:

  • 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

    • 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).
      • This is nothing particularly new. Mircosoft tried this already in the 2000s with 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.

        • I also seem to remember there was D [dlang.org], although I haven't heard of it in a while...

        • > 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.

          OK Rust critics, you can't have it both ways, either Rust people are rewriting everything in Rust or "you can't rewrite adequate code just for the new shiny". Pick one.

          Truth is Rust is being adopted for new projects where memory safety is necessary, and for the most part that's good enough, especially as major systems do tend to

        • Re: (Score:2)

          by _merlin ( 160982 )

          Managed C++ was mostly used as an interoperability layer between C++ libraries and CLR languages like C#. It wasn't an attempt to make a "safe C++" language.

        • You don't break code that works.

          Breaking code that works is job security. "don't break code that works" is something that most of the programming world has given up on, unfortunately (along with KISS).

      • Re: (Score:3)

        by kertaamo ( 16100 )

        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

        • 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.

          If the only programs with permission to escape the language's type system are system libraries signed by the operating system publisher, it isn't "totally useless." It'd be like Java applets, J2ME phone applications, Silverlight applets, XNA games, and Windows Phone 7 applications. Executables for these platforms are in an intermediate representation that lets the loader tell if unsafe was used. If the executable contains unsafe code but isn't signed with the permission to escape the sandbox, the loader rai

          • I'm in agreement this is generally where Rust needs to head. "unsafe" needs to be something 99% of projects will never ever use. It should be so rare that even third party crates that use unsafe code, or are dependent on unsafe crates, have to be explicitly loaded using a "extern unsafe crate" command.

            To get there what Rust actually needs is a proper, Java-level, basic system library. Not just for system calls and multithreading and singletons and whatever, but also implementations of secure algorithms and

        • The problem is that without allowing some "unsafe" operations in Rust or any other language it is impossible to do any I/O

          I don't think that's true, unless you insist on immutability. In particular, it IS possible to do safe IO, most languages can handle it. For Rust, it's just a matter of defining the proper rules that make IO safe, and then enforcing them.

      • 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).

        Do you have examples where Rust is implemented with unsafe? I would think Google implementing Rust code in Android [slashdot.org] for memory safety would not just allow unsafe everywhere.

      • No, the biggest problem is that computers are fundamentally calculators with the addition of pointers and goto, and computer scientists have spent the last five decades trying to hide those two features from users because if you expose them you have a general purpose machine that can be made to do anything.

  • Growing like C++ does? (Score:3)

    by JamesTRexx ( 675890 ) on Sunday December 21, 2025 @04:44AM (#65872537) Journal

    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)

      by Uecker ( 1842596 )

      A hardened version of C would be the way forward, not Rust--.

      • Re: (Score:2)

        by kertaamo ( 16100 )

        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.

        • Hardened C would force you to use smart pointers except in a section with a compiler directive #UNSAFE when you must use raw pointers. Then you basically have the same effect as rust.

          • You're confusing C++ with C. C doesn't have "smart pointers" and any attempt to graft something onto C that makes pointers trackable makes it exceptionally inefficient.

            There is a C compiler out there, Fil C [fil-c.org], that makes use of the UB that exists because of the desire to support capability architectures (it doesn't use capabilities, but early versions emulated them in software, the language evolving over time) that tracks pointers and includes block/length information with each pointer. It works, can superfic

            • I know C doesn't have smart pointers. Because C programmers usually know how to manage memory. Doesn't mean one couldn't be made for c, and many devs do makes their own.

        • What would your hardened version of C look like?

          It'd look like a subset of C where the compiler emits a diagnostic for every undefined behavior that's practical to detect at compile time and inserts code to catch at runtime everything else the standard calls undefined. The first step toward this is what GCC already does for -Wall -Wextra -pedantic -fsanitize=address,undefined. The second step is that a pointer variable doesn't contain a raw address but instead a base address and index, and every dereference of an array member is bounds-checked against th

          • https://fil-c.org/ [fil-c.org] does this (no, really! They made use of UB's "We might end up wanting a C compiler to run on a System/38" justification, but the issue you're going to have is its all immensely inefficient with both memory and speed. And ten to one I'll bet the people arguing they "just want a safe C" are arguing that because they think C is the most efficient programming language ever and don't want to program in something "less efficient".

            Truth is hardening C is hard, it's like trying to harden assembly

            • Re: (Score:2)

              by Uecker ( 1842596 )

              I do not think a hardened version of C is that hard. Fil-C is slow because it runs unmodified C. To develop a hardened version of C you need to subset C and emit errors for possible UB. It would need some extensions for ownership and/or lifetimes, but there is no need to throw out the baby with the bathwater and come up with a super-complicated and different language such as Rust.

              • The question I have for you is what makes you think, once you've added features to C to deal with the issues related to what you removed, you'd end up with a less complicated language than Rust or Java?

                To be quite honest, ownership and lifetimes are what makes Rust feel complicated to a new user. The rest of it is pretty straightforward. It adds some OOPS stuff which is straightforward and ignorable if you don't like OOPS for some reason.

                The complex stuff though? Those are what lifetimes and/or the borrow c

                • Re: (Score:2)

                  by Uecker ( 1842596 )

                  Java, C#, Rust, and Go were not created by people who want to make C safe, but people who have different ideas on how a language should work. Go is, unsurprisingly, close in philosophy but the others are very far.

                  Function pointers do not need to be replaced in a safe version of C.

                  You are right that you need something as lifetimes or a borrow checker. You certainly do not need an entirely different syntax, proc macros, monomorphization, many different string types, etc.

        • Re: (Score:2)

          by Uecker ( 1842596 )

          It would be a subset of C where the compiler emits warnings or run-time checks for possible UB.

          Rust is not a hardened version of C. Rust is far more complex than C, not stable, has different syntax, different principles, and very long compilations times.

      • Fil-C [fil-c.org] exists if you want to harden your existing C code (as long as it's not dependent on UB), but it's relatively slow.

        There's also a new language called Trap C, covered by Slashdot in the past, that is supposedly a hardened version of C.

        So, you really have two choices: you can inefficiently use the language you know (Fil C), or you can learn a new language (Trap C) that looks a bit more like C than Rust does. I know ahead of time you're going to reject the first one - Fil C is great for legacy code, but t

      • Sure but did you ever figure out why no one has yet done that? There are ways to harden C and C++ like with compiler options [openssf.org], but no one has come out with a version that has safety built in. Bjarne Stroustrup has started efforts to harden C++ but that come only after Rust started making progress. The main reason I can see is the some C/C++ developers do not want to be told what to do or how to write safer code. They know better than anyone else. They will not embrace a safer C/C++ just like they will not

        • Re: (Score:2)

          by Uecker ( 1842596 )

          It is mostly hard because there are no resources for it. Even for maintaining C front-ends compilers there are barely resources, there is so much which you could do easily, but most of the energy goes into C++ or other things.

          • And why are there "no resources" for it. Yet a programmer at Mozilla saw the need for a memory safe language like Rust and developed it over a few years. Then Mozilla took over.

            • Re: (Score:2)

              by Uecker ( 1842596 )

              It is the usual problem of open-source and free software. What is old is not maintained properly. Rust gives companies an excuse to move on until it too is boring and old and will suffer from neglect.

              • I don't know if that is true. Parts of Linux are very old and are still maintained. Also Rust is not "new". It was first created in 2012. Yes it is newer than C, but it is not new.

    • it's doing that to attract c++ devs.

      c++ devs looks down upon simpler languages where everything is straightforward and easy.

    • 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.

      If Rust is to have a good future it's time for them to learn from the Python people. Python has a bunch of wierd stuff; functional programming; comprehension, introspection and so on going on. However the main good thing that they do is being slightly embarrassed about the complexity.

      Look at the language disasters - C++, Perl and perhaps even Scala, for example. What lots of them have in common is that they boast about their "sophistication" - it's summarized in the Perl motto "there's more than one way to

      • Using a comprehension and introspection you can convert a dict (HashMap) into an object and back again, each with one line. When they are useful they are very useful.

  • 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

    • 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)

        by Uecker ( 1842596 )

        But what you can is put an ownership / lifetime model similar to Rust into C or C++. This does not avoid all the hassle of Rust but would avoid some of the problems of Rust and allow a much smoother transition.

        • Sean Baxter did that with Circle lang. It's C++ plus a load of extras including lifetimes and borrowing. What it doesn't do is what the GP wants which is save mortals from the complexity of lifetime management.

        • It wouldn't avoid any of the hassle of Rust, it'd basically be Rust but with fewer features and a slightly more C like syntax.

          100% of the problems C people have adapting to Rust are to do with getting their head around the borrow checker/lifetime model. Everything else is very straightforward.

          (I'm not saying Rust is without flaws, it has plenty, but they're nothing that's not in C too.)

          • Re: (Score:2)

            by Uecker ( 1842596 )

            Rust has many flaws C does not have, including a type system build on monomorphization, annoying syntax, less explicitness, worse support for independent compilations.

  • I'd like it if there was an alternate set of documentation that doesn't use the word "variable" for something that can't vary after you set it. Create a new term, allow me to use "var" for what's currently called "mutable", just something. Every time I read that, my programming knowledge and English background have a short battle -- it's tiring.

    • Re: (Score:2)

      by vyvepe ( 809573 )
      It is called variable because you can initialize it to a different value any time the process execution enters the initialization code. Mutable (mut) is added so that is a bit more typing to use them. That is a small incentive to prefer immutable variables (as it should be since it is a good programing practice to to prefer immutable variables).
  • Rust touts its amazing memory safe etc, but then it appears that to do much of anything (especially replicate existing non-rust code functionality) then rust reaches for allowing "unsafe" code. So, what was the point?

    • Rust touts its amazing memory safe etc, but then it appears that to do much of anything (especially replicate existing non-rust code functionality) then rust reaches for allowing "unsafe" code. So, what was the point?

      Is that the design of Rust or is it developers porting existing code in the laziest way by just encapsulating "unsafe" code with a keyword and calling it done? I think is the latter.

    • It doesn't. Most code doesn't use nor need unsafe. Most uses of unsafe are well encapsulated.

  • ... such a great language for reducing security vulnerabilities, why does firefox need to update every week or two to fix critical or high CVEs [mozilla.org]? Has there been any measurable decrease in such vulnerabilities since firefox adopted Rust?
     

  • Is Rust a Cult? Is Rust growth organic? Have other programming languages come along with a manifest destiny?

  • When building a Rust application, you are typically pulling in multiple and often redundant crates to implement things like error management. While extension via crates is fine, I can see this going the way of NodeJS and Python where you end up making yourself highly vulnerable to supply chain attacks.

    Setting aside the question of "how do we pay for it?", for the moment, I think there is a need to have some level of verification available once a crate reaches a certain level of ubiquity. Once you have a c

Slashdot Top Deals

Innovation is hard to schedule. -- Dan Fylstra

Close