3 ms·
What's old is new again -- I'm pretty sure QNX could do this in the 1990s. QNX had a really cool way of doing inter-process communication over the LAN that wor
by ISL 7y ago
What's old is new again -- I'm pretty sure QNX could do this in the 1990s.
QNX had a really cool way of doing inter-process communication over the LAN that worked as if it were local. Used it in my first lab job in 2001. You might not find it on the web, though. The API references were all (thick!) dead trees.
Edit: Looks like QNX4 couldn't fork over the LAN. It had a separate "spawn()" call that could operate across nodes.
https://www.qnx.com/developers/docs/qnx_4.25_docs/qnx4/sysarch/proc.html https://www.qnx.com/developers/docs/qnx_4.25_docs/qnx4/sysar...
- checker659 7y ago> I'm pretty sure QNX could do this in the 1990s. Plan 9, SmallTalk
- imglorp 7y agoErlang of course. All spawns and messages can be local or remote.
- masklinn 7y agoIndeed, weird to only find it that low as a sub-comment: spawn(Node, Module, Function, Args) -> pid() Returns the process identifier (pid) of a new process started by the application of Module:Function to Args on Node. If Node does not exist, a useless pid is returned. Otherwise works like spawn/3.
- russellbeattie 7y agoAny time I see something about remote processes, I immediately think, "Erlang could probably do this." I think Erlang would have been the programming language of the 21st century... If only the syntax wasn't like line noise and a printer error code had a baby, and raised it to think like Lisp.
- sosodev 7y agoElixir is pretty cool. You get all the power of Erlang wrapped up in a much more developer friendly language.
- Proven 7y ago+1. I was going to mention this (less eloquently)
- femto113 7y agoEven further back this echoes some of the goals of MIT's Project Athena started in 1980s.