Wed Sep 24 09:22:32 CEST 2003
From: "Joe Armstrong"
> IMHO the *essential* features are:
> - light weight concurrency
> - inter-process isolation
> - transparent distribution
> - remote detection of errors
> All the rest (HOFs, structs, List comprehensions, type systems,
> bit syntax, macros, includes, ... bla bla) are "nice to have"
> but NOT essential.
your mail, and some other discussions here, made me think of something that for
me is rather revolutionary. If it happens to be something either impossible or
obvious, I apologize for taking your time.
Why not take this idea of separating the concerns to its limit? At the bottom
there would be two parts: a "process engine" that should only know about
spawning, killing and scheduling processes, and also about the communication
between them. The other part would handle the interface with the outside world:
memory management, IO, file systems, hardware. Possibly it isn't possible to
implement the two efficiently without strong dependency, but the goal would be
to have them as separate as possible.
Now what would processes do? Run, of course. This would be inside a virtual
machine (*) - but after the former separation, it seems to me that this VM could
be (in principle) almost any VM. Even more, different processes could even run
on different kind of VMs. Of course the most efficient would probably be to use
the same one. But wouldn't it be cool to be able to run Java and .Net as Erlang
processes (**) and in the long run convert all of those to Erlang? ;-)
After describing this architecture, it begins to look like a OS kernel (I think)
and I am pleased to notice that :-) In the future maybe this will be *the* OS...
(*) In a general sense, even machine code can be seen as bytecode for a VM.
(**) Not unmodified programs from today, but code that targets this OS.
Is this only an utopia, or could there be something that will work in real life?
There is a lot of OS research that targets this area, so it's possible this is
already done or at least been looked at. What do you think?
More information about the erlang-questions