Hacker News Reader

> every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays,

This is the fault of all the bullshit tools that were never any good to begin with (Webpack, Babel, etc) and the Node ecosystem generally causing pain. If you had a package-lock.json you should (in theory) be able to install all of those and it should work. Of course, this relies on dependencies of dependencies actually following semantic versioning but I'm fairly sure many packages on npmjs.org do not follow semantic versioning.

Worst case scenario, you can take your TS files and put them in a newly created project. Preferably the project has a minimal number of build tools, eg, 1. Such as Vite, for example. This effectively replaces easily 5 or 6 major load bearing dependencies that used to be necessary.

Even better: Just use Deno, where it doesn't need any of this to build and run TS files!

How does lock file rely on semantic versioning? It specifies dependencies (and their dependencies) explicitly together with their exact hash

not sure how one can have a problem running something if it installs all the same dependencies and using the same scripts

True story, that's why I moved back to Maven (pom.xml) from Gradle.

As a bonus -- IDEs seem to work faster with Maven, I assume because parsing declarative pom.xml is faster than parsing and running imperative build.gradle.

Maven is better than Gradle, full stop. The only real issues with Maven, are the they keep adding features and are bringing in more scripting capabilities. Call me old, but a build system should be purely declarative as a matter of principle. Scripting just leads to someone eventually getting the idea of doing something clever, and then it becomes hell afterwards.

To put it more bluntly, Gradle only matters because of Android.

The snarky response would be that TypeScript and Go are not industrial strength languages :)

C++, C, even Fortran run just fine after decades.

Nitpick: C++ is not. Far from it. Compiled binary -- yes, but try building a barely old C++ project.

"I have no confidence that a C++ application I built last year with CMake 3.21 will build today with CMake 3.25." (c) https://wordsandbuttons.online/the_real_cpp_killers.html

The JS ecosystem’s churn is unusually bad. I wouldn’t use that as a representative example.

Tell me about it... I recently just had the fun of playing with an angular 8 project and thats 'only' 2019. Luckily in that case it was just turning on flags for node to act in an older deprecated way.

For my older projects as long as I could get the right visual studio to install and run (VMs will fix any OS compat issues) I could compile the things out of the box. As we did not go external unless we absolutely had to. These newer central repository projects are not going to end well.

What you say about Gradle's instability over a long time is so true. Even code snippets from 3 to 5 five years ago seldom work without some (more or less random) adjustments.

It's been standard practice for a very long time to use the Gradle wrapper, which fixes the Gradle version, so there really shouldn't be a problem building an old project.

Making changes to one is indeed fraught.

You're right that including the Gradle wrapper is a common good practice for years. But if you have to or want to move to a newer Gradle version than you can enjoy the full randomness of the domain specific language from Gradle itself and from a thousand plug-ins.

Exactly, if you have a very old Gradle project, it's best to use the wrapper to keep running with the version of Gradle it was written for, and make sure to use a compatible JDK to compile with (older Gradle versions won't work on new Java versions, which goes against most Java code which will almost certainly run forever even if written for Java 1.1).

Note that what OP said he found was a JAR, not code. If you found an executable built in any language, I would expect it to still be able to run 13 years later.

JAR is not executable, it's a zip-archived bytecode (basically the same code with better readability for machines, very easy to decompile back to sources, you usually only lose comments and whitespaces). Java is an interpreted language, not compiled, at least mainstream VMs.

> In the Java world, sure.

While 2011 Java certainly still runs today, 2011 Java is Java 6, which probably looks quite a bit different than the Java you'd write today. Not "different language" different, but different enough, especially with lambdas, and if you're doing anything with multithreading, or like to use functional-style streams APIs.

(I remember when generics came out in Java 5... now that did make it look a bit like a different language.)

> For another anecdote, every Golang repository I've found that predates v2 modules is nearly impossible to build, especially if it contains dependencies that link straight to Google Code instead of GitHub

Sorry, but github repo listed above is compiled Java program in jar format. JVM is doing the heavy lifting here. For golang you are talking about building the program. The equivalent of it would running exe or binary format and that definitely would work unless OS/Arch version itself disappeared.

There is ton of churn in Java ecosystem package moving from javax -> jakarta namespace, new date / time/ file libs, build tool, class file format and so on. What could most likely work is standalone jar file running in older and newer JVMs.