> EDIT: Don't know how FP and the pipe operator alone make things Unix-y. Erlang/Elixir definitely play in their own league and I don't recall ESR's rules off the top of my head to make a detailed comparison right now.
Forgive my constant stream of edits. It started off as a short reply but I kept coming back feeling "It's a programming language discussion, ugh. I really should elaborate."
Lots of people contributed to the Unix philosophy, but ESR's contributions alone are 17 rules and people only tend to talk about 1-2 of them so that's why I referred to them as "oft-butchered."
I would say FP satisfies the Unix streams ideal due to how you transform data through functions and pass this data to other functions. Elixir's pipe macro just makes this read more naturally. The modularity comes from the Erlang concept of "applications" and Elixir takes this further with umbrella applications.
I've written quite a bit of Elixir and I can't say that I've ever really needed to interop with the kernel or POSIX APIs at all. One of the reasons I use Elixir is because BEAM handles all of the crap I used to write in other languages (Async I/O APIs) to make them "fast." Heck, a lot of people even think Erlang got microservices right nearly 30 years ago!
I did write some Go long before I ever wrote any Elixir so my experience is similar to OP. Go has a great niche in infrastructure tooling due to compiling to a binary, having a nice stdlib for tedious server-related things (TLS, crypto, etc). and supporting cross-compilation. That said, I'll never write servers or business application logic in Go again. Elixir is just the better tool for the job there.
It's not pedantic as it's the point the OP is trying to make; not UNIX'y means it's not playing well with the environment, he's not talking about philosophy.
Which is the point, when he's says it's not UNIX'y, he means it doesn't play well with the environment; he's not talking about philosophy, he's talking about the implementation so saying it's philosophically the same is missing the point.
My point is that the original article was saying its "UNIX'y" in philosophy. So the commenter you're discussing is the one who is missing the point, in my opinion. It's a moot point anyway, we're being needlessly pedantic here.
Forgive my constant stream of edits. It started off as a short reply but I kept coming back feeling "It's a programming language discussion, ugh. I really should elaborate."
Lots of people contributed to the Unix philosophy, but ESR's contributions alone are 17 rules and people only tend to talk about 1-2 of them so that's why I referred to them as "oft-butchered."
I would say FP satisfies the Unix streams ideal due to how you transform data through functions and pass this data to other functions. Elixir's pipe macro just makes this read more naturally. The modularity comes from the Erlang concept of "applications" and Elixir takes this further with umbrella applications.
I've written quite a bit of Elixir and I can't say that I've ever really needed to interop with the kernel or POSIX APIs at all. One of the reasons I use Elixir is because BEAM handles all of the crap I used to write in other languages (Async I/O APIs) to make them "fast." Heck, a lot of people even think Erlang got microservices right nearly 30 years ago!
I did write some Go long before I ever wrote any Elixir so my experience is similar to OP. Go has a great niche in infrastructure tooling due to compiling to a binary, having a nice stdlib for tedious server-related things (TLS, crypto, etc). and supporting cross-compilation. That said, I'll never write servers or business application logic in Go again. Elixir is just the better tool for the job there.