3 ms·

I'm sorry but I couldn't help not commenting on this. That comment on the README is disingenuous at best, truly a shame as it now casts for me a different image

I'm sorry but I couldn't help not commenting on this. That comment on the README is disingenuous at best, truly a shame as it now casts for me a different image of what I initially thought to be a cool project worth supporting. node.js was not (of course!) planned to play nice with 'metacall' so I do not see why they were expecting otherwise. I have spent thousands of hours working with and contributing to libuv, V8 and node itself and I can tell you from experience that they are examples of extremely good software engineering and practice. I suggest the authors of this lib (if they´re reading this) to actually spend some time studying the code infrastructure that makes node.js possible instead of just bashing out at it out of mere ignorance. You would be surprised.

pcr910303 7y ago
Well, (I’m not the project maintainer but) I don’t think the mention of ‘bad design’ in the README is ignorant; It is not what I would call a good design at best to one that tries to embed nodejs inside an app. Everyone has different views on what is ‘good’ and what is ‘bad’; the internals can be (and is) beautiful but the external APIs for interacting with nodejs has grown organically(not really designed). There are discussions for a better N-API for embedding in the nodejs issue tracker[1]. The author looks like he has studied enough internals to implement nodejs inside the library; he even (helpfully) explained how metacall has embedded nodejs successfully and improvements available in the nodejs part. [2][3][4] I wouldn’t call that bashing out at it out of mere ignorance. [0]: https://github.com/nodejs/node/issues/23265#issuecomment-427069095 https://github.com/nodejs/node/issues/23265#issuecomment-427... [1]: https://github.com/nodejs/node/issues/23265 https://github.com/nodejs/node/issues/23265 [2]: https://github.com/nodejs/node/issues/23265#issuecomment-452690239 https://github.com/nodejs/node/issues/23265#issuecomment-452... [3]: https://github.com/nodejs/node/issues/23265#issuecomment-496878712 https://github.com/nodejs/node/issues/23265#issuecomment-496... [4]: https://github.com/nodejs/node/issues/23265#issuecomment-496918901 https://github.com/nodejs/node/issues/23265#issuecomment-496...
- forwhatisworth 7y ago
  I am sorry but you do not understand what we are talking about. Do not worry, we have all been there at some point and it is on my best interest to explain to you what's going on :) The sentence "the bad design of node.js does not allow to manage the thread pool from outside" implies two things initially, 1. that there is a thread pool, which is part of the architecture of node.js and 2. that this thread pool cannot be managed by an external program. On the same sentence, they then try to use these concepts combined as an argument to "the bad design of node.js". What I wanted to convey is that this statement -> "the bad design of node.js" is a huge hyperbole and it is blatantly wrong, since it is actually a very good "real-world" example of good software design and practices. Anyone that has spent at least a couple days interacting with the developer community behind node.js and sister project can attest their level of knowledge, talent and commitment. Also, just bashing on a project that you're building on top of is an extremely tasteless display of vulgarity ...

pcr910303 7y ago

Well, (I’m not the project maintainer but) I don’t think the mention of ‘bad design’ in the README is ignorant; It is not what I would call a good design at best to one that tries to embed nodejs inside an app. Everyone has different views on what is ‘good’ and what is ‘bad’; the internals can be (and is) beautiful but the external APIs for interacting with nodejs has grown organically(not really designed). There are discussions for a better N-API for embedding in the nodejs issue tracker[1]. The author looks like he has studied enough internals to implement nodejs inside the library; he even (helpfully) explained how metacall has embedded nodejs successfully and improvements available in the nodejs part. [2][3][4] I wouldn’t call that bashing out at it out of mere ignorance. [0]: https://github.com/nodejs/node/issues/23265#issuecomment-427069095 https://github.com/nodejs/node/issues/23265#issuecomment-427... [1]: https://github.com/nodejs/node/issues/23265 https://github.com/nodejs/node/issues/23265 [2]: https://github.com/nodejs/node/issues/23265#issuecomment-452690239 https://github.com/nodejs/node/issues/23265#issuecomment-452... [3]: https://github.com/nodejs/node/issues/23265#issuecomment-496878712 https://github.com/nodejs/node/issues/23265#issuecomment-496... [4]: https://github.com/nodejs/node/issues/23265#issuecomment-496918901 https://github.com/nodejs/node/issues/23265#issuecomment-496...

forwhatisworth 7y ago
I am sorry but you do not understand what we are talking about. Do not worry, we have all been there at some point and it is on my best interest to explain to you what's going on :) The sentence "the bad design of node.js does not allow to manage the thread pool from outside" implies two things initially, 1. that there is a thread pool, which is part of the architecture of node.js and 2. that this thread pool cannot be managed by an external program. On the same sentence, they then try to use these concepts combined as an argument to "the bad design of node.js". What I wanted to convey is that this statement -> "the bad design of node.js" is a huge hyperbole and it is blatantly wrong, since it is actually a very good "real-world" example of good software design and practices. Anyone that has spent at least a couple days interacting with the developer community behind node.js and sister project can attest their level of knowledge, talent and commitment. Also, just bashing on a project that you're building on top of is an extremely tasteless display of vulgarity ...