Okay, C++ is believable, but can you really build a Java / .NET project that was not touched for 20+ years with no changes to the code or the build process (while also using the latest version of the SDKs)?
I imagine you can _make_ a project compile with some amount of effort (thinking maybe a week at most) but they wouldn't be exactly "unzip the old archive and execute ./build.bat".
Yes, because Ant exists since 2000, Maven exists since 2004, and MSBuild since 2003.
Before it was a common procedure to have central package management, we used to store libraries (jars and dlls), on source control directly in some libs folder.
Afterwards, even with central package management, enterprise software when done right, is not calling the Internet in every build, rahter there are internal repositories that are curated by legal and IT, and only those packages are allowed to be used in projects.
So the tooling is naturally around after 20+ years, no one is doing YOLO project management when playing with customer's money.
As for the "...latest version of the SDKs..", that is moving the goal posts, there is no mention of it on,
> Go is the only language where I've come back to a nontrivial source code after 10 years of letting it sit and have had zero problems building and running. That alone, for me, more than makes up for its idiosyncrasies.
Ant and Maven have existed for a long time, but for me they didn't prevent Java (and other JVM language) projects from suffering significant bitrot in the build process.
For example, I worked on a project that just stopped being able to be built with Maven one day, with no changes to the JVM version, any of the dependencies, or the Maven version itself. After a while I gave up trying to figure it out, because the same project was able to be built with Gradle!
Older Scala projects were a pain in the ass to build because the Typesafe repositories stopped accepting plain HTTP connections, requiring obscure configuration changes to sbt. I've never had to deal with things like that in the world of Go.
> As for the "...latest version of the SDKs..", that is moving the goal posts, there is no mention of it on [...]
I thought it was implied since tooling & library breakages over the years happen and sometimes you can't just get the old SDK to run on the latest Windows / macOS. If the languages and Ant/Maven are backwards compatible to that extent, that's actually pretty good!
I had to deal with moving a .NET Framework 4.7 project to .NET Standard 2.0 and it wasn't effortless (although upgrading to each new .NET release after that has been pretty simple so far). We took a couple of weeks even though we had minimal dependencies since we're careful about that stuff.
I imagine you can _make_ a project compile with some amount of effort (thinking maybe a week at most) but they wouldn't be exactly "unzip the old archive and execute ./build.bat".