What Unix pipelines got right and how we can do better
programmingsimplicity.substack.com
What Unix pipelines got right and how we can do better
1–10 of 22 posts
Re: What Unix pipelines got right and how we can do better
#2I find Paul's take on simplicity(and complexity) very illuminating.
Re: What Unix pipelines got right and how we can do better
#3> This cross-language composition remains remarkably rare in modern development, where we typically force everything into a single language ecosystem and its assumptions.
I think IPC via HTTP, gRPC, Kafka, files, etc allows language decoupling pretty well. Intra-process communication is primarily single-language, though you can generally call from language X into C-language libs. Cross-process, I don't see where the assertion comes from.
Re: What Unix pipelines got right and how we can do better
#4> This cross-language composition remains remarkably rare in modern development, where we typically force everything into a single language ecosystem and its assumptions. I think IPC via HTTP, gRPC, Kafka, files, etc allows language decoupling pretty well. Intra-process communication is primarily single-language, though you can generally call from language X into C-language libs. Cross-process, I don't see where the…
Something like Kafka should be part of the core operating system. Its API has been stable for years (decade+?) now.
Re: What Unix pipelines got right and how we can do better
#5[deleted]
Re: What Unix pipelines got right and how we can do better
#6[deleted]
Re: What Unix pipelines got right and how we can do better
#7> This cross-language composition remains remarkably rare in modern development, where we typically force everything into a single language ecosystem and its assumptions. I think IPC via HTTP, gRPC, Kafka, files, etc allows language decoupling pretty well. Intra-process communication is primarily single-language, though you can generally call from language X into C-language libs. Cross-process, I don't see where the…
Wouldn't passing comms through a C ABI still be placing everything into a single language? Or am I conflating communication protocol with 'language'? My parser/combinator/interpreter senses are tingling.
Re: What Unix pipelines got right and how we can do better
#8When cat writes to stdout, it doesn't block waiting for grep to process that data.
It will certainly do that if the buffer is full.
prevents the implicit blocking
No, that's exactly the case of implicit blocking mentioned above.
Does anyone else find this article rather AI-ish? The extreme verbosity and repetitiveness, the use of dashes, and "The limitation isn't conceptual—it's syntactic" are notable artifacts.
Re: What Unix pipelines got right and how we can do better
#9> This cross-language composition remains remarkably rare in modern development, where we typically force everything into a single language ecosystem and its assumptions. I think IPC via HTTP, gRPC, Kafka, files, etc allows language decoupling pretty well. Intra-process communication is primarily single-language, though you can generally call from language X into C-language libs. Cross-process, I don't see where the…
Something like Kafka should be part of the core operating system. Its API has been stable for years (decade+?) now.
Isn't dbus pretty much that (not that it's particularly good)
Re: What Unix pipelines got right and how we can do better
#10This looks and reads like AI slop.
Also viewing Unix pipes as some special class of file descriptor because your Intro to OS professor didn't teach you anything more sophisticated than shell pipe syntax is kinda dumb.
File descriptor-based IPC has none of the restrictions discussed in this article. They're not restricted to text (and the author does point this out), they're not restricted to linear topologies, they work perfectly fine in parallel environments (I have no idea what this section is talking about), and in Unix-land processes and threads are identically "heavy" (Windows is different).