Re: Is Lua the next big thing?

[Sam Roberts <sroberts@...>]

On Tue, Mar 13, 2007 at 09:49:40AM -0300, Roberto Ierusalimschy wrote:
> > Complete isolated interpreters are a problem of its own and simply
> > kills most of the advances of threading at all.
> 
> Erlang does not support shared memory; its processes communicate via
> messages. That does not seem to kill its "threading power". (Erlang
> has been used quite successfuly in several light real-time industrial
> applications with high level of parallelism.)

A few points here:

- erlang does have threading problems - threads are one of the only
  portable ways on unixy systems to get non-blocking file operations,
  and to take advantage of multi-core systems. Coincidentally, I did a
  bunch of googling last week to see how they dealt with this, and the
  answer seemed to be that there was an add-on IO library that created a
  thread pool, spawning off OS worker threads that are allowed to block.
  AFAICT, erlang predates multi-core machines, and just doesn't take
  advantage of them. However, since Erlang is inherently a distributed
  system, and many apps are designed to work across multiple machines,
  they will also work with multiple erlang instances on the same
  machine, so there is a way to take advantage of multi-core/CPU
  systems.

- erlang allows data structures (+code/objects, I think) to be
  transparently serialized into messages.  So, even though it enforces
  separation of states, it also allows easy transport of data between
  states. The lua implementation I've seen of this don't involve sending
  code, and usually allow only a few primitive types to be marshalled.

So, Erlang has some of the limitation of lua with respect to
state-sharing and threading, and those limitations are its strengths.
But, the are strengths in Erlang because of other language features it
has. Lua has the limitations, but not the features.

Of course, I'm still using lua. :-) Lua's strength (and weakness)
remains its flexibility and neutrality. You "could" implement an
erlang-like system in lua, possibly, with fairly wizard-like effort, but
you can also implement lots of other kinds of systems, from the lightest
touch of config file input, to doing almost everything in lua.


> > If i have to serialize all data, send it as a byte stream into another
> > interpreter and deserialize there, i can also live with serparate
> > processes. I'm not sure if you can migrate a complete object structure
> > from one interpreter instance to another in LUA (i don't believe you
> > can).
> 
> When we use threads without shared memory, frequently we have to think
> differently from the way we think with shared memory. For instance,
> instead of sending data all around (through serialized streams), it is
> common to have one process for each data (an object? an abstract data
> type?), so that what flows around are "messages" (in the OO sense) to
> manipulate that data. You never migrate a complete object structure
> from one interpreter instance to another. You simply send a process
> reference from one instance to another.

Lua is scheme-minimalist in many ways, but one thing the lisps have
usually provided (always?) is data marshalling. You can write and
read recursive data structures natively. I know, there are dozens of
implementations of this out there for lua... but maybe thats a bad
thing.

Cheers,
Sam