8 ms·

The GP got the facts wrong, but IMO we shouldn't dismiss the sentiment. In particular: > You are yearning for the simple and inefficient days of yore The simp

The GP got the facts wrong, but IMO we shouldn't dismiss the sentiment. In particular: > You are yearning for the simple and inefficient days of yore The simpler our systems are, the more we can understand them, and the more reliable we can make them. And more often than not, a system that's simple from top to bottom, and kept as small as possible, is efficient. Yes, I do kind of miss the days when HTTP was understandable enough that I could write my own HTTP server directly on top of a TCP socket API. TLS is a necessary evil to protect users from bad actors, but I'm not so sure about HTTP/2. In one of my Rust projects, I just switched from reqwest to ureq (yes, partly prompted by this discussion), and saved ~600K in a release build (already optimized for size). That's 600K of removed code that can't cause bugs anymore. And I know that in my particular use case, HTTP/1.1 will be good enough.

chrismorgan 4y ago
It’s worth noting that HTTP/2 is only a part of the difference there—reqwest is generally designed to spend more code on better correctness and performance and starts with async, whereas ureq is designed for simplicity and is synchronous-only, which all tends to lead to less code. For the point in question, it would be interesting to compare reqwest minus HTTP/2 support, or ureq with HTTP/2 support. On the matter of reliability: I’d honestly expect HTTP/2 and HTTP/3 to end up more reliable than HTTP/1 (my guess is that HTTP/2 probably already is, but HTTP/3 won’t be just yet), because binary protocols require more careful implementation and generally leave much less room for bad implementation, whereas text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs).
- mwcampbell 4y ago
  > text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs). And to be fair, the HTTP server that I did in fact write as a teenager in the late 90s (in the MOO programming language) was firmly in that category. I'm sure my mild wishing for those days is just nostalgia.

chrismorgan 4y ago

It’s worth noting that HTTP/2 is only a part of the difference there—reqwest is generally designed to spend more code on better correctness and performance and starts with async, whereas ureq is designed for simplicity and is synchronous-only, which all tends to lead to less code. For the point in question, it would be interesting to compare reqwest minus HTTP/2 support, or ureq with HTTP/2 support. On the matter of reliability: I’d honestly expect HTTP/2 and HTTP/3 to end up more reliable than HTTP/1 (my guess is that HTTP/2 probably already is, but HTTP/3 won’t be just yet), because binary protocols require more careful implementation and generally leave much less room for bad implementation, whereas text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs).

mwcampbell 4y ago
> text protocols are simple enough that the average quality of implementation is much lower (because barely-skilled developers can make something that mostly works without even looking at the specs). And to be fair, the HTTP server that I did in fact write as a teenager in the late 90s (in the MOO programming language) was firmly in that category. I'm sure my mild wishing for those days is just nostalgia.