• 0 Posts
  • 70 Comments
Joined 2 years ago
cake
Cake day: December 24th, 2023

help-circle





  • the world wasn’t born with companies. Trying to argue their morals as the ultimate truth is toxic to our humanity.

    if all a company cares about is shareholders, said company doesn’t deserve to exist.

    you argument is trying justify the status quo and arguing for a system that is innately oppressive and cruel. “That’s how it is” We should make it not be like that just the same as we made it be.









  • I am quite cheeky for saying this but:

    How is it leaky if the default paradigm of any sequential program is the expectation that it will block? If i write blocking socket code I know my thread is blocked until read() returns.

    If i am writing async socket code I know to wait for poll or whatever it is that is the correct way to wait nowadays. My design would reflect that. The blocking is just moved to another thread effectively and this abstraction is packaged as a Future.

    Asynchronous code does not require the rest of your code to be asynchronous. I can’t say the same for blocking code.

    Well this is just stating a tautology isn’t it?

    Edit:

    It would be a Hurculean effort, and I don’t think it’s a sustainable approach. If you’re writing a higher level library, it would be a lot to ask to check if your dependency’s dependency’s dependency maybe reads from a socket.

    I guess I understand what’s the argument here.

    The author wants a safeguard against libraries that are blocking with compiler checks. I agree it is a nice thing to have. But they could have mentioned that without saying “blocking code is leaky abstraction”.