I don't understand the difference to TCP here. If the path is not congested but the receiving endpoint is, the receiver can control the bandwidth by reducing the window size. Ultimately, it is always the sender that has to react to congestion by reducing the amount of traffic sent.
RPC is something of a red flag as well. RPCs will never behave like local procedure calls, so the abstraction will always leak (the pendulum of popularity keeps swinging back and forth between RPC and special purpose protocols every few years, though).
AFAIK, an ebpf function can only access memory it got handed as an argument or as result from a very limited number of kernel functions. Your function will not load if you don't have boundary checks. Fighting the ebpf validator is a bit like fighting Rust's borrow checker; annoying, at times it's too conservative and rejects perfectly correct code, but it will protect you from panics. Loops will only be accepted if the validator can prove they'll end in time; this means it can be a pain to make the validator to accept a loop. Also, ebpf is a processor-independent byte code, so vectorizing code is not possible (unless the byte code interpreter itself does it).
Given all its restrictions, I doubt something complex like a graphics driver would be possible. But then, I know nothing about graphics driver programming.
> Fighting the ebpf validator is a bit like fighting Rust's borrow checker
I think this undersells how annoying it is. There's a bit of an impedance mismatch. Typically you write code in C and compile it with clang to eBPF bytecode, which is then checked by the kernel's eBPF verifier. But in some cases clang is smart enough to optimize away bounds checks, but the eBPF verifier isn't smart enough to realize the bound checks aren't needed. This requires manual hacking to trick clang into not optimizing things in a way that will confuse the verifier, and sometimes you just can't get the C code to work and need to write things in eBPF bytecode by hand using inline assembly. All of these problems are massively compounded if you need to support several different kernel versions. At least with the Rust borrow checker there is a clearly defined set of rules you can follow.
There's no reason they can't instead be used to show how data transforms. The sort of 'flow wall' someone sees in a large industrial setting (think water/waste water treatment plants, power plants, chemical plants, etc) or process mockup diagrams for spreadsheet heavy modpacks (I'm looking at you GregTech New Horizons).
Data can instead be modeled as inputs which transform as they flow through a system, and possibly modify the system.
The fun really starts if you have a CPU using big endian and a bus using little endian..
Back in the late 1990s, we moved from Motorola 68k / sbus to Power/PCI. To make the transition easy, we kept using big endian for the CPU. However, all available networking chips only supported PCI / little endian at this point. For DMA descriptor addresses and chip registers, one had to remember to use little endian.
For high-speed networking, exokernel concepts are now being used in the form of DPDK (user space) and eBPF/XDP (user code dynamically verified and loaded into kernel space). Exokernels aimed to move kernel functionalities not into a bunch of separate processes like microkernels, but into libraries. In the late 1990s, I worked on such a system which unfortunately fell victim to the dotcom crash.
lifetimes, async, the myriads of pointer types, that poor-person's monad '?' for a single type..
Sure, you need to give the compiler a lot of hints to achieve what Rust is doing, but it does not look pretty or elegant.
Lifetimes are indeed unique, but hardly take up much syntactical space.
? operator is fine, especially if you’re used to JS or C#, and hardly take up much space.
Pointer types are what, & and * ? Fine if you’re coming from c, c++ and don’t take up much space.
.async is the weirdest for sure, but again hardly strange or disgusting.
What about any of this is worse than if I smashed my face into my keyboard but hit only the $*%#•¥$><~.,!=&@£.?!’ characters, aka writing Perl? Or anything as totally alien as Haskell?
Most Rust I read or write, if I squint, looks like Python with a few extra braces and semicolons.
I was thinking of things like Box, Rc, Arc, Cell, Refcell. Then there is also the macro language, which integrates Scheme concepts. Like C++, it is a huge language, with extra wrinkles for every new corner case. Again, maybe this all is unavoidable if one wants to have zero cost abstractions. Hopefully, language designers will learn from Rust and come up with something more elegant.
Out of those, Box is the only one that is, and the way that it is is not syntax: it has one exception, and that’s that you can move the contents out of it via a dereference. That’s making existing syntax semantically valid, not introducing new syntax.
In terms of syntax, you create a box with Box::new just like you might any other struct.
EDIT: anyway I'm not saying that means that your underlying issue isn't real, just that I think describing it as "syntax" makes the issue confusing to understand. It sounds to me like maybe you think Rust programs are too verbose?
From my VoIP experience, there is no 'typical' in NAT. There have been attempts to classify NATs (https://www.rfc-editor.org/rfc/rfc3489, Section 5), but they have been abandoned after seeing how NATs sometimes change their behaviour dependent on their load, the number of connections, the phase of the moon etc (https://www.rfc-editor.org/rfc/rfc4787, Section 3). So, yes, application-level keepalives are your best bet.
By this they mean expulsion of all people -including citizens- who don't "look German" and people who support them. If this is not fascist, I don't know what is.
RPC is something of a red flag as well. RPCs will never behave like local procedure calls, so the abstraction will always leak (the pendulum of popularity keeps swinging back and forth between RPC and special purpose protocols every few years, though).