Comment by triska | Hacker News Reader

Comment by triska | Hacker News Reader

Parent Full thread

One very interesting development in this direction is Web Prolog by Torbjörn Lager:

https://github.com/Web-Prolog/swi-web-prolog/raw/master/book...

Quoting from the introduction:

"In particular, we pick the features that make Erlang into an actor programming language, and on top of these we define the concept of a pengine – a programming abstraction in the form of a special kind of actor which closely mirrors the behaviour of a Prolog top-level."

And quoting from Section 1.3 of the current draft:

"Is the actor programming model compatible with the logic programming model, and does the combination of the two models make sense? Yes, we will try to show that the actor programming model of Web Prolog is able to co-exist harmoniously with its logic programming model, and that both models are usable in the same program, with actors used for modelling the reactive, deterministic interfaces to the user and other external entities, and with the non-deterministic component behaving as an actor, encapsulating the non-determinism."

Chapter 3 cites your work directly:

"Actors, as specified in (Hewitt et al., 1973), involve entities that have their own mailbox."

Unfortunately, Actors cannot be efficiently implemented in browsers because of the way that they implement concurrency.

I’m not sure I agree. For example, nothing about Erlang makes it unsuitable for a browser environment, it can handle running single threaded, or distributed across workers, where each worker runs its own scheduler. The only limitation is interacting with the DOM, since that must all happen in the main thread, but it is still possible to treat that the same way other blocking I/O is dealt with in the scheduler.

I’m actually working on a compiler/runtime for Erlang for WebAssembly, so I’m maybe more familiar than most with how it works in practice.

Workers can be made to work in a browser, but communication can be awkward and slow.

> Workers can be made to work in a browser, but communication can be awkward and slow.

True, but with the SharedMemory browser API, things are looking up (but not yet implemented in all major browsers).

Apologies, Professor, I missed your reply!

SharedArrayBuffer makes communication between schedulers essentially equivalent to non-browser environments, but support for it is still iffy at best due to Spectre. Luckily, that is a temporary problem, not a fundamental issue (SharedArrayBuffer being disabled that is, not Spectre).

In a single-threaded setting, there isn't any significant overhead that I'm aware of between a browser and non-browser environment, aside from any overhead potentially incurred by executing on the WebAssembly VM rather than directly on the host machine. Of course, running single-threaded is less than ideal for other reasons.

When you say "they", I assume you mean "browsers"? Sorry for the dumb question. I know precious little about web programming and concurrency.

Except for webworkers (relatively new, I've not used them and know little about them), javascript in browsers is single-threaded. Even asynchronous things like ajax requests can only handle the result once the thread finishes doing whatever it was doing.

Interesting and thanks for the explanation. Does it have to be single threaded?

JavaScript in browsers was decreed by the standards committee to be single-threaded forever. Consequently, JavaScript is entirely lacking in concurrency constructs, e.g., implementing a region of mutual exclusion inside a JavaScript program.

Thanks! I assume that was for a reason? Or just oversight?

Reply on news.ycombinator.com