Re:It's time to get the Posix elephant off our necks
by wahern on Wednesday February 22, 2023 @09:58PM
(#34906156)
> io_uring or Windows IOCP
They're great tools but they're not great abstractions. If you use them directly for all I/O, then every application in every programming language will end up looking JavaScript, which even with Promises is quite ugly. Promises aren't new; language designers avoided them as best they could for decades because they suck as abstractions.
Languages like Go do a great job at providing abstractions, and tools like io_uring and IOCP are useful for implementing those abstractions. But they're not ideal, either, nor are they necessary. Their value is diminished. Note that both io_uring and IOCP are implemented internally using thread pools that perform synchronous operations, not much different from how Go works when using traditional BSD Sockets interfaces to implement its abstractions. io_uring and IOCP have access to some optimizations, but the basic model remains the same.
If you read between the lines (discussion of pthread complexity, emphasis on virtual memory, which is fundamentally blocking) I think the author is implicitly making the same argument--that better abstractions would make synchronous threading more efficient and easier, and these should be available as a basic application primitives, rather than relying on languages and third-party runtime engines to build atop more coarse-grained primitives, io_uring and IOCP included.
They're great tools but they're not great abstractions. If you use them directly for all I/O, then every application in every programming language will end up looking JavaScript, which even with Promises is quite ugly. Promises aren't new; language designers avoided them as best they could for decades because they suck as abstractions.
Languages like Go do a great job at providing abstractions, and tools like io_uring and IOCP are useful for implementing those abstractions. But they're not ideal, either, nor are they necessary. Their value is diminished. Note that both io_uring and IOCP are implemented internally using thread pools that perform synchronous operations, not much different from how Go works when using traditional BSD Sockets interfaces to implement its abstractions. io_uring and IOCP have access to some optimizations, but the basic model remains the same.
If you read between the lines (discussion of pthread complexity, emphasis on virtual memory, which is fundamentally blocking) I think the author is implicitly making the same argument--that better abstractions would make synchronous threading more efficient and easier, and these should be available as a basic application primitives, rather than relying on languages and third-party runtime engines to build atop more coarse-grained primitives, io_uring and IOCP included.