Ralith

> the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.

This isn't accurate. The core protocol objects in Quinn are those defined in "quinn-proto", which has absolutely no awareness of how I/O is performed or what event loop is in use: the interface is structurally very similar to Quiche's, with the caller providing data/timeouts by any means and consuming events that result. See https://docs.rs/quinn-proto/0.2.0/quinn_proto/struct.Endpoin... for details.

The high level "quinn" crate interface, which incorporates awareness of UDP sockets and the tokio event loop, is strictly an optional binding; that's why it's a separate crate.

> existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.

Support for this type of flexibility, up to and including allowances for a C API suitable for integration with existing software, has actually been an express design goal of Quinn from the start, and I regret that that wasn't clear.

Comment · 7 years ago

It's worth emphasizing that QUIC is more general than a new transport for HTTP; it has wide ranging applications, due to being far more versatile than TCP.

Comment · 7 years ago

All Rust programs call out to platform-dependent unsafe code sooner or later in the form of the standard library. Otherwise, you wouldn't be able to allocate memory or do any I/O whatsoever.

Sometimes the standard library doesn't expose functionality you want, like the capability to read/write the ECN bits of your UDP packets, so you have to bind some syscalls yourself. The capability to do this is one of Rust's core strengths, and it does not compromise a program's rustiness any moreso than calling a wrapper around write to print "Hello, world!" does.

Comment · 7 years ago

The current draft encourages, but does not require, QUIC implementations to employ path MTU discovery along those lines; see https://quicwg.org/base-drafts/draft-ietf-quic-transport.htm... for details. Quinn doesn't yet have this implemented, but it would be pretty cool!

Comment · 8 years ago

> But for C/C++ projects I would just compile in an Ubuntu container as well.

Setting up a reproducible build environment with nix-shell is much more convenient than screwing around with containers.

Comment · 8 years ago

> Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.

This is actually easier to deal with on NixOS than elsewhere, because the tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple versions of a lib, etc) are so well developed.

Comment · 8 years ago

> most of the configuration is for desktop stuff and NixOS doesn't really cover that.

I like home-manager: https://github.com/rycee/home-manager

Comment · 8 years ago

You just pass it in explicitly: https://nixos.org/nixpkgs/manual/#sec-pkg-override

Comment · 8 years ago

> I invented quaternions using matrices

what