jchassoul

just use bspwm!

Denite resolves Unite's problems. https://github.com/Shougo/denite.nvim

happy vim8 + Denite user here!, Telescope seems great as well can't wait to try it out eventually with nvim!

The future of RTS is the acknowledgement of Brood War as our new modern digital chess.

I love bspwm!

It's all about messaging.

quoting: Soon we will have chips with thousands of cores with high-bandwidth interconnect. Such chips will power the next generation of Intelligent Applications.

Since message passing between Actors is the standard method to communicate, languages like Erlang are highly relevant.

Syntactic sugar causes cancer of the semicolon!

It is NOT, is cool that you love Clojure, Scheme or Common Lisp but LFE is not a re-implementation of any of those things nor envy any of the features on them.

LFE is a clean, beautiful an proper Lisp for the complete BEAM ecosystem.

If anything on the BEAM ecosystem interest you I highlight recommend you check out LFE! (=

There are no symbols! you have lots of little processes with lots of connections between them and you change the strengths of the connections and that's how we learn things.

Both are awesome papers, I found this very interesting:

"In 1975 Gerald J. Sussman and Guy L. Steele Jr. began experimenting with some interpreters in an attempt to understand the consequences of the Actor model of computation. This led to the publication during 1976–1978 of a series of papers describing a new dialect of Lisp called Scheme. Scheme was one of the first languages to have taken seriously the implications of lexical scoping and first-class functions. Namely, Scheme correctly treated closures—a closure is a function along with the local environment within which it was defined."

I heart Richard Gabriel once saying that the goal of Scheme was implement Carl Hewitt's Actor model but they discover closures instead, got hyped and forget about the original mission.

Later history repeat itself twice, Robert Virding a true Lisp Hacker implement LFE his own LISP for the BEAM ecosystem and accomplish the original Scheme goal and probably without even know or care much about it, in the similar way that once Mike Williams, Joe Armstrong and him build Erlang the best implementation (in my opinion) that we got from the Actor model without know nothing about it existence at the time of the development of Erlang.

Indeed the SIP over WebRTC open source stack is a thing of beauty!

Thanks professor, looking forward to join your keynote at code mesh.

https://codesync.global/speaker/carl-hewitt/

Do you want to abolish the protagonist role of the channel abstraction like in CSP based languages and certain message brokers?

We can't have issues with channels if we're all actors and don't impedance mismatch the mixture when building our systems.

Bigger than that is a concurrent model of computation!

How this view on channels relate with information theory? can we think of them as an actor and its capacity a property of the physical modeling represented by that actor: floppy disk, cd, dvd, lan, wan, river, lake, ocean?

That is wrong, Actor systems have a property called "Unbounded nondeterminism" nondeterministic TM have only bounded nondeterminism.

https://en.wikipedia.org/wiki/Unbounded_nondeterminism

The statement is true, Actor systems can handle uncertainty in ways that Turing Machines can not.

Turing machines are not very good handling uncertainty? the key pond is on physics ? yada, yada? I thought this was 101 already!

and yet it moves

Hewitt work so relevant today, I found interesting that the Lisp Scheme was a failed attempt to implement this model of computation, ORGs, the scientific community metaphor, Planner, Inconsistency robustness, he even have a paper with David Marr from the same year of Actors "Video Ergo Scio" related today with the idea of inverse 3D graphics of capsules.

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.

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.

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)

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.