Good practice

[erlang@REDACTED]

> I suppose that the situation is different with C, because it is a rather
> low-level systems programming language ("glorified assembler" as some
> would have it), and programmers need to be able to bend the language
> into whichever shape they want it in order to make the code fast enough
> or small enough for their particular purposes and hardware. Since
> everybody needs to bend the rules in their own special way, there can be
> no real consensus as to what the compiler should warn you about. In a
> language like Erlang, the range of possible tricks that can go horribly
> wrong is just so much smaller.

Actually, here I'd like to make something of a philosophical point...

Yes, C is debased assembler (IMHO, I think that C's syntax is messy, and
a decently written piece of assembler is frequently more readable than
most C, but I realise that I'm in the minority here so I won't press the 
point) but there's quite another way of regarding erlang in this context.

I think erlang is a systems language.  Erlang is, in fact, a pretty darned
low level systems language.   Also, again IMHO, a very elegant one.

It just happens to be a systems language for a virtual machine, along with
a networking language for a network of such virtual machines, in a virtualised
networking environment.

The corollary is of course that one could perfectly well write a useful, 
meaningful OS in Erlang, for using the BEAM virtual system as one's application
platform.  Efficient?  Not particularly, in the big picture.  Desirable?
 .... just possibly.  I think it could well be desirable.

As an example of something along those lines, I would offer Inferno.

The tricky part would be deciding what you wanted in such an OS, and how to
secure it, given Erlang's rather open-ended design.