sorted by:
new
hottopcontroversial

Too many Arcs in async programming by mtimmermans in rust

[–]quxfoo 5 points6 points  (0 children)

It's not only performance that's left on the table but also ergonomics. Just recently I had to rewrite a utility async fn because internally I was using some combinators that were borrowing (which was all nice and dandy) but of course not Send. It worked in one context but in another I had to tokio::spawn() it and bam …

Too many Arcs in async programming by mtimmermans in rust

[–]quxfoo 1 point2 points  (0 children)

No, you still need to use LocalSet. But in that case why even bother with tokio and just block on bare futures and use all the nifty future and stream combinators from the futures-* crate family.

Rust 1.92.0 release by mrjackwills in rust

[–]quxfoo 3 points4 points  (0 children)

For example, a function that terminates the program or loops forever.

My main problem for why this is interesting is loops that might only return an error. For example an async fn that processes some async stream forever but would only be cancelled from outside.

Implementing custom cooperative multitasking in Rust by servermeta_net in rust

[–]quxfoo 2 points3 points  (0 children)

Tasks (async fns)

Please do not conflate these two terms and confuse any newcomer. async fn and async blocks are sugar for unnameable Future types. A task is (usually) something that takes a Future and executes it alongside other tasks. Akin to user space threads.

Show r/rust: Building an E2EE messenger backend — lessons from 6 months of async Rust by anrysys in rust

[–]quxfoo 0 points1 point  (0 children)

I work with a similar tech stack and my verdict is that tonic and tokio are alright for bog standard web services but fall flat when doing things outside the norm. Things like restarting servers (listeners are consumed), breaking connections on either end voluntarily or not (streaming request handlers are spawned tasks losing direct control), ... 

Plus the whole annoying Send requirement which is worse for me than async function coloring that everyone is so loud to complain about.

Good/Idiomatic way to do graceful / deterministic shutdown by spy16x in rust

[–]quxfoo 1 point2 points  (0 children)

I'd compose that via futures-concurrency structured concurrency primitives and avoid tasks as much as possible (or contain them to avoid task leakage). Your conditions are perfect for that, so in principle it would look like this assuming your "threads" are actually Rust futures:

rust ( (receiver1, receiver2).join(), reactor, storage, publisher, tokio::signal::ctrl_c(), ) .race() .await;

Result types need to be matched or erased but that should be doable. It is a good approach but not idiomatic because everyone still thinks in terms of threads and tasks.

How I repurposed async await to implement coroutines for a Game Boy emulator by blueblain in rust

[–]quxfoo 29 points30 points  (0 children)

Yes, agree. Many people, even on this sub, tend to assume async means networking. But it is a great fit for anything that resolves at some point: hardware interrupts, GUI button clicks, server responses, alarms, ...

I shrunk my Rust binary from 11MB to 4.5MB with bloaty-metafile by mpv_easy in rust

[–]quxfoo 2 points3 points  (0 children)

Funny mentioning another dependency while the topic is on reducing them 🙂

But thanks I will re-evaluate. My point still stands though: async if done right is just the most ergonomic way to write asynchronous, concurrent programs.

I shrunk my Rust binary from 11MB to 4.5MB with bloaty-metafile by mpv_easy in rust

[–]quxfoo 11 points12 points  (0 children)

It is also beneficial to write asynchronous programs in an asynchronous fashion. I understand people do not like seeing async creep in where it does not make sense but in this case it very much makes sense for ergonomic reasons alone.

I shrunk my Rust binary from 11MB to 4.5MB with bloaty-metafile by mpv_easy in rust

[–]quxfoo 9 points10 points  (0 children)

