Hi, Speaking as a QUIC and Rust enthusiast.
>From my experience, a significant friction point for QUIC adoption in non-browser Rust applications is not so much availability of async (after all, at least for quinn and s2n-quic tokio-based async is a first class citizen), but the relative immaturity and fragmentation of the HTTP/3 layer and the lack of convergence with existing, widely used HTTP abstractions. In Rust today, hyper is the de-facto standard HTTP crate, and many higher-level frameworks build on it for HTTP/1 and HTTP/2 client and server support. Unfortunately, hyper does not support HTTP/3, and while there have been efforts in that direction [1], progress appears slow and there is no convergence into the main hyper crate in sight. At the same time, quiche provides a solid and production-proven HTTP/3 implementation, but it is intentionally quiche-specific and does not integrate with the common Rust http types or the hyper ecosystem. The result is that an application that wants to support HTTP/3 _and_ earlier HTTP versions often ends up with duplicated code paths and bespoke abstraction layers whose only purpose is to bridge over ecosystem gaps. That is a non-trivial engineering cost, and one that is hard to justify unless QUIC-specific features are central to the application value. I suspect a similar pattern exists in other language ecosystems as well, though I have less hands-on experience there. Without some level of convergence at the HTTP layer, QUIC and HTTP/3 remain harder to adopt, regardless of how good the underlying transport libraries are. Best Regards, Yaroslav [1] https://github.com/hyperium/h3 On Thu, Jan 8, 2026 at 11:23 AM Lucas Pardue <[email protected]> wrote: > Hi, > > Speaking with only the hat of a QUIC implementation maintainer and > addressing some of the API topic. > > On Wed, Jan 7, 2026, at 13:48, Chris Box wrote: > > Reviving this thread for the new year. > > On Sat, 22 Nov 2025 at 17:24, Michael Welzl <[email protected]> wrote: > > Hi, > > These minutes are great, thanks! Seems like it was an interesting > conversation. > > > Agreed. My takeaway is that evangelising the benefits of H3 over H2, > supported by some new public data, would really help. Data on the problem > areas, with advice on how to handle them is also needed. This can then spur > development of libraries and encourage shipping with default-on > configuration. > > Need better tools in programming languages to make it easier to use QUIC. > > FWIW, this is why the TAPS WG existed, see RFCs 9621, 9622, 9623. It > would be great if we could get some momentum towards more implementations, > specifically ones that use QUIC… surely there’s no easier way for people > to access QUIC’s features without having to care about the specifics. > > > I agree the modern Transport Services API should be encouraged. > https://www.rfc-editor.org/rfc/rfc9623.html#name-existing-implementations > lists > Apple's Network.framework, NEAT and two Python implementations. > > > I currently have two master students working on implementations that will > use QUIC, but that’s as much as *I* can offer, from the world of academia. > > > Thank you for that! > > > PS: there’s also https://github.com/tfpauly/draft-taps-quic-mapping but > it’s going stale… > > > It strikes me as odd that 9621-9623 didn't include support for 9000. Is > there a reason why the QUIC mapping wasn't seen as important? > > > From my experience, API development and maintenance are a huge cost > center. While an API definition might do some of the work, theres an > iceberg beneath that. > > The quiche project I maintain provides a low-level Rust library for QUIC, > with a FFI to allow usage from C. Similarly there is a low-level HTTP/3 > layer that sits on top with Rust and FFI APIs. The expectation is that > these are integrated in an application that provides the I/O and event > runtime. Its is common that HTTP applications have their own > programming/object model and API (potentially 1st parh1ty or 3rd party > common libraries). > > quiche is used to power several Internet-scale production systems at > Cloudflare. Its used by other folks at scale too, who can name themselves. > It can also be used as a backend for curl. The project is active and > embraces QUIC's innovation capabilities. We regularly tweak the API as we > learn from deployment experience, introduce new IETF work, or run other > experiments or trials. > > quiche is not the only Rust implementation. neqo, quinn, and s2n-quic are > some more-widely known ones, and there are others. > > One of the common anecdotes I've heard over past years is something like > "I really wanted to use quiche but my project is using async Rust which is > not directly supported. I didn't want to have to write ans maintain my own > layer, so I used quinn instead". I'm not going to begrudge people picking > software that lets them get on with life. The lack of a quiche async > friendly API was primarily down to the project maintainers not needing one. > In recent years, that's changed and in the last year we've open sourced > "tokio-quiche" [1], which sits further atop the low-level libs mentioned > above. > > As much as it might pain people to hear, I struggle to see what benefit a > TAPS-like interface would provide. It sounds like a tonne of work that > would introduce friction to my ongoing project needs. I have no idea what > it would mean for the applications that build on top it. I doubt we'd use > it ourselves and it would likely become a second class citizen. > > More recently, I've seen people brand new to the world of QUIC use > AI-coding assistants to quickly build functional prototypes using quiche or > tokio-quiche. I suspect they could switch implementation easily too, if > required. If one of the arguments for TAPS is that it reduces the barrier > for new entrants to try the QUIC protocol, I think that argument is being > rapidly eroded. > > Finally, another statement that others might find controversial. IMHO if > you have a custom application that can just be flipped from TCP to use QUIC > by a couple of lines or flags, I suspect that the application is so simple > that there's going to be very few benefits to QUIC. The new dimensions of > operational considerations will likely kill any enthusiasm gained from a > simple flip-on switch. For more-complicated applications, then its likely > they've already invested in a stack of technologies and build the > abstraction they already need. > > Cheers > Lucas > > [1] > https://blog.cloudflare.com/async-quic-and-http-3-made-easy-tokio-quiche-is-now-open-source/ > > > Chris > > > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
