The tragedy of running an old Node project

> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...

What ecosystem are you comparing to?

Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues.

Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.

Even Rust, which is usually great and has modern packaging and built-in dependency management, often has issues building old projects due to breaking changes to the compiler.

All this is to try to say that I don't think this is some problem unique to JS at all - but rather a side effect of complex interconnected systems that change often.

A big reason Docker and containers in general became so popular was because it makes this problem a lot less difficult by bundling much of the environment into the container, and Docker is very much agnostic to the language and ecosystem running inside it.

Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages. Python has a very rich standard library. You can do a lot with libc, if you had a c++ Qt project then it would provide you with basically everything you could ever need.

> Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages

That's not the only reason. :)

Horrible syntax full of inconsistencies, bolted on type system with TypeScript helps but will always be bolted on, quirks everywhere, as if `null` was not bad enough they also have `undefined`, I can go on.

I simply avoid it for anything but small enhancements scripts on otherwise static HTML pages.

It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me. And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV.

> It's okay for you to have the opinions you do

Likewise.

> I know [...] C, C++, C#, Python, Go, various flavors of Assembly

That's good. But these are all languages that either lack strong typing and or are themselves rather quirky.

Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __init__, etc.).

Also C# and Go still have implicit nulls all over the place. Their designs show ignorance for modern language design. Sum-types, explicit null, immutability, sound type systems -- all lacking in all langs you mention.

So what languages do have these IMHO "Game changers"? OCaml/ReScript/ReasonML, Haskell, Elm, Rust, Gleam, F#, Scala, Kotlin, ...

Those languages really showed _me_ something important: how it could be better.

There is another group of languages that also sits on a unique place in the solution space: the LISPs (incl. Racket, Schemes and Clojure). I found it very worth while to learn to program with them as well.

In the last few years C# did away with implicit nulls. Nullable and non-nullable object references are disambiguated with T? and T. There are multiple keywords and expressions to further make it nice to work with these. You would be correct to note that there are "nullability holes" in certain edge-case scenarios, particularly around JSON serialization. But other than that it's a pretty smooth sailing.

If you do use C#, you may also want to add <WarningsAsErrors>nullable</WarningsAsErrors> to .csproj too.

I know it's a bit like Kotlin. I heard though that C#'s move still has some std lib bits that are nullable.