Go-like channels in 10 lines of JavaScript
pedrocattori.dev
Go-like channels in 10 lines of JavaScript
1–10 of 65 posts
Re: Go-like channels in 10 lines of JavaScript
#2AFAICT after the first write, the inner promise is resolved and will return the same value it was resolved with even if subsequent writes are made. This is totally different than Go-like channels which can receive multiple writes, often handling buffering them until they are consumed.
Re: Go-like channels in 10 lines of JavaScript
#3This is interesting.
Correct me if I don't understand is this only concurrent with respect to IO is that right? If you run a IO operation or network call (fetch api) in those promises, those shall be concurrent with the CPU execution of your Javascript?
I think async/await is a great primitive. I've been working on implementing a async/await switch statement based state machine* in Java for multithreaded async/await. I want to handle the scheduling of multiple promises eagerly, so when you call async task1(); async task2(); async task3(); it schedules them all independently on different threads.
* if you've used protothreads in C, this is what it is similar to.
To do interleaved concurrency in Javascript, you could do the same pattern (switch based state machine) or do my concurrent looping approach. You break up your long CPU task into lots of microtasks and switch between them concurrently with a switch statement. You switch between tasks with a scheduler loop, so you do a bit of work on each task independently. It's concurrent but not parallel.
here's my writeup of concurrent loops which takes arbitrarily nested loops and turns them into an iterator https://github.com/samsquire/ideas4#133-concurrent-loops---l...
here's my java state machine of multithreaded async/await in Java, that could be adapted to Javascript except it wouldn't be parallel.
https://github.com/samsquire/multiversion-concurrency-contro...
Re: Go-like channels in 10 lines of JavaScript
#4AFAICT after the first write, the inner promise is resolved and will return the same value it was resolved with even if subsequent writes are made. This is totally different than Go-like channels which can receive multiple writes, often handling buffering them until they are consumed.
That's correct. The last three paragraphs of the article cover this and include links to libraries that have "full" channel implementations.
Re: Go-like channels in 10 lines of JavaScript
#5This is interesting. Correct me if I don't understand is this only concurrent with respect to IO is that right? If you run a IO operation or network call (fetch api) in those promises, those shall be concurrent with the CPU execution of your Javascript? I think async/await is a great primitive. I've been working on implementing a async/await switch statement based state machine* in Java for multithreaded async/await.…
go channels aren't threads but means to pass messages between running goroutines (also not threads, but are boxed like one). Go has first-class async built-in using `go func(){ return long_running_thing(); }()` to spawn a coroutine that executes long_running_thing(). The problem with go is you can either lock with a mutex (bad for google scale) or you can do like Erlang do and pass messages. Ok, but how? Channels. Go has support for a special keyword called `chan` that when used with `make` it will allocate a channel of a defined type. Essentially a FIFO queue to grok it in your head. Where you pass in your object of defined type, and the other side reads it in a blocking select to broker the message. Select in Go can block on a number of channels so it's easy to listen for events in this way. SIGTERM, Messages, TCP Data, etc.
Re: Go-like channels in 10 lines of JavaScript
#6But there is no concurrency in Javascript! So even after this exercise, the running function still has to finish before the next can start. This will only create actual concurrency when each of the actors are themselves doing pretty IO heavy things where they wait for external processes to finish. Otherwise, if you actually have compute heavy processes that should run in parallel you should use the node.js cluster package or worker threads, both of which come with IPC built in already.
Re: Go-like channels in 10 lines of JavaScript
#7I don’t understand why there is a bang operator in the last code sample on line 18. Is it a typo?
Re: Go-like channels in 10 lines of JavaScript
#8I don’t understand why there is a bang operator in the last code sample on line 18. Is it a typo?
Its a Typescript-ism for asserting that the value is not `undefined`. So you're telling the typechecker to trust you on this one
Re: Go-like channels in 10 lines of JavaScript
#9This is interesting. Correct me if I don't understand is this only concurrent with respect to IO is that right? If you run a IO operation or network call (fetch api) in those promises, those shall be concurrent with the CPU execution of your Javascript? I think async/await is a great primitive. I've been working on implementing a async/await switch statement based state machine* in Java for multithreaded async/await.…
I actually think async/await is a terrible primitive, and if you’re on Java, the approach of Project Loom is vastly superior (i.e. threads can be cheap so everything can just be synchronous again). I’ve no problem with library-level concepts like promises and futures but it feels very short sighted to put it into an actual language, it’s just noise.