Hacker News new | ask | show | jobs
by chriswarbo 4094 days ago
It's a nice line of thought, but I think there's a lot of existing work that's should be investigated. Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?".

Erlang is mentioned as an example, since its VM certainly offers many features we'd like from an OS. Maybe comparisons to Smalltalk, LISP machines and even regular UNIX shells should be offered.

It's likely that all this has been done before, and I'm tempted to think that its major problems would stem from having too much power in the config language. For example, I'd imagine you could do this with SysV init's runlevels and shell scripts, but it would be pretty horrible. What would make the language du jour any less horrible?

Also related is, of course, the Nix ecosystem: Nix package management, NixOS configuration management, NixOps provisioning, DisNix distributed services, etc.

1 comments

> Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?".

In all honesty, I'm not sure you read the article. The entire point is the idea to deploy tiny chunks of code, independently, in any language.

> The entire point is the idea to deploy tiny chunks of code, independently, in any language.

What does "tiny chunk of code" mean? According to the article:

> Literally, a simple interface that did one (or very few) things well.

Hmm, sounds like the UNIX philosophy to me. Operating on code in a language-agnostic way? Sounds like scripting to me...

> What if instead you could deploy classes.

Classes are a language feature, so this looks to be asking for an alternative scripting language.

> What if your operating system was in a way an API to deploy services (it is!) > but the size of the code deployed was so small that it would in turn be hard > to make mistakes.

That's the point of UNIX: do one thing and do it well; compose the pieces using scripts.

Of course, UNIX is not perfect, it's just an obvious comparison. I mentioned a few others above. That's what I got from the article, after squinting through the jargon ("deploy" instead of execute, "services" instead of processes, etc.)