5 ms·
I too have switched from Node.js to Go in my own projects. However, Node.js (and Angular 1.x) still pay the bills. I tried to convince my previous company to wr
by iends 11y ago
I too have switched from Node.js to Go in my own projects. However, Node.js (and Angular 1.x) still pay the bills. I tried to convince my previous company to write some of their microservices in Go but it was a hard sell. In fact, I introduced a minor piece of go code that would only run once and politics exploded. I was asked to rewrite it in Node.js.
Obviously, I'm not longer with that company, but still writing Node in the day job. As you mention, packages have minor updates with breaking changes, so if you don't shrinkwrap things explode. There is a huge number of JS packages that do a lot of interesting things but the average quality leaves a lot to be desired.
I've found people get something working very quickly with Node.js but then after a year...or three it's very hard to maintain the Node.js system. Especially when the original author is no longer on the team. This is the problem TypeScript tries to solve, and TypeScript is really nice in my opinion...but its 2015 and my computer has four cores and 4 virtual cores. Languages that do not enable developers to easily take advantage of these cores are not interesting and not something I want to invest too much time in for fear they are out of favor in the next few years when cores increase even more...
Go has this solved, but people don't quite trust Google yet. For one, they seem to have a history abandoning things (or completely rewriting from scratch them like Angular 2). Go is missing a few needed features that are preventing more wide spread adoption (things like better package management), but these features are not things that the core team is prioritizing at this time.
- politician 11y ago> 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 agoCluster isn't sufficient because you cannot communicate between processes really.
- cphoover 11y agonode child process module supports IPC bidirectional communication between parent and child processes.
- MrLeap 11y agohttps://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 agoI 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.
- Touche 11y ago> Go is missing a few needed features that are preventing more wide spread adoption For me it's that Go is purely an imperative language and is not ashamed of it. That's fine, it's a good imperative language, but I don't like them, so I won't use it. I don't care how great goroutines are (or are not, I really don't know), I'm not using a non-functional language again in my career.