[gordonguthrie]

If you fancy developing your own transpile-to-js language I have written up the actual process in some detail: http://luvv.ie/toolchain.html

Erlang (via Erlang Core) is actually quite a sweet example. Erlang (which is small) is transformed into Erlang Core (a language targetted at machines not humans) which has a very small set of primitives (21 in all). That Language is turned into a compact AST which is then transpiled to a Javascript AST and transformed back up to Javascript using standard JS syntax tools.

I have also written up the thinking about how to make an OTP-ish Erlang dialect in the browser work as part of Erlang/OTP's 'span of control' in the server-side cluster: http://luvv.ie/mission.html

[lucaspiller]

Wow, I thought at first this was just making an Erlang-style syntax compile to JS, but this is much more than that. Very nice!

Does it run on BeamJS? :D

[gordonguthrie]

No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser.

So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code like:

    call_user("[e-mail]", modal, {"Did you brush your teeth?", {"yes", "no"}})

and the 'modal' process in my browser gets some message like:

    {msg, {"Did you brush your teeth?", {"yes", "no"})

It pops a yes/no dialog box and send "yes" back to the calling process on the server.

[nickik]

On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them.

Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back.

I know more about CSP and not Actors but there you use many of the same tricks (I think). And I really don't see why one would constrain the browser side.

See for example this project: http://www.infoq.com/presentations/pedestal-clojure

[gordonguthrie]

I don't agree.

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

I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written.

Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is low:

    * a menu bar
    * a toolbar
    * a tabs bar
    * a grid
    * the cell input overlay
    * 5 or 6 dialog boxes

The grid is endless scrolling set of spreadsheet cells and behind the scenes it is pre-built panels of 20x20 which are 'next-but-one' assembled on the fly for smooth scrolling.

Even if you break the grid out for max concurrency - you only add another 8 or 9 concurrent data models.

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

With regard to restart and supervision I really do mean the Operational Supervision that Erlang/OTP supervision does in terms of handling errors. 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. Page refresh covers most of what you might ever need.

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.

[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.