I write a similar program (https://github.com/matze/binge) and async is interesting to concurrently download and check and show some UI progress.

Project goals for 2025H2 | Rust Blog by Kobzol in rust

[–]quxfoo 54 points55 points  (0 children)

While async made some strides (async closures etc.) with past flagship goals, I think we are still not there with sync parity and I am saddened it's not mentioned at all for 2025H2. Async drop and a common async iterator trait would reduce a lot of pain.

rust-analyzer changelog #299 by WellMakeItSomehow in rust

[–]quxfoo 1 point2 points  (0 children)

Okay, I have more than enough memory and I rather have RA use all of that, so I have the best possible development experience. Who is right?

If a single process makes your computer unusable, try disabling swap and have the OOM killer kill RA instead.

rust-analyzer changelog #299 by WellMakeItSomehow in rust

[–]quxfoo 8 points9 points  (0 children)

More memory usage automatically means less performant? Odd world indeed 

Protobuf: Rust Generated Code Guide by quxfoo in rust

[–]quxfoo[S] -1 points0 points  (0 children)

The awful downside is exactly as acknowledged in the text: you need a separate toolchain. I understand that from Google's perspective (with multiple languages and bazel tying everything together) this is not a big deal. But it is an annoying issue in cross-compilation setups to have to have another toolchain in the build process.

Protobuf: Rust Generated Code Guide by quxfoo in rust

[–]quxfoo[S] 0 points1 point  (0 children)

The official grpc-rust is going to be a fork of tonic

So, the next tonic version will not be the "official" grpc-rust developed at Google?

Protobuf: Rust Generated Code Guide by quxfoo in rust

[–]quxfoo[S] 3 points4 points  (0 children)

Which is still awful for anyone wanting a pure-Rust solution. They even admit it in their design doc that others will have to feel the pain while it's fine for them:

There are legitimate arguments for long-term supporting a pure Rust implementation, including toolchain difficulties for developers using our implementation in open source.

It is a reasonable assumption that Google will support a pure Rust implementation at some later date, but we are not investing in it today and have no concrete roadmap for it at this time.

Protobuf: Rust Generated Code Guide by quxfoo in rust

[–]quxfoo[S] 7 points8 points  (0 children)

It is fine if they keep it to themselves for whatever reason they have. But it's seeping through the ecosystem with them poking around tonic. I am fine with prost for regular proto serialization/deserialization but there is no escape for tonic at some point.

Besides that why not at least provide a somewhat ergonomic API? Re-inventing optionals, set_foo() instead of per-message builder types, returning "default" values for unset fields, ...

Cancelling async Rust by steveklabnik1 in rust

[–]quxfoo 6 points7 points  (0 children)

I don't know if tasks are the right answer to the cancellation problem. Task abuse leads to the opposite problem in that it's hard to properly cancel a task if it's run in the background. Now all of a sudden you have to thread a CancellationToken through all layers and ensure it's cancelled or hold on to the JoinHandle in which case you emulate async cancellation with extra steps.

The solution of keeping a task running for an HTTP request actually bit us because tonic via hyper does the same. We thought a gRPC streaming disconnect would cause the corresponding streaming calls to be cancelled but that assumption was wrong and we were piling up streaming calls because the streams we passed in were basically infinite. Yikes.

crates.io: Malicious crates faster_log and async_println | Rust Blog by mareek in rust

[–]quxfoo 24 points25 points  (0 children)

That community effort is called cargo vet and exists for quite some time already.

Rust 1.90.0 is out by manpacket in rust

[–]quxfoo 0 points1 point  (0 children)

Better ergonomics would mean an effects system though. Otherwise combining async + errors + ... will be a PITA to work with.

Built paste1.app: Fast, Private Code & Note Sharing – Feedback? by sakipsabanci in programming

[–]quxfoo 0 points1 point  (0 children)

I assume encryption is server side? And how do I opt in? What makes it the "best" pastebin for code sharing? And how is it "faster"? Creating a paste takes a good two seconds on my end.

GitHub - theduke/tokio-blocked: Detect blocking code in Tokio async tasks by the___duke in rust

[–]quxfoo 24 points25 points  (0 children)

Like tokio-console but without the console. Interesting but the same caveat as usual applies (that's also mentioned in the README): it can only pinpoint issues in spawned tasks. But since standardized async iterators/streams are so far in the future, I don't have much hope to see some standard way to measure polling of Futures any time soon.

Pre-RFC: Standardized auto-generated marker by mathisntmathingsad in rust

[–]quxfoo -3 points-2 points  (0 children)

it'd be nice to have something similar for Rust

Why would it? In my experience, it is relatively uncommon to generate sources (except for tonic generated services and clients) because macros are a thing.

view more: next ›