4 ms·

Abstraction hides detail, but at what coat? A network close call at a high level closes a network socket. But at the tcp level there's a difference between clo

by mannyv 2y ago

Abstraction hides detail, but at what coat? A network close call at a high level closes a network socket. But at the tcp level there's a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset. Is the difference important? If depends. If you have a bunch of half open sockets and run out of file descriptors then it becomes very important. Another example: you call read() on a file, and read 10k bytes. Did you know your library was reading 1 byte at a time unbuffered? This abstraction will/can cause massive performance problems. My favorite one is when a programmer iterates over an ORM-enabled array. Yes, let's do 50,000 queries instead of one because databases are too complicated to learn. Just like any tool, abstraction has costs and benefits. The problem is that lots of people ignore the cost, and assume the benefit.

atomicnumber3 2y ago
I think an important distinction is hiding details from other parts of the program, and having details being hidden from you. 99.9% of the time I don't care what the tcp socket closes with as long as it isn't leaking a resource. And if I did care, then I picked the wrong level of network abstraction to engage with. I should've used something more raw. Regarding ORM arrays. I have myself recently debugged such a case. I chortled a bit at the amateur who wrote the code (me last year) and the schmuck who accidentally wrapped it in a loop (me 3 weeks ago). Then I changed it slightly to avoid the N queries and went on with my day. No need to lambast the tooling or the programmers. Just write something maintainable that works. No need to throw the entire ORM away just because we accidentally made a web page kinda slow that one time. And don't worry, I too lament when web pages I don't control are slow. You may rest uneasily knowing that that page would be slow regardless of whether ORMs existed because it is not slow because of ORMs, but because there is no incentive for the business to care enough to make it faster.
f1shy 2y ago
>> But at the tcp level there's a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset. If you are doing a „TCP application” of course it makes no sense to abstract the TCP layer. Is not about cost. Now if you have an application that has to communicate somehow with other system, and you want to not depend on specific protocols, then the communication part should abstract away that part. How to deal with your example? Well, if you can say “I will always want X, you can make a configuration option “TCP.close” or “TCP.reset”. If “it depends” then you have to build the logic for the selection in the abstraction layer, which keeps hidden.
josephcsible 2y ago
> Your api has removed that choice from you It has? Can't you rely on connect(2) with AF_UNSPEC doing a RST, and shutdown(2) with SHUT_WR doing a FIN?

by mannyv 2y ago

atomicnumber3 2y ago

I think an important distinction is hiding details from other parts of the program, and having details being hidden from you. 99.9% of the time I don't care what the tcp socket closes with as long as it isn't leaking a resource. And if I did care, then I picked the wrong level of network abstraction to engage with. I should've used something more raw. Regarding ORM arrays. I have myself recently debugged such a case. I chortled a bit at the amateur who wrote the code (me last year) and the schmuck who accidentally wrapped it in a loop (me 3 weeks ago). Then I changed it slightly to avoid the N queries and went on with my day. No need to lambast the tooling or the programmers. Just write something maintainable that works. No need to throw the entire ORM away just because we accidentally made a web page kinda slow that one time. And don't worry, I too lament when web pages I don't control are slow. You may rest uneasily knowing that that page would be slow regardless of whether ORMs existed because it is not slow because of ORMs, but because there is no incentive for the business to care enough to make it faster.

f1shy 2y ago

>> But at the tcp level there's a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset. If you are doing a „TCP application” of course it makes no sense to abstract the TCP layer. Is not about cost. Now if you have an application that has to communicate somehow with other system, and you want to not depend on specific protocols, then the communication part should abstract away that part. How to deal with your example? Well, if you can say “I will always want X, you can make a configuration option “TCP.close” or “TCP.reset”. If “it depends” then you have to build the logic for the selection in the abstraction layer, which keeps hidden.

josephcsible 2y ago

> Your api has removed that choice from you It has? Can't you rely on connect(2) with AF_UNSPEC doing a RST, and shutdown(2) with SHUT_WR doing a FIN?