Thanks! I came here to ask the "How do I Erlang?" question. Erlang has been on my radar for a long time but I've never taken the time to dig in. 85% of my code output is obscure protocol stacks in Python+Twisted, the other 15% is real-time embedded C over an RTOS. Even if I can't use Erlang in production, I'm sure I'd find food for thought in the concepts.
> Even if I can't use Erlang in production, I'm sure I'd find food for thought in the concepts.
Oh boy are you going to be in for a treat. The concept for no loop construct other than recursion and recursive thinking was worth it for the little time I dabble in Erlang.
FWIW, the class for it was the first class to sell out for the upcoming https://elixirconf.com/.
Here's a great presentation by Garth Hitchens on Nerves https://www.youtube.com/watch?v=O39ipRsXv3Y (he uses it in production at his company, http://www.rosepoint.com/, which builds sort of vertical-market marine navigation hardware). He mentions some performance stats as well.
Nerves boots into the ErlangVM, but runs on a buildroot Linux. This makes it possible to run on a wide variety of hardware, but with the associated baggage.
GRiSP uses RTEMS[0] as its base which should make its performance more predictable.
The tutorials and core library documentation are really very clean.. You should be able to go pretty far just by installing a package and starting through the tutorials, although OP also has some links to more docs too
There's a lot of overlap with Spawned Shelter, and I haven't touched it in a few months, but https://gist.github.com/macintux/6349828 is a list of free Erlang resources I try to maintain.
I was not aware about Spawned Shelter and your list of resources wow, I need to check the first be as soon as I click on your link I needed to write you some thanks message! awesome job with the list.
the only different with the others is that since they implement existent languages following the spec, which means that some things don't map directly to the VM semantics and pay a little overhead, for example lua is a mutable language and the BEAM is immutable, this means that mutability is implemented by passing an immutable environment and mutating it.
This doesn't mean you can't use them, but they are mostly used as extension languages and for scripting than for complete projects.
The original Lua has also designed to be used as extension language to be embedded and give the base systems scripting super-powers! The beauty of the Luerl Lua implementation is that is really a full implementation of the Lua language is not something inspired by Lua or some kind of handicap version of the language. I agree of course with your statement about a little overhead, but it is a real true Lua.
Luerl lacks tail call optimization, coroutines, and "proper handling of __metatable". Without those three things Lua is just a simpler JavaScript and not that interesting.
(Lua also has a first-class C API, but we'll let that slide.)
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)
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?)
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.
> there's a online course by Simon Thompson from the University of Kent that started 2 days ago, you may be able to join:
First time doing a MOOC - is this considered a good quality one? I find his ordering of course material not always logical, and he omits useful info in places (discovered through Googling)
http://spawnedshelter.com/
there's a online course by Simon Thompson from the University of Kent that started 2 days ago, you may be able to join:
https://www.futurelearn.com/courses/functional-programming-e...
if you like the ideas but want to try something different there are alternative languages that run on the Erlang VM:
* Elixir with a ruby-like syntax: https://elixir-lang.org/
* LFE (Lisp Flavoured Erlang): http://lfe.io/
* Efene with a python-like syntax: http://efene.org/
and one in development but already looking really interesting: Alpaca, an ML inspired language: https://github.com/alpaca-lang/alpaca