Hacker News Reader

Comment by pram | Hacker News Reader

One big thing for me is I'm actually able to maintain stuff I wrote, for a very long time. I made a Go application in version 1.5 and I've brought it up to 1.19 with very little changes. This thing is basically 'done' and its been running for the past 7 years with zero issues, with uptime usually going into a year+

On the contrary, most the Javascript I wrote in 2015 is essentially defunct. I've developed a deep dread for starting anything new in it.

View on HN

That's more a failure of the JS ecosystem (the JS itself from 7 years ago should run exactly the same) than anything else.

Having programs run 7 years later should be the expectation, not the unexpected.

Exactly. The Javascript ecosystem is a special kind of hell. What gets me torqued is that we have an entire generation of young devs now who us old farts have to work with, and they think that the constant state of chaos and insane complexity is normal.

Node.js api surface hasn't changed much. It has more todo with frameworks people use and adding 10k dependencies, next trying to update every week to stay on the latest version.

And Node evolved much later than the other stable frameworks. I was going to use NodeJS in 2014 for a startup, but after evaluating the absolute nightmare of ways you could do async programming in JavaScript, I went with Python and Tornado, which was a callback-free, clean way of programming. It was years ahead of JavaScript in that regard, so you were ahead of the curve if you were not jailed in the JS world.

What boggled me at the time was how JS programmers had no idea that the current at the time async programming in JS was a war zone - they had no other experiences and took it as normal.

I struggled to understand what I was missing, and then I happened to find this post, and it hit pretty much every point I encountered in practice:

https://notes.ericjiang.com/posts/751

It also really helps having the ability for one Go program to use multiple versions of a package. Makes it easier when you come back to an old program with old dependencies and try to start working on it again.

I think this has more to do with the kind of software you write in JavaScript than something inherent to the language or ecosystem. Often JS is used to write web related stuff targeting the browser or other api's which have a fast pace of change. Versus a system level utility in GO that can go untouched for years on end.

I’m curious, what changes did you have to make to upgrade your go code?

Changes I remember included updating ioutil.ReadFile() to be os.ReadFile(), and some other similar depreciations.

I've noticed over time that the various linters and vet-tools have become more strict about things that they didn't detect in the past.

But I tend to write code with reasonably high levels of coverage (in the 80-100% region) so running linters and test-cases has always been part of my approach to using go.

The two major ones were a JWT package being deprecated, and then adding go mod which didn’t exist when I started. Then some smaller go vet issues.

I recently converted some Go code from 1.13 to 1.19, and the bulk of the work was replacing vendored dependencies with go modules and updating the CI/CD pipelines to properly cache said modules.

7 years - I've had that happen after 7 months! Seriously.

I definitely learned my lesson about lockfiles the hard way.

Reply on news.ycombinator.com