🚀 go-pugleaf

"Marc E. Fiuczynski" <mef@cs.washington.edu> writes:
| I just started to read some papers on ALEF, which is the PLAN9
| C-like programming language.  Any users of this language care to
| share their anecdotes.

Sure, I'll have a go.

ALEF is a concurrent language.  With respect to that feature, one
thing that it does right that M3, Ada, Java, and others do wrong is
that it has language constructs for expressing both operating system
supported concurrency (a "proc") and runtime system supported
concurrency (a "task").  procs are created by calling
rfork(RFMEM|RFPROC), which creates a new process sharing address space
with the parent.  [Under Unix you can get the same effect by using
fork() and mmap(), though rfork() is very much faster, like everything
else in Plan 9 compared with Unix.]  Tasks are coroutines: they
reschedule cooperatively, they will block the process they are in if
you execute a system call.  These two primatives are simple to
understand, and let you express what you really want when writing
concurrent programs.

This well conceived separation of functionality also has the benefit
of enormously simplifying the runtime system.  procs are simple: they
map directly to real OS processes.  tasks are simple: they are
coroutines that require no cooperation from the operating system.  For
comparison, look at pthreads, Java, M3, and see how complex their
"thread" implementation is.  The problem is that they want to act as
if their threads were os supported processes, so that system calls
won't block, for example, but they also want to be lightweight and
inexpensive like coroutines.  This fundamental conflict of interest
results in unsatisfyingly complex and fragile runtime systems.
Pragmatically, ALEF does much better.