4 ms·

Wait what? Why are they getting rid of simplicity and model that just works. Once again Microsoft managed to put on some C# programmers on JS. The first thing t

Wait what? Why are they getting rid of simplicity and model that just works. Once again Microsoft managed to put on some C# programmers on JS. The first thing they thought was why doesn’t it support threads! Let’s build thread support and get a promotion! Edit: I would question usage of Node if everything you are doing is CPU bound. I think people started down-voting me without going through docs, I mean just read this documentation page and tell me this is right https://github.com/Microsoft/napajs/blob/master/docs/api/memory.md#memory-allocation-in-cpp-addon https://github.com/Microsoft/napajs/blob/master/docs/api/mem...

shados 9y ago
Not like they did it first. There's been a few multi threaded JS over the years, and shared memory types are part of the standard, so /shrugs
chenzhekl 9y ago
The README expained it clearly > As it evolves, we find it useful to complement Node.js in CPU-bound tasks, with the capability of executing JavaScript in multiple V8 isolates and communicating between them. Not everything MS did was evil.
- couchand 9y ago
  It's not evil it's just dumb. If your workload is CPU bound you probably shouldn't be running it in Node.js.
  - fenwick67 9y ago
    There are some cases on the threshold that this can be useful for. For example, let's say your Node application's requirements changed, and now you have to transform a set of five JSON objects to one JSON object, with some big arrays, indexing, and sorting required. The operation takes 10-100ms of cpu time, which isn't nuts, but with thousands of requests per second would normally be a catastrophe. If you can spawn a thread in this case you can save the day.
    - couchand 9y ago
      You say that 10-100ms of CPU time on the hot path of your requests isn't nuts, but we'll just have to agree to disagree about that.
      - fenwick67 9y ago
        All I meant was "transforming and merging complex documents can really take this much time", not "stopping your whole server application for this long is okay" (that would be nuts).
xigency 9y ago
That memory allocation comment does seem like the wrong way to be doing things in JavaScript.

shados 9y ago

Not like they did it first. There's been a few multi threaded JS over the years, and shared memory types are part of the standard, so /shrugs

chenzhekl 9y ago

The README expained it clearly > As it evolves, we find it useful to complement Node.js in CPU-bound tasks, with the capability of executing JavaScript in multiple V8 isolates and communicating between them. Not everything MS did was evil.

couchand 9y ago
It's not evil it's just dumb. If your workload is CPU bound you probably shouldn't be running it in Node.js.
- fenwick67 9y ago
  There are some cases on the threshold that this can be useful for. For example, let's say your Node application's requirements changed, and now you have to transform a set of five JSON objects to one JSON object, with some big arrays, indexing, and sorting required. The operation takes 10-100ms of cpu time, which isn't nuts, but with thousands of requests per second would normally be a catastrophe. If you can spawn a thread in this case you can save the day.
  - couchand 9y ago
    You say that 10-100ms of CPU time on the hot path of your requests isn't nuts, but we'll just have to agree to disagree about that.
    - fenwick67 9y ago
      All I meant was "transforming and merging complex documents can really take this much time", not "stopping your whole server application for this long is okay" (that would be nuts).

xigency 9y ago

That memory allocation comment does seem like the wrong way to be doing things in JavaScript.