3 ms·

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

7thaccount 7y ago
When you say "they", I assume you mean "browsers"? Sorry for the dumb question. I know precious little about web programming and concurrency.
- Izkata 7y ago
  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.
  - 7thaccount 7y ago
    Interesting and thanks for the explanation. Does it have to be single threaded?
    - ProfHewitt 7y ago
      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.
      - 7thaccount 7y ago
        Thanks! I assume that was for a reason? Or just oversight?
bitwalker 7y ago
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.
- ProfHewitt 7y ago
  Workers can be made to work in a browser, but communication can be awkward and slow.
  - monoideism 7y ago
    > 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).
  - bitwalker 7y ago
    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.

Izkata 7y ago
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.
- 7thaccount 7y ago
  Interesting and thanks for the explanation. Does it have to be single threaded?
  - ProfHewitt 7y ago
    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.
    - 7thaccount 7y ago
      Thanks! I assume that was for a reason? Or just oversight?

bitwalker 7y ago

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.

ProfHewitt 7y ago
Workers can be made to work in a browser, but communication can be awkward and slow.
- monoideism 7y ago
  > 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).
- bitwalker 7y ago
  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.