Let me try providing a different perspective based on experience. QUIC works amazingly well for _some_ kinds of machine to machine traffic.
ssh3, based on QUIC is quicker at dropping into a shell compared to ssh. The latency difference was clearly visible.
QUIC with the unreliable dgram extension is also a great way to implement port forwarding over ssh. Tunneling one reliable transport over another hides the packer losses in the upper layer.
The article that GP posted was specifically about throughput over a high speed connection inside a data center.
It was not about latency.
In my opinion, the lessons that one can draw from this article should not be applied for use cases that are not about maximum throughput inside a data center.
QUIC v1 does encrypt the SNI in the client hello, but the keys are derived from a predefined salt and the destination connection id. I don't see why decrypting this would be difficult for a nginx plugin.
> For example, instead of a power function that uses a loop, you could generate specialized code like x * x * x * x * x directly. This eliminates runtime overhead and creates highly optimized code.
Could anyone explain to me how this is different from templates or parameter pack expansion in C++? I can see the constexpr-ness here is encoded in the type system and appears more composable, but I am not sure if I am missing the point.
I looked at the paper but I can't find anything related to C++.
> Could anyone explain to me how this is different from templates or parameter pack expansion in C++?
I don't think it's any different.
> I can see the constexpr-ness here is encoded in the type system
I also see they introduce new constructs like let$, so it's not just a type system thing.
> I looked at the paper but I can't find anything related to C++.
I don't think the author needs to compare their code to C++. That said, it looks to me like it is similar to the upcoming C++26's reflection capabilities.
It's an interpreter though, not a JIT. This kind of programming language thing is a bit of a hobby horse of mine, so see the comment I just posted on this for full details:
Wondered about the same thing. Perhaps the author deals with graphs with no side effects or branches? It would then trivially become CSE on a single basic block.
SSA transformations are essentially equivalent to what the author appears to be doing in terms of let-bindings [0].
Can anyone suggest simple to implement algorithms for SSA destruction? I find Cytron's destruction easy (paired with copy propagation), but the more recent ones are difficult to implement directly from the papers.
Aren't we paying for Result types every time it's used? A result of a 64 bit value wouldn't fit into $eax for example (I understand there are exceptions to this rule through invalid bit pattern optimizations)
Cargo workspaces do not support compiling two subprojects for two different targets in a single build invocation. The workaround was (still is?) to use each subproject as a standalone project just for builds. The dependency between these targets is now expressed by the Makefile invoking cargo. This also breaks IDE integrations because your IDE does not know how to ask cargo to pick the right target for each workspace member.
Bazel makes this consistent with platforms [0]. I have not used bazel with Rust but it worked fine for my multi-target C++ builds.
