[nickik]

> The mission is to be a dom-scripting language http://luvv.ie/mission.html

If that is your goal then I dont want to clame that you have not achived it. This looks quite good for many things, my point is however that I mayself would not want to restrict myself this way.

In the future we be able to directly go from one browser to another, we might query or get messages from tons of diffrent servers, the OS might send us events and so on. More and more, the browser becomes a application deployment target.

> 9 - 29 Web Worker processes for a page sounds liveable with.

The question is not really if I can live with, the question is if I want to.

It just seamst to me that, when light weight concurrency is good on the server we should also use it in the browser. Seams to me this would help with the idea of using simular programming models on both ends.

> I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option.

I can imagen many things. Lets say a you inplment some game or simulation where you have threads of executuion doing some calculation and maybe rendering themselfs on the screen. Now it would be nice to have some sort of fail-over system that might monitor all these and can potentially restart them, maybe get some information from the server or internal data store, maybe it is required to shut down all the other threads and restart them as well.

Maybe you stop getting messages from the server, and you have to restart the server or go and search for another server. Maybe you have to get a message from the server, informing you that it is shuting down and internal storage should be used.

I can image lots of things, and I dont know why I should restrict myself by design.

> I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.

CSP is what Go implments (or core.async library in clojure).

[gordonguthrie]

The concurrency issue is not mine to fix. Javascript provides native concurrency by Web Worker which (compared to Erlang processes is a very heavy-weight, no-shared code environment. LuvvieScript is just realising that (given those prior contraints) an OTP-ish Erlang dom-script language can be created.

The alternative (a light-weight process language) involves building a scheduler in Javascript - which is a very different beast to a transpiler with a message-consuming/emitting runtime built with existing JS libraries.

To be brutally honest, the later is beyond my competancies.

[nickik]

Fortunately somebody has already made a implementation and you could try to use it as a base layer for your own system. I don't how easy it is to interface with Clojures core.async, but I guess its probably possible.

Here somebody has already did a mini-actor implementation: https://github.com/halgari/clojure-conj-2013-core.async-exam...

It might be a interesting exercise to implement Erlang Actors on top of this and then expose it to a JS interface. This might be a good idea in general and not just for your OTP-ish langauge.

Also I want to say that I came a across as very negative, I just wanted to say that LuvvieScript is quite cool and useful. WebWorkers are a much better primitive for Erlang style stuff because its shard nothing even on the server (I think). In really the browser should really provide a API for either shard memory threads or proper Erlang/Go Style threads.

[gordonguthrie]

Yeah, Erlang is proper shared nothing. With modern multicore phones I think low-number concurrency in Web Workers should be enough.

My problem with using Clojure libraries is that I don't really know JS very well :( I really am all Erlang...