Earlier quoted context omitted.
Right! It can't be the all of the cool features are done in wasm, which doesn't even have a GC yet.
WASM is farther along than concurrent JS though...
That's true. But most of the web is written in JS, not wasm.
Concurrent JavaScript: It can work
61–70 of 189 posts
Re: Concurrent JavaScript: It can work
#62Earlier quoted context omitted.
And what about server developers using Node.js?
Is there any limitation or reason for not implementing WASM on nodejs?
No. In fact, AFAIK it's already implemented on Node, behind the --expose-wasm flag: http://thecodebarbarian.com/getting-started-with-webassembly...
Re: Concurrent JavaScript: It can work
#63Earlier quoted context omitted.
And what about server developers using Node.js?
Is there any limitation or reason for not implementing WASM on nodejs?
There may or may not be, but that doesn't address that Node.js was created to specifically avoid a threaded concurrency model in the first place.
Re: Concurrent JavaScript: It can work
#64JavaScript should just copy the Tcl threading model.
Re: Concurrent JavaScript: It can work
#65Earlier quoted context omitted.
Concurrency generally means preemption. Event loops have no preemption. It's not correct to use parallelism to mean preemption, as you seem to be doing.
In CS, parallelism is simultaneity. Two things are parallel if they occur at the same time. Concurrency is design, which may allow for parallelism. And may allow for preemption. Preemptive or cooperative concurrency is a design decision, both are concurrency.
"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption.
I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency.
But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time. He's implying that if you run things at the same time then it's called parallelism. That's just not true. It's still called concurrency, even though it could also be called parallelism in the right circumstances.
I think it's best to understand this terminology this way:
Concurrency: the phenomenon of two things happening at the same time, or being made to appear that way.
Parallelism: the study of how to make things run to completion in less time by using multiple CPUs or computers.
Re: Concurrent JavaScript: It can work
#66Earlier quoted context omitted.
Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too. Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.
JS already supports immutable objects, by using Object.freeze().
That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).
Re: Concurrent JavaScript: It can work
#67Forgive the ignorance, but why do we need threads when we already have the event loop? And, as a follow-up, why introduce a new concurrency model that's based on Java instead of, say, creating a concurrent "event pool" where execution order isn't guaranteed and callbacks are executed with maximum concurrency (edit: to clarify, I mean maximum parallelism)?
Event loops are great for handling work that can be handed off occasionally to worker threads (like how Node works with libuv), but are awful when doing consistent CPU-bound work, such as with games, 2D/3D visualizations, finance, and the like. SharedArrayBuffer is a nice primitive that allows multiple Threads (or WebWorkers) to work on data in parallel. The additional primitives they're proposing offer quite a bit o…
If you're that concerned about performance, though, aren't doing things like `.asyncJoin()` just going to eat up any potential gains by 1) wrapping the result in a Promise and 2) throwing the Promise back into the event/microtask queue? It seems like the transport would quickly become the bottleneck.
I'm also struggling to understand what tier of performance you're aiming for, since you're hoping to boost performance by using a Thread in JS when, in node, you can already code expensive computation in C++ and expose a binding back to JS (which to me makes more sense in the context of game design since that's basically what most already do with Lua--this would just be in reverse).
Re: Concurrent JavaScript: It can work
#68Earlier quoted context omitted.
In CS, parallelism is simultaneity. Two things are parallel if they occur at the same time. Concurrency is design, which may allow for parallelism. And may allow for preemption. Preemptive or cooperative concurrency is a design decision, both are concurrency.
"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption. I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency. But it's…
I'll generally agree with your definitions for concurrency and parallelism. Our parallelism definitions were essentially the same.
But what you say about coldtea is not a fair interpretation of their post. millstone said this:
The event loop doesn't allow you to do a computation
concurrently with handling user events, so it's not at
all a proper concurrency model.
Parallelism, and coldtea's comment does not exclude this, is a special case of concurrency. It is the case where a program's components execute simultaneously. Whereas, generally, concurrency in CS does not require simultaneous action (as you state in your definition).
Re: Concurrent JavaScript: It can work
#69Forgive the ignorance, but why do we need threads when we already have the event loop? And, as a follow-up, why introduce a new concurrency model that's based on Java instead of, say, creating a concurrent "event pool" where execution order isn't guaranteed and callbacks are executed with maximum concurrency (edit: to clarify, I mean maximum parallelism)?
I think eventloop implements concurrency only but thread will implement concurrency with parallelism.
I edited my comment to clarify (hopefully). What I was thinking was that a theoretical "task pool" would execute callbacks with maximum parallelism.
Re: Concurrent JavaScript: It can work
#70Earlier quoted context omitted.
Depends on what you're doing, but if you just want to take advantage of multiple cores you can already accomplish that with `cluster`.
I remember when people used to say "you don't need threads, just use fork"!
What do they say now, out of curiosity?