4 ms·
I think it's happening somewhat in the software space, where we pursue speed improvements by penetrating through sometimes literally decades of accumulated cruf
by jerf 7y ago
I think it's happening somewhat in the software space, where we pursue speed improvements by penetrating through sometimes literally decades of accumulated cruft layers to build something more modern. It is ironically harder precisely because it's easier; we've got a lot more software layers because it's so much easier to add another one. Wayland is probably one big example of it, but I often have this feeling in my Go code, too, where instead of a framework on top of a framework on top of a very framework-y core language like Python, we more-or-less just get on with it, both at the level of the code I type, and in the generated assembler as well. I imagine Rust programming feels much the same way when working with Rust-native libraries, I just don't have direct experience.
It's not all Electron apps out there.
Also, when I call something "accumulated cruft", it's not just vague "bloat" concerns I'm referring to; you have the problems of several layers of leaky abstractions, and those leaky abstractions may well date from an era of radically different hardware. It's true this can cause "bloat", but it causes other problems, too.
- the_duke 7y agoQUIC/Http3 could be another software example of this. There is too much cruft in the TCP/IP + HTTP stacks, so the solution is to implement a new protocol on top of the lowest abstraction that can be practically used (IP+UDP) in user space; at least until kernels implement it. I will delegate judging if this is a good idea to more knowledgeable parties though.
- ocdtrekkie 7y agoIsn't QUIC/HTTP3 the opposite? It's moving up the layers of abstraction, by moving something that would previously have been managed at layer 4 up to a higher layer. Running everything that used to be done in the network layer up to the application layer and putting everything on top of HTTPS is the opposite of what the parent is advocating for.
- jerf 7y agoIf we consider it relative to HTTP1 just to heighten the contrast, it takes the layers of: TCP connection management and negotiation, plain text framing protocols, protocols too limited to deal with the greatly-increased use of or need for multiple streams at once, SSL layering its own negotiation in, rather hacky stories around websockets/SSE (which are usually used as text protocols framed inside of text protocols framed inside of text protocols... not really the best setup), and probably a couple of other things. All of these things were designed for a different era at the very least, and often designed independent of each other. HTTP3 slices through the whole thing and creates nearly an entire protocol stack for its needs, using only the minimum it needs from IP to work over the internet at all. My software engineering instincts tell me this is all a bad idea and those layers should be kept separate as they were, if indeed they weren't already intermingled more than they should be (e.g., SSL & SNI; "why should SSL have to know anything at all about how HTTP deals with host names?" say my instincts). However, I intellectually realize that my software engineering instincts are not calibrated for the size of the HTTP world, nor the amount of resources that can be thrown at this problem. It's a great example of slicing through many layers that make sense independently, but just never quite went together properly, to make something that's going to perform better without 30 years of mismatching layers stacked on top of each other. (I'm not saying HTTP3 is perfect, only that it is a good example of someone at least trying to do what I was talking about.)
- the_duke 7y agoI guess it's kind of both. It circumvents the established network and software stack and builds a new protocol on the lowest-level abstraction that can be used practically (IP + UDP) because everything else would require hardware and kernel support, which would take many years to manifest.