Anyone can go on the internet and tell lies, and being smug armchair architects is a favorite bloodsport in our industry, but seriously shut up.
Conversation
Replying to
Cross-platform async APIs in my opinion have one of the highest bars for running code and precise benchmarks next to a field like cryptography. They are notoriously hard to get right with tradeoffs everywhere
Quote Tweet
The kernel APIs are brittle and unforgiving and to the extent people can actually build cross-platform abstractions it's through blood, sweat, and tears.
Nearly every attempt I've seen to second-guess decisions made by people in-the-trenches has ended in a breakage.
Show this thread
1
4
AIO for storage is also a lot different than the best way to deal with sockets. Making a portable abstraction for any of this involves many sacrifices, and I think at this stage it's hard to end up with a result that's not disappointing for Rust's niche.
Quote Tweet
Replying to @DanielMicay @raggi and @thinkingfish
I don't think it's possible to have an AIO library that's both good and portable right now. The whole point of Rust is having efficient abstractions mapping well to the low-level details. If it's not a thin abstraction over io_uring, it fails at being a good AIO library on Linux.
2
4
Yeah, there is nothing resembling a portable model for asynchronous filesystem I/O. The best you can do involves throwing thread pools at certain common filesystem operations on certain platforms.
1
3
nginx uses thread pools for AIO on Linux and it works very well:
nginx.org/en/docs/http/n
Cloudflare uses a patch for async open in addition to the standard read, write and sendfile support. It's only an issue when you have a huge number of files since otherwise it's cached.
1
3
There's ongoing work on using io_uring. The main advantage is saving CPU and memory resources. It's not significantly faster for general usage. It's only really significantly faster for lots of small files where the overhead of working with the threads is significantly higher.
1
3
I'm familiar with io_uring 😜
Quote Tweet
My experience report for shipping a Ruby binding which uses a C extension that wraps io_uring: multiple issue reports from people whose kernel headers were out-of-date
Show this thread
1
3
Yeah, I saw that. I just meant that in the context of the most popular web server, threads are largely good enough already. I would have thought that io_uring would have more to offer but scaling up the number of threads generally ends up offering comparable performance for it.
1
2
I'm sure it's a lot more compelling for something like a database. Thread pools work a lot better than people seem to think though. One caveat is nginx allows you to configure separate thread pools for different storage devices via the usual server/location block configuration.
1
2
I see a lot of problems with Rust's library ecosystem for AIO, etc. but the language portion of it seems really good. I don't really see the problem. I'm glad Rust went this way and I think the approach in Go is going to look like a clear mistake to most people in hindsight.
1
1
4
If you haven't seen it, look at fuchsia.dev/fuchsia-src/co. This is pretty much the same for Android, where Rust is being heavily adopted for platform code. I doubt they would use Go for anything beyond more tooling if at all.
Also github.com/google/kati/bl is a similar experience.
Rust could have easily ended up with GC and M:N threading if it had been rushed along more instead of spending so much time figuring things out.
Most of the things I regard as mistakes in Rust are in the standard library, not the language, so they're largely avoidable anyways.
1
3
Shipping the libnative/libgreen split and “libio1” would’ve been bad (not to mention GC)
3