generator functions exist, which is not even needed in this case, you could just pass a promise as an argument
Go-like channels in 10 lines of JavaScript
11–20 of 65 posts
Re: Go-like channels in 10 lines of JavaScript
#12[flagged]
Re: Go-like channels in 10 lines of JavaScript
#13But 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 pa…
Or use a language that supports multi threading in some sensible manner..
Re: Go-like channels in 10 lines of JavaScript
#14generator functions exist, which is not even needed in this case, you could just pass a promise as an argument
The main trick on display here is that you can store a reference to the `resolve` method of a promise that normally would have to be called within the promise definition itself.
Of course, you don't need a channel abstraction to do that. To me, channels are the most intuitive and self-contained way to solve the problem, so I wanted to use that model of concurrency in JS.
Re: Go-like channels in 10 lines of JavaScript
#15This 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.
Why don't you like async/await?
8 years ago I wrote a npm package that turned code that looks like this:
tcp.send("syn", function(syn) {
console.log("received", syn);
tcp.send("syn-ack", function(synack) {
console.log("received", synack);
tcp.send("ack", function(ack) {
console.log("received", ack);
});
});
});
seq([tcp, console], function(tcp, console) {
var syn = {}; var synack = {}; var ack = {};
tcp.send("syn", this(syn));
console.log("received %s", syn);
tcp.send("syn-ack", this(synack));
console.log("received %s", synack);
tcp.send("ack", this(ack));
console.log("received %s", ack);
});
How would you prefer to write asynchronous code?
How does Loom handle resource starvation problem? If a thread puts a while (true) {} in there somewhere, can that thread be preempted away from that kernel thread?
Re: Go-like channels in 10 lines of JavaScript
#16But 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 pa…
[deleted]
Re: Go-like channels in 10 lines of JavaScript
#17But 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 pa…
> But there is no concurrency in Javascript!
Yes and no.
At the “ECMAScript”-level, JavaScript has no built-in concurrency, but every serious JavaScript implementation enables proper concurrency via the async primitives and the internal scheduling.
Put simply, if you know how to write async code properly, your JavaScript code can achieve high concurrency!
Re: Go-like channels in 10 lines of JavaScript
#18But 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 pa…
JavaScript does have concurrency! Try the following:
Promise.all([new Promise(t => setTimeout(t, 3000)), new Promise(t => setTimeout(t, 3000))]).then(() => console.log('done'))
It just happened to be executed one by one but the VM handles the switching for us.
What you're talking about is parallelism, which JavaScript indeed does lack and you'd use cluster or workers for that. That's when things happen at the same time, outsourced to different cores. This is what JavaScript cannot do (yet?).
Re: Go-like channels in 10 lines of JavaScript
#19There are a ton of other approaches that would work with NodeJS that would be even more simple though right?
The easiest or first that comes to mind is just have your function that does whatever functionality is required for creating this assetsManifest (whatever both compileServer and compileBrowser depend on). Lets call this createAssetsManifest. Then you have your 2 compile async functions but you just don't await on them and let them run without using the await keyword.
const manifest = await createAssetsManifest();
compileBrowser(manifest);
compileServer(manifest);
Not referring to the author or anyone in particular. Just a thought since these keywords might used so often by engineers new to Node that they might not have ever learned what came before?
Re: Go-like channels in 10 lines of JavaScript
#20This 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.
Hear, hear
The worst part of Rust, too, is that async/await is tacked on— and it’s just a bad primitive to start with.
I have many more thoughts on this that I might like to blog about, but it can be improved by having a async runtime of some kind (we don’t call malloc a runtime, but it is— and you need something similar for ergonomic async) — to wit, the de facto pseudo-answer for this in Rust is tokio (which should just be promoted to the stdlib, at this point; the vast majority of async code depends on it’s particularities).
It’s also causes quote-unquote “function coloring problems” left, right, and center — which is also avoidable. Just for kicks, consider a language with “call-async”/“yield”. Tie that in with a runtime and this whole topic becomes much, much, cleaner. Async at the callsite! (This is the blog I’ve been meaning to write)