[jchassoul]

What do you mean with proper handling of __metatable?, I'm not aware about the lack of tail call optimization that you mention please share your sources, about coroutines luerl is designed to use Erlang processes instead of coroutines that's the beauty of its implementation, you have millions of independent lua vm's running on top of independent beam processes.

Coroutines are replaced by concurrency of multiple lua processes running in parallel if you have more than one physical core on your machine all in the same battle tested Erlang VM.

(Luerl is an implementation of that fist-class C API, but for the BEAM Erlang/OTP VM)

[wahern]

I'm not exactly sure what's meant about __metatable, either. I merely quoted directly from the project website:

  https://github.com/rvirding/luerl

I assume they don't fully implement some of the metatable semantics, such as __gc on tables or operator overloading. They don't mention lacking coroutines, but the interfaces are missing from their list of supported interfaces.

Coroutines aren't just about green threading or async I/O. I often write tree walkers similar to this:

  local function walk(t)
    local function walk_next(node)
      if node then
        coroutine.yield(node, "preorder")
        walk_next(node.left)
        walk_next(node.right)
        coroutine.yield(node, "postorder")
      end
    end

    return coroutine.wrap(function ()
      walk_next(t.root)
    end)
  end

  for node, order in walk(tree) do
    ...
  end

Basically, coroutines allow you to easily reverse consumer/producer roles such that both consumer and producer can be implemented in the most natural style. That's hugely helpful when dealing with complex data structures and complex code flow, and Lua is somewhat unique in providing stackful coroutines. (Scheme is perhaps the only other language providing something at least as powerful--call/cc is even more powerful. MoarVM has stackful coroutines, but they're hidden behind Perl 6's narrow gather construct. Though, FWIW, the gather interface works well for the particular example I gave above.)

I understand that Erlang is all about message passing, which can provide similar semantics. But when programming in Lua, stackful coroutines are a huge asset. They don't require copying of messages and are basically free--creating a new coroutine has about the same cost as creating a function closure in terms of memory, and invocation costs are the same as a pcall, which means there's basically no significant performance impact. More importantly, because they're stackful you can generally call unrelated module and library routines without that code needing to be aware that they're running in a coroutine, or that a function they've been passed might yield the coroutine. (The only niggle is if library code passes a function, which itself might yield, into another coroutine. In that case the function might yield to the wrong resume point. But IME this is very rare, specifically because coroutines often obviate the need rely on callbacks as an interface for result production. Aside: Does Erlang support passing functions--and closures--to another Erlang process?)

[jchassoul]

First thanks for the quality of your response.

Yes, I notice the quote from the project github repo, just guessing I thought that it was referring to the lack of getmetatable and setmetatable functions, but I see them in the debug module, I'm no Lua expert so I don't really know how this lack of handling of __metatable feature affects the implementation.

But it's no related with the garbage collector or any type of missing feature that could make the Luerl project unusable.

About coroutines, there is no coroutines in Luerl but that's on purpose and I know it may seems counter intuitive coming from a solid Lua background.

I can't agree more with your statement about that coroutines aren't just about green threading or async I/O, I agree with you on this completely... BUT

In the BEAM ecosystem you kind of want to use processes instead, the VM it's build for handling independent isolated processes that are very small and like you said basically free at creation time and also at context switching.

The main difference between processes and coroutines is that, literally, in a multiprocessor machine a OTP release on the BEAM runs several processes concurrently in parallel. Coroutines, on the other hand, are running only one at the time on a single core and this running coroutine only suspends its execution when it explicitly requests to be suspended.