What does HackerNews think of msquic?

Cross-platform, C implementation of the IETF QUIC protocol, exposed to C, C++, C# and Rust.

Language: C

#43 in C
#23 in C++
#13 in C#
#4 in API
#93 in Rust
I referred to sockets as an API design, not to express an opinion on whether you should place your protocol implementations inside or outside the kernel. (Although that’s undeniably an interesting question that by all rights should have been settled by now, but isn’t.)

Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to cram SCTP in there[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.

[1] https://datatracker.ietf.org/doc/html/rfc6458

[2] https://quiche.googlesource.com/quiche

[3] https://github.com/microsoft/msquic

[4] https://github.com/litespeedtech/lsquic

Microsoft has an excellent implementation, too: https://github.com/microsoft/msquic
> Every app has to implement it itself

No? I'll just link against one of the cross platform libraries that implements it, the same as for any other networking protocol. (Ex https://github.com/microsoft/msquic)

Also see: https://github.com/quicwg/base-drafts/wiki/Implementations

> same as for TLS, making fewer apps implement it without a lot of extra work

... do you not just link against a relevant networking library at this point? If not, why?!