I recently took a job. Great team, great company, interesting problem, relevant work. Everything's nodejs, but I didn't worry. How bad could it be?

While the prize for Worst Tech Used in a Professional Setting might go to InterSystems Caché ® (syntax errors will bork your entire runtime, with no undo). And it's all downhill from there.

Nodejs (javascript + libuv, aka control flow obfuscation framework) is a strong contender. I've never worked so hard to make so little code reliable, robust, deployable. And there is no Right Way to use nodejs. Everything changing all the time, every day is a do-over.

As for Swing. Remove (or ignore) it's goofy MVC and it's just like Qt. State of the art UIMS for desktop when they both came out.

After working with MUMPS for some time, getting to use Node.js has been a religious experience for me. I feel as if an incredible weight has been lifted off my shoulders.

I know the feeling. Four years ago I got done working on some truly terrible tech stacks and got to use NodeJS for the first time and it felt like a huge weight had been lifted off my shoulders too. Then I left that company and I'm doing Java now, and I realized that leaving NodeJS behind has also lifted a huge weight off my shoulders, but of a different kind.

What about Java makes you like it more, or about Node.js that made you particularly frustrated?

I wish JavaScript were statically typed, but I'm not convinced about switching to TypeScript yet. I can see other ways Node.js could be frustrating.

EPIC?

NodeJS is only sexy if you prefer weird unprotected sex.

NodeJS leverages the advanced V8 JIT and async operation in its crudest form. It's good for certain classes of tasks (a lot of I/O with simple logic around it), but not as great for the more general case.

OTOH Typescript can alleviate many of the problems of JS proper, the execution model is still a bit uncomfortable. I'd rather take Erlang /Elixir for the typical Node case.

It seems that the largest issue with your previous job is a lack of coding standards/discipline. I think that this point:

> the weakly-typed/dynamic nature of JavaScript itself which doesn't scale well to larger server-side codebases

has less to do with it.

Do you really feel that your strongly-typed Java job would be so great if all of the other poor practices of your previous job were in place?

Having had extensive experience (many years) using each of statically and dynamically typed languages professionally, it's been my finding that, all other things being equal, statically typed languages are better at yielding high quality large codebases. There are entire classes of errors that a competent IDE will detect for you instantly in a statically typed language that you might not catch until compilation/testing/even production in a dynamically typed language. It's also simply easier to write more powerful tooling for refactoring in statically typed languages, so large-scale refactorings inevitably end up being easier. And it's no accident that companies (including mine) are increasingly adopting TypeScript, which brings some of the advantages of statically typed languages to JavaScript.

I have to say that, just looking at the language itself, C# is probably my favorite, but the surrounding stack including Windows makes me prefer Java on Linux to it, especially Java 8 because of its support for lambdas.

Although, it's also been my experience that the other factors mentioned have more of a role than the attributes of the languages involved themselves.

I beg to differ.

Have your ever tried to maintain a large js project? It gets harder the bigger the codebase gets.

Is there an alternate universe where this is not true? Where things get simpler while they get more complex?

He's saying that it gets proportionally more harder to manage a large codebase in JS than it does in statically typed languages like Java. This has been my experience as well.

Erlang, for one example.

Read about AXD 301 development.

That's absolutely been my experience too.

FYI, Java 8 is now in beta for App Engine Standard: https://cloud.google.com/appengine/docs/standard/java/quicks...

Oh, I'm well aware. Unfortunately it's been in beta for awhile now, and keeps slipping deadlines. We can't use it until it's out of beta because we run an important production service with external contractual obligations and we need guaranteed support for things working. The "no SLA" policy on the beta makes it a non-starter for us.

I've always found it weird when people say stuff like this. Clearly your last team was bad, you even said the developers were less skilled, and time constraints were problems and yet you manage to blame tooling.

There's absolutely great test and CI tooling for JavaScript. The fact that you and your team didn't spend enough time to develop an expertise with them isn't the languages fault.

I clearly blamed a lot of things in addition to tooling in my post. My overall point, which I don't think you quite got, was that language choice doesn't matter so much compared to all those variables, and that I'm much happier and more productive now working in a less "sexy" language because of those other differences.

I think the only comment you can make is that, ceteris paribus, newer tech stacks indicate some awareness of newer ideas (who include agile / devops tooling). Old tech might, but also might not.

I'm more inclined to think that Palantir's problems are inherent to the enterprise revenue equation.

"Features and code quality that aren't contractually mandated" = profit

The more things you can put in that category, the more profit...

Newer tech stacks might also indicate chasing the newest/hottest thing without regards to long-term sustainability of the platform, however. You don't always want to be bleeding edge, as bleeding edge can easily be dead five years from now, whereas if you stick with a "boring" mainstream technology it'll still be around in five years.

True. But the enterprise shops I've seen tend to make the "not modern enough" error 20x more often than the "too modern" error.

Good engineers will naturally gravitate towards good tools. Therefore away from bad ones. Node.js is not a good tool. Therefore the quality of engineers using it will be poor and get worse over time. The same is true of MongoDB.

Good engineers will naturally gravitate towards good tools. Therefore away from bad ones. A hammer is not a good tool. Therefore the quality of engineers using it will be poor and get worse over time. The same is true of shovels.

Your example isn't making sense to me. Hammers and shovels are excellent tools. There's a reason they're some of the most commonly possessed and used tools world-wide.

Your example isn't making sense to me. Nodejs and MongoDB are excellent tools. There's a reason they're some of the most commonly possessed and used tools world-wide.

We could continue this all day. I can tell you're very inexperienced in saying specifically that a tool is bad. You'll learn as you grow in experience that even if you don't like a tool, that it can be useful for lots of other people in lots of circumstances. It may seem unbelievable to you, but when you get some more notches on your belt, you'll understand what I'm saying. Good luck!