Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrent JavaScript: It can work

webkit.org

Post reply on HN
Print view View original

41–50 of 189 posts

Re: Concurrent JavaScript: It can work

#41

Post by rmrfrmrf »

stupidcar wrote: post #23
pitaj wrote: post #20

Earlier 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?

Depends on what you're doing, but if you just want to take advantage of multiple cores you can already accomplish that with `cluster`.

Re: Concurrent JavaScript: It can work

#42

Post by millstone »

preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

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.

Re: Concurrent JavaScript: It can work

#43

Post by skybrian »

pizlonator wrote: post #26
preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

Even loop is not concurrency. Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.

Creating async tasks that can run concurrently and deliver progress via events is a concurrency model.

Re: Concurrent JavaScript: It can work

#44

Post by STRML »

pitaj wrote: post #16
STRML wrote: post #7

Earlier quoted context omitted.

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…

I think that kind of stuff it much more relevant in the land of WebAssembly. It certainly makes sense there, but in normal JS, I doubt the usefulness.

It depends. It could be very useful for React/React Native, for one.

Re: Concurrent JavaScript: It can work

#45

Post by enoah_netzach »

pizlonator wrote: post #33
christophilus wrote: post #31

Earlier quoted context omitted.

You can build concurrency on the event-loop, though, which is what the OP was probably referring to.

Not quite. Consider a component in your code that does this: for (let blah of things) foo(blah); In an event loop, if things has a lot of stuff in it, this can block the event loop. Other things in the event loop won't be able to run until this completes. With threads, this just works.

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

Re: Concurrent JavaScript: It can work

#46

Post by Jtsummers »

millstone wrote: post #42
preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

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.

It's a proper concurrency model, it's just not an efficient one when it comes to execution.

Concurrency has (at least) two components: design concurrency, execution concurrency. The event loop mechanism in JavaScript allows you to do effective concurrent design. It does not provide for concurrent execution. This is the primary distinction in academic CS between concurrency and parallelism.

Re: Concurrent JavaScript: It can work

#47

Post by coldtea »

pizlonator wrote: post #28
richardwhiuk wrote: post #25

Earlier quoted context omitted.

You say fun, but what you mean is twisted mess.

WebKit uses threads. WebKit is not a twisted mess.

WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.

Re: Concurrent JavaScript: It can work

#48

Post by stupidcar »

fermuch wrote: post #36
stupidcar wrote: post #23

Earlier quoted context omitted.

And what about server developers using Node.js?

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 it at all. Fine, if that's their opinion, but they should come right out and say it.

Re: Concurrent JavaScript: It can work

#49

Post by coldtea »

millstone wrote: post #42
preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

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.

Re: Concurrent JavaScript: It can work

#50

Post by pizlonator »

enoah_netzach wrote: post #45
pizlonator wrote: post #33

Earlier quoted context omitted.

Not quite. Consider a component in your code that does this: for (let blah of things) foo(blah); In an event loop, if things has a lot of stuff in it, this can block the event loop. Other things in the event loop won't be able to run until this completes. With threads, this just works.

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.

Post reply on HN