Re: C++ religious war (was: llua Higher-level C API for Lua)

[Andrew Starks <andrew.starks@...>]

On Fri, Mar 21, 2014 at 1:55 PM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> Having that kind of straightforward concurrency in Lua would be a
> fantastic thing.

I think this  is the next "64 bit integer" for Lua.

1: The rise of the "app store" created a compelling need to maintain
code bases in ObjectiveC, Java and .Net. This is difficult to do for a
2 dollar app that may not sell and so we have Corona and many others.

2: The mobile space has many asynchronous requirements, in addition to
the multiple cores that (i think) all devices now have.

I think fantastic concurrency in Lua is pretty close to "present", as
long as you stick to the "one state per thread". Maybe the language
lacks some keywords (await?), but coroutines seem to cover my bases.

I come back to my question from long ago: How could Lua evolve to
further support this use case?

The use case might be stated: "A language that sits on top of a
native/system language *for the purpose of replacing the application
code that would normally be written in that language.*"

Of course much improvement could be achieved through library code. In
order for library code to have  a significant impact, I believe that
the libraries have to look like Lua: very small and simple. There
aren't enough people that want to embed Lua and are also willing to
package a large opaque library in order to achieve something that they
see as basic.

Some individual libraries that I think would help:

timer: (sleep, nano-timer)
A simple library that accesses the native os's high performance timers.

poll/select
A "poll" or "select" library that used the native environment's
best-equivelent. I know that this is hard, but if one is trying to
achieve the ability to catch file / socket i/o, there should be a
library that other library authors use. LuaSocket does this (as well
as sleep), and even makes it easy to integrate with other libraries.
But it is not insignificant that I need to load LuaSocket to use it
and it only supports select on Windows. IO Completion ports would be
much better.

thread
llthreads2, but fixed. This library doesn't need to support every
possible conception of threading. What llthreads2 does is probably
enough, IMHO

xmove, but for transfer between lua_states

I know that in the Luaverse, there are tools that do all of these
things. My point of emphasis is that individual libraries are better
than fully baked solutions and some well done, simple tools might make
a big impact.

Not that Lua isn't already successful in that space.

-Andrew