4 ms·

> This is the problem TypeScript tries to solve. If your development methodology collapses when an original developer leaves, then the problem was that they we

> This is the problem TypeScript tries to solve. If your development methodology collapses when an original developer leaves, then the problem was that they were carrying tech debt by force of will rather than building a robust architecture. This isn't something TypeScript can solve. > Languages that do not enable developers to easily take advantage of these cores... Single-threaded runtimes, like Node, aren't intrinsically problematic, and multi-threaded solutions aren't a panacea. If you have multiple cores and a single-threaded application that you'd like to scale, then assuming the other resources are plentiful, just spawn multiple instances and pin them to those extra cores. > Go ... I like Go, and its goroutines, but working with them still requires an understanding of locking and concurrency to get it right. If the plan is to throw a random front-end developer at Go and expect magic, I think that's wildly optimistic.

troncheadle 11y ago
> If you have multiple cores and a single-threaded application that you'd like to scale, then assuming the other resources are plentiful, just spawn multiple instances and pin them to those extra cores. Not to mention, this is part of the core functionality of node. The cluster module is built in. https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html.
- iends 11y ago
  Cluster isn't sufficient because you cannot communicate between processes really.
  - cphoover 11y ago
    node child process module supports IPC bidirectional communication between parent and child processes.
  - MrLeap 11y ago
    https://www.npmjs.com/package/bobbin https://www.npmjs.com/package/bobbin my buddy wrote this npm module to make that use case easy. I've put it to work and it's pretty awesome.
tracker1 11y ago
I was going to comment on TypeScript as well... I find that it's when modules become too big, ill-named or just hard to follow that is when things get hairy. TypeScript (and Angular, while I'm at it) tend to favor larger class-style modules. It's harder with a dynamic language, and TypeScript doesn't inherently make it better. As for Angular, mentioned before, I really don't like their DI system and really favor Node's CommonJS or ES6 module references. Agreed on single-threaded runtimes... you can get around them, as far as robustness goes, you bring in the same techniques used to scale to multiple servers, you're just doing it a little sooner. I haven't done enough in Go to really comment, it looks cool, though I haven't had a use case that I really needed more performance than what I already have with the other tools available.

troncheadle 11y ago

> If you have multiple cores and a single-threaded application that you'd like to scale, then assuming the other resources are plentiful, just spawn multiple instances and pin them to those extra cores. Not to mention, this is part of the core functionality of node. The cluster module is built in. https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html.

iends 11y ago
Cluster isn't sufficient because you cannot communicate between processes really.
- cphoover 11y ago
  node child process module supports IPC bidirectional communication between parent and child processes.
- MrLeap 11y ago
  https://www.npmjs.com/package/bobbin https://www.npmjs.com/package/bobbin my buddy wrote this npm module to make that use case easy. I've put it to work and it's pretty awesome.

tracker1 11y ago

I was going to comment on TypeScript as well... I find that it's when modules become too big, ill-named or just hard to follow that is when things get hairy. TypeScript (and Angular, while I'm at it) tend to favor larger class-style modules. It's harder with a dynamic language, and TypeScript doesn't inherently make it better. As for Angular, mentioned before, I really don't like their DI system and really favor Node's CommonJS or ES6 module references. Agreed on single-threaded runtimes... you can get around them, as far as robustness goes, you bring in the same techniques used to scale to multiple servers, you're just doing it a little sooner. I haven't done enough in Go to really comment, it looks cool, though I haven't had a use case that I really needed more performance than what I already have with the other tools available.