Genuine question: Aren't locks a quagmire in terms of lock management? Why start there?
All of the alternatives are an even bigger quagmire.
Concurrent JavaScript: It can work
21–30 of 189 posts
Re: Concurrent JavaScript: It can work
#22JS 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 makes a proper distinction will help - I got it through Clojure, but there's certainly others like (obviously) Golang.
Re: Concurrent JavaScript: It can work
#23Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…
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?
Re: Concurrent JavaScript: It can work
#24It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.
It'd also be nice if immutable objects could just be shared instead of copied or transferred instead of the current situation where they are copied and then made mutable.
> instead of the current situation where they are copied and then made mutable.
Could you share an example? As far as I understand, Immutable JS uses something like a trie for structural sharing and avoids memory leaks.
Re: Concurrent JavaScript: It can work
#25Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…
I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.
You say fun, but what you mean is twisted mess.
Re: Concurrent JavaScript: It can work
#26JS 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.
Re: Concurrent JavaScript: It can work
#27It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.
As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints. Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.
User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation.
This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.
Re: Concurrent JavaScript: It can work
#28Earlier quoted context omitted.
I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.
You say fun, but what you mean is twisted mess.
WebKit uses threads. WebKit is not a twisted mess.
Re: Concurrent JavaScript: It can work
#29Earlier quoted context omitted.
As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints. Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.
User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation. This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.
Threads are quite successful in the real world. I think it's because the alternatives are either harder, less capable, less scalable, or even more of a footgun.
Re: Concurrent JavaScript: It can work
#30JS 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…
Events and asynchronous operations are sufficient enough for a concurrency library to be built on top of JS with minimal changes. I wouldn't consider what JS has now a reasonable concurrency model but the asynchronous event handling could serve as a starting point for a source of events that run on multiple threads.