1. 15
  1.  

  2. 3

    It’s early in its life and I’m not sure what I think about its prospects or even its raison d’être.

    On the latter, there are better languages and runtimes to handle concurrency. Many, in fact. One of JavaScript’s appeals, to me, was its singlethreadedness—just one less thing to think about, one constraint to keep things simpler. (Especially with all the foot-guns JS gives you!) But if you’re coding JS all over the place, it’s also simpler to just stay in that space when you need to parallelize something. Generally, the better performance of those other languages is dwarfed by the I/O waiting.

    On the former, all of the npm modules out there were built without any awareness of multiple threads and most Node projects are a morass of dependencies (including all of mine, of course). Switching to this runtime is fraught with difficult-to-discern bugs in your code as well as in the code you didn’t write. That’s going to hamper uptake, as will having to trust that Microsoft is going to embrace this project and keep developing on it.

    1. 4

      I think that’s a little bit of FUD there, though–from a cursory look at the API, they just seem to be creating isolated V8 contexts (effectively) and adding a bit of glue to help with farming out things to worker pools. The API isn’t completely compatible yet, but it seems like memory sharing bugs and concerns aren’t quite valid.

      1. 1

        What’s a little bit of FUD? The fears about dependency incompatibility making debugging more difficult or that Microsoft might abandon the project at some point?

        1. 2

          Dependency incompatibility is plausibly overstated.

          I would expect switching to multiple V8s running inside one process to not be a big problem for pure JS code. async Node JS doesn’t usually want to do anything which depends on process wide mutable state (like changing cwd then changing it back) because that will usually be race-ey even with a single threaded implementation (because some other code could muck with it while the first one is waiting for a callback).

          I wouldn’t expect this to make your existing code share data structures between threads at all, except for code that is explicitly using postMessage or using SharedArrayBuffer (whenever that becomes a thing).

          Libraries that extend Node in C or C++ may care. It’s 2017 though, libraries should be threadsafe! Don’t write bindings if they aren’t. :/

          1. 1

            On the former, all of the npm modules out there were built without any awareness of multiple threads and most Node projects are a morass of dependencies (including all of mine, of course). Switching to this runtime is fraught with difficult-to-discern bugs in your code as well as in the code you didn’t write.

            My reading here was that you were implying that single-threaded code running in a multi-threaded environment might explode and that there were difficult bugs that plagued this runtime.

            The former I don’t think is actually a problem because of the memory model Node and this use, and the latter I assume is FUD unless you have links.

            1. 2

              That’s a fair point, in that I just made an assertion. And even that isn’t based on any tangible work with the project.

              If there are no side effects of inter-thread communication and sharing in the dependencies, then, sure, there will be no problems. If there are, then it’s likely that it’ll happen in the myriad of packages that your project includes or the dependency tree from those packages. In my experience with multithreading (not JS), it can get very gnarly to figure out if it’s your code, the dependencies, or the runtime itself.

              That’s what I meant. I’ll accept that it’s a “little bit” of FUD because it doesn’t arise from actual experience. (And JS’s natural asynchronous model probably negates my real experiences with multithreading.)

      2. 1

        Created a golang version of the estimate-pi example here: https://gist.github.com/wcharczuk/aa006f37774c5bc1f9ff8881727c75ad

        Overall, it’s shows promise but I can’t get it to do more than 2 workers without crashing. Also golang is faster (as you’d expect)