6 ms·

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

by pram 4y ago

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.

philosopher1234 4y ago
I’m curious, what changes did you have to make to upgrade your go code?
- pram 4y ago
  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.
- dharmab 4y ago
  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.
- stevekemp 4y ago
  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.
Andys 4y ago
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.
DangitBobby 4y ago
I definitely learned my lesson about lockfiles the hard way.
shakow 4y ago
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.
- papito 4y ago
  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.
  - brnewd 4y ago
    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.
    - papito 4y ago
      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 https://notes.ericjiang.com/posts/751
sgt 4y ago
7 years - I've had that happen after 7 months! Seriously.
brnewd 4y ago
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.

by pram 4y ago

philosopher1234 4y ago

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

pram 4y ago
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.
dharmab 4y ago
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.
stevekemp 4y ago
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.

Andys 4y ago

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.

DangitBobby 4y ago

I definitely learned my lesson about lockfiles the hard way.

shakow 4y ago

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.

papito 4y ago
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.
- brnewd 4y ago
  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.
  - papito 4y ago
    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 https://notes.ericjiang.com/posts/751

sgt 4y ago

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

brnewd 4y ago

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.