Rust

5989 readers

5 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

Rust Project goals for 2024 (blog.rust-lang.org)

submitted 3 months ago by [email protected] to c/[email protected]

6 comments fedilink hide all child comments

top 6 comments

sorted by: hot top controversial new old

[–] [email protected] 0 points 3 months ago

Tldr; their flagship goals are:

2024 edition: (1) supporting -> impl Trait and async fn in traits by aligning capture behavior; (2) permitting (async) generators to be added in the future by reserving the gen keyword; and (3) altering fallback for the ! type.

Async: support for async closures and Send bounds.

Rust in the Linux kernel: focus on the unstable features it uses so it can progress out of the experimental phase.

And highlights other goals:

Stabilize cargo-script
Improving Rust's borrow checker to support conditional returns and other patterns
Move parallel front end closer to stability
Ergonomic ref counting
Implementing "merged doctests"

With a link to a list of 23 other goals

[–] [email protected] 0 points 3 months ago (2 children)

I wish Rust would adopt tokio (or any other, if better suited) as a default first citizen async runtime. Then everyone can be sure to write in that runtime , knowingly it will run. If people need a different runtime, they could still opt out of tokio and opt in to whatever they like. The freedom of choice would not be hindered, but we would gain a default runtime.

What's stopping this from happening?

[–] [email protected] 0 points 3 months ago

Is that even desirable? There are other runtimes for specific things, e.g. for embedded, WASM, Fuchsia, etc. Doesn't seem like there's a one-size-fits-all runtime.

I guess the proper answer is some kind of minimum standard async interface, but presumably there's a reason they haven't done that.

I dunno really, I've avoided async Rust as much as possible due to the number of footguns it has.

[–] [email protected] 0 points 3 months ago* (last edited 3 months ago) (1 children)

Goal is to keep the std to the absolute minimum. It's a lot easier to change a normal library and switch over, than to change std. Just ask the c++ guys about their reflex support.

That's the reason rand, regex, num, chrono etc. aren't part of the std.

[–] [email protected] 0 points 3 months ago (1 children)

Or look at Python and their urllib, urllib2, new urllib, and the requests package on PyPi.

We already sort of saw this in Rust with crossbeam and standard channels, until of course they replaced the standard lib implementation with crossbeam's implementation.

[–] [email protected] 0 points 3 months ago

Yeah, std can never break backwards compatibility. So any big thing that gets added needs to be sure it wont ever change. Something like tokio is far too large for that and already does not fit all use cases.

What I want to see is more support for interop between the different run times by providing standard interfaces for things between the various runtimes. For instance being able to spawn a task in for the runtime to take care of. You cannot do that without knowing which runtime you are using ATM. Which is highly anoying for developing libraries that need to do this. And that is only one of the many problems that could be solved in the std lib without needing to bring in the whole runtime - just create common interfaces we can use that can be implemented by each runtime,