Earlier quoted context omitted.
And what about server developers using Node.js?
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...
Concurrent JavaScript: It can work
51–60 of 189 posts
Re: Concurrent JavaScript: It can work
#52Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.
The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memory to avoid the wasteful marshalling step.
Re: Concurrent JavaScript: It can work
#53Earlier quoted context omitted.
And what about server developers using Node.js?
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"!
Re: Concurrent JavaScript: It can work
#54Earlier quoted context omitted.
That is parallelism, not concurrency. Concurrency: two functions can run one after the other while they are non blocking for the callers (e.g. hyperthreading). Parallelism: two functions can run at the same time (e.g. multiple processors).
Your definition of concurrency is not correct. Concurrency usually implies that the work is chopped up into very small interleavable bits. A while function call with a loop of unbounded length being the default granule of interleaving is definitely not part of the definition of concurrency. The term "concurrency" subsumes both event loop style concurrency and two-cores-running-code-at-the-same time concurrency.
Yes, it is. The JavaScript event loop is a very lazy scheduler than does no preemption. It's a very primitive concurrency model. It's up to the users of the language to break their tasks down into sufficiently small components or yield to allow for interleaving of work.
Re: Concurrent JavaScript: It can work
#55Earlier quoted context omitted.
Is there any limitation or reason for not implementing WASM on nodejs?
Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java. When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using i…
So true!
Lots of people actually like using JS. I think it makes sense to understand what features can be added to this language.
Re: Concurrent JavaScript: It can work
#56Re: Concurrent JavaScript: It can work
#57Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each...
For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement!
Threads for the server-side? I don't care.
Re: Concurrent JavaScript: It can work
#58Earlier quoted context omitted.
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.
Surprisingly, that's not what concurrency model means. What you describe is parallelism.
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.
Re: Concurrent JavaScript: It can work
#59Earlier quoted context omitted.
Surprisingly, that's not what concurrency model means. What you describe is parallelism.
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.
Re: Concurrent JavaScript: It can work
#60Earlier quoted context omitted.
I share your concerns about the usefulness and implementation of this concurrency strategy. In my opinion, concurrency isn't necessary for JS. If web developers want high-performance, concurrent computing, they should push for adding concurrency to WASM. I doubt concurrency could hurt JS, but I just don't see any reason for it that concurrent WASM doesn't fulfill.
And what about server developers using Node.js?
I thought the point of Node.js was that threads were too complicated and rendered unnecessary by asynchronous event loops that do message passing between processes. Are the Node people finally giving up on this trope?