Comment by refulgentis

Please don't try this at home. This is clickbait, or alternatively, a naive discussion that didn't expect top-of-HN attention.

There's one issue spelled out as a premise, namely, that this requires another connection thats perfectly 100% reliable.

Then, there's another glaring issue. I won't recap the article for this one because there's too much verbiage involved. TL;DR: fallible is assumed to mean "if the server receives a request, its guaranteed the client will receive a response". [1] shows what happens when that's not the case

Last but not least, there's a lot more to TCP than what's let on in the article. "turns out this absurd hypothetical isn't actually that far off of how TCP+TLS and UDP behave" -- I won't attempt to claim this for UDP, but I am 110% certain that this is extremely misleading for TCP. McDonald's hamburger isn't that far off from steak is significantly more accurate.

Usually I wouldn't skewer something, but, I've seen the horror of a "we'll just do the good and necessary parts of TCP" reimplementation. One that ran on 10s of millions of devices and led to crappy Bluetooth syncing and throughput for years. Two people picked the parts of TCP they thought were necessary, hacked it in, and it's hard to accept how much this cost various people and companies in various ways. 10 digit problem.[2]

[1] c.f. here for an easy trace in the article's vernacular of what happens if that's not the case https://pastebin.com/0Zs1pRfR

[2] arguably, the problem here wasn't trying it, but management being unable to handle everything after trying it. But that's a whole different story :) -- at 26 I would have thought this was impossible, at 36, I expect it