Hacker News Reader

Comment by kaba0 | Hacker News Reader

It would help Unix’s case if the glue between the parts wouldn’t be byte streams and some very crude int result code, signals, etc.

A monolith can be just as composable if not more, with a much “stronger glue” in the form of language-mandated guarantees. Also, sometimes doing multiple things well is the better direction — IPC is additional complexity and essential complexity can’t be decomposed.

View on HN

Unix has gotten pretty far using just text and return codes. But there's no need to be dogmatic about it I guess, it could be nice to pass objects around, rather than text, like Powershell does. Although, their implementation seems quite verbose.

I think to really use something like that, I'd want a well-defined ordering for the fields and the ability to also do something like

variable.1

in addition to

variable.someLongFieldName

This could result in less than obvious scripts, but a shell language also needs to be compact, for interactive usage.

In Unix space we use text, almost exclusively. This byte stream thing is a windows/java bs thing.

When contributing to uutils (the coreutils written in Rust), one of the bigger pain points with cross platform support is the way that in Unix, everything, including arguments, is just bytes, while on Windows, arguments are semi-opaque text strings. E.g., the -t option in sort, join, etc. takes an arbitrary byte (other than null, which is supported via \0), so you can sort, join, etc. binary inputs. However, the -t option will not let you use a multi-byte character, even valid Unicode characters like é, which, if Unix actually used text for everything, you would expect it to. Meanwhile, on Windows, uutils still doesn't support non-ASCII byte values for -t, because Windows doesn't provide a way to represent those.

Reply on news.ycombinator.com