Hacker News new | past | comments | ask | show | jobs | submit login

Having thought further about this, I’m going to double down on this, because it’s worse than I was even contemplating. What you describe would be as like Rayon as a propped-up, life-size cardboard cutout of a house, is like the depicted house.

Rayon’s approach lets you write code that will run in arbitrary other threads, inline and wherever you want to. That’s absolutely essential to Rayon’s API, but you can’t do that in JavaScript, at all: workers don’t execute the same code (it’s not based on forking), and interaction between workers is limited to transferable objects, or things that work with structured clone, which excludes functions.

No, you can’t get anything even vaguely like Rayon in JavaScript. You could get a feeble and hobbled imitation with untenable limitations or extra compilation step requirements (and still nasty limitations), and that’s about it.

With Rayon, you can add parallelism to existing code trivially. With JavaScript, the best you can manage, which is nowhere near as powerful or effective even then, requires that you architect your entire program differently, significantly differently in many cases, and in ways that are generally quite a bit harder to maintain.

If you wish to contest this, if you reckon I’ve overlooked something, I’m open to hearing. I’m looking for something along these lines to work:

  import { f1, f2 } from "./f.js";
  let n1 = Math.random();
  let n2 = Math.random();

  await par_iter([1, 2, 3, 4, 5])
      .map(n => f1(n + n1))
      .filter(n => f2(n + n2))
      .collect();
Where the mapping and filtering will be executed in a different worker, and collect() gives you back a Promise<Array>. The fact that f1 and f2 are defined elsewhere is deliberate—if it didn’t close over any variables, you could just stringify the function and recompile it in the worker.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: