I'm really hoping that most of the larger async-related usability issues are fixed ASAP, but I don't know if doing it this year is feasible. These cause lots of friction, and turn some people off to the language.
If you do this because you have similar code for One and Two, I suggest defining a closure above the match and calling it inside of it. It's not as pretty but it solves code duplication.
Does deleting a file need a "danger" block, for example?
That's for a user to decide! If in their context deleting a file needs to be handled extremely carefully, then yes, they would use a danger block with their own file wrappers.
Then we don't need one ādangerā level, but more of unsafe(io), unsafe(GPIO) and so on.
And global directive that permits crate to do unsafe(something) without explicit unsafe block.
Actually pretty interesting idea, because people discuss whether it's good idea to use unsafe for anything but language UB pretty regularly.
At that point it might be worthwhile for Rust to properly explore capabilities, such that without specifying e.g. the io capability, the compiler will error out if the code tries to access I/O functionality anyway.
Implementing capabilities that way will thus provide static guarantees that only the explicitly specified capabilities can be used by the code.
2 Likes
There are also number of very vocal opponents to inheritance, who are often misquoting Design Patterns , by the Gang of Four (IIRC, you can find an example of that in the "Rust Book"). It has its usefulness, but Rust provides enough tools so that it's not too painful.
You can mimic method overwriting in Rust as when using inheritance the same way as in this example for Go: Inner Pattern to mimic Method Overwriting in Go
Stabilize once_cell_try
You can do that in Rust with traits, but it's not inheritance; it's the simple dynamic dispatching of an interface. If you want your UI elements to really inherit from the base class, you have to wire all the trait methods manually. There's no fields, either, since it's only an interface.
On my wish list is an implementation for fibers. D has done that quite nicely: fibers - D Programming Language. On top of fibers you can then implement CSP (communicating sequential processes) as in Go (aka channels and Goroutines). This has also be done in D: GitHub - DmitryOlshansky/photon: Photon - a transparent Fiber scheduler and event-loop for DLang. Just to show what I mean.
There are some spare time efforts to implement that in Rust, but what I've seen so far does not go all the way.
CSP imho makes concurrent programming a lot easier. I did earlier lots of asynchronous and other concurrent programming. Spent lots of time with reproducing race conditions and deadlocks (circular message sends) and finding ways to fix them. Green threads and channels makes this a lot better from the beginning.
CSP in Rust is essentially the only big wish I have for Rust.
They also turn the whole language into something entirely different from what Rust currently isā¦ so we have another āpseudo-wishā for something that have zero chances of materializingā¦ I wonder why people bother to invent theseā¦
You need a detailed plan and a lot of design and patience. Then in 2036 or, perhaps, 2046 you may get your wish. In 2026? Fuggetaboutit.
1 Like
I was a little dissapointed in the latest blog post because I feel it missed a big part of safety-critical projects: uptime.
I need to validate that the critical paths can't panic. For example, my server cant crash because a bad request caused a handler to panic.
Safety is safe by default, has unsafe blocks, // SAFETY comments, lints, etc. Panic-less not so much.
One could be more mindful of things like unwrap, expect, panic macros, array lookups, etc. However, needing to be more mindful is how you accidentally crash 80% of the internet.
Also, there are some instances where its not obvious if a panic could happen. Maybe your array lookup had its bounds check dropped because the compiler verified it was never needed.
Im aware of crates like no_panic but have had some trouble using them because sometimes the standard library contains the panic code and I can't change that.
...so my wish for rust in 2026 is that there is a better way to validate that a code path is panic free.
I understand that the standard library or other crates might panic (most safety critical code doesnt use these), and that at the OS and hardware levels that some operations are never guaranteed. However, Im more worried about validating my crates local code. Kind of like how the unsafe_code = "forbid" lint works.
I dont know if the solution: mimics safety, is a compiler thing, is a linter thing, is a macro, or what.
5 Likes
And another with that wouldn't happen. Sigh.
Proper handling of handling (or proper handling of side-effects, to be more precise) is something people are working on. If we would have a reliable, working, and ergonomic solution by 2050 ā I would be happy. 2026? Nope, don't even worth talking about. We have just barely convinced people that it's worthwhile to have memory safety in a systems languageā¦ and that fight took half a cenruty. And you want next fight to finish in a year? Not gonna happen.
That's the thing: no one knows. There are lots of research. Research tales decades. Andā¦ that's it.
Yes, I know it's not a satisfactory answer. Yet that's the realistic one: panic (that enabled todo) was a price that Rust had to pay to be adopted at all.
Removing it would be task to either Rust successor, or, perhaps very late version of Rust that would arrive there after passing dozen of editions.
That wouldn't happen in 2026.
Is there a particular reason you've decided to go around shooting down everyone's ideas (at length) because you don't deem them reasonable to expect in a short timeline? A wishlist is often unreasonable; I don't expect most of us to get even two of our wishes granted this year. But you don't see me making lengthy, derogatory comments about what everybody else wants. This thread isn't about what we reasonably expect this year, it's what we would get if we had our way. To quote the very first words of the OP:
22 Likes
My greatest wish is selfish, and so I state it just because you asked - if my wish were your command I would keep sthum.
My wish is for Rust to stand still, offer no more features so I can catch up.
With the help of Clippy (primarily) and LLMs having much broader knowledge than me I am continuously finding new things - after five years using Rust.
For meta Rust, and on a related note, I am hoping that the Rust project management takes a good look at itself, and likes what it sees. I hope they work to keep the good things getting better and to deprecate the things that did not work.
The management and curation of Rust is very good. Naturally not perfect. It would be wasted on a project that was not as excellent as this.
Keep up the good work, all you wonderful people
4 Likes
My wish for rust are :
- Stable allocator API (good to do optimization in backbone library and performance sensitive program which why most people use rust)
- Stable compile time reflection (then I will not need proc macro again because it is complex and can not know what is the type. I already tried the nighly compile time reflection. It allows me to do thing at compile time to make it zero cost and improve safety. Like compile time SQL validation, compile time zero cost dependency injection, compile time code generation (easier than proc macro and superior because now I know the type information)
- Async reactor interface. So that the async ecosytem will be able to be used with any async runtime. Async runtime just need to implement the interface, then any async library will compatible with each other and can be used with any async runtime
2 Likes
- Generic functions over async, to reduce the async ecosystem split.
- Out of the box code coverage inside cargo test.
- Easier way to have an internal crate registry.
Perhaps you already know about it, but there's an "ignore" feature, which you might find most useful in that sort of situation; that's how I deal with it. Click on the avatar to get the profile, and you'll see it in the top right corner:
2 Likes
Frustratingly it doesn't work as well as I wish it did. It still shows topics as updated when an ignored user posts in them, and doesn't hide topics from the ignored user in the topic list.
Macro annoyances:
-
Say I have a mixed chain of A and/or B.
$( $($A:ā¦)? $($B:ā¦)? )=>+gets refused, as it could repeatedly match nothing. If either can come 1st or not at all, I canāt make one of them mandatory. If it did match both, Iād also want an arrow in between. This would be such a welcome construct:$( $Aā¦ $| $Bā¦ )=>+ -
Itās easy to skip something optional
$( ā¦ )?but then thereās no way to find out whether it was there. I work around it with something I donāt expect to match$( ā¦ $($dummy:ident)? )?ā ugly, and what if someone does provide an unexpected token there? Iād want an arbitrary capture$x:{ ā¦ } -
Hygiene with sub-macros can require a lot of verbose forwarding. Iād prefer a way to opt out of hygiene. Also it feels a bit random that hygiene doesnāt apply to all identifiers.
-
Macros caring about generated code correctness from their limited perspective can be painful. I just tried putting
$vis:visbefore a sub-macro invocation. Instead I had to forward it to all matching rules. If this were allowed and I generated wrong Rust, the compiler would catch it afterwards.
- Proper reflection which it looks like we'll be getting fairly soon
- Associated type defaults and async traits being stabilized
- Perhaps some form of "partial structs" to define fields across structs without code duplication or resorting to macros (this is one thing my Java-brain still has a bit of trouble coping with at times)