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.
Not to mention, this is part of the core functionality of node. The cluster module is built in. https://nodejs.org/api/cluster.html.
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.
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.
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.