3 ms·

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

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.

doublepg23 1y ago
As a more sysadmin/ops focused guy it really is the killer feature. Static binaries and a more Java-esque resource profile than say Python are the cherries on top.
fuzztester 1y ago
i have read that same point said multiple times on hn about both common lisp and perl, including in a recent thread about perl.
- keyle 1y ago
  The difference is that going back to Go code you've written a few years ago, isn't nearly as bad as going back to Perl code you've written a few years ago!
  - fredrikholm 1y ago
    And having written a lot of Common Lisp, Go code is extraordinarily straight forward in a sense where every developer writes in almost the exact same style. This is not true for Common Lisp (even though it's not as bad as people make it out to be). I feel the exact same way with C versus C++, even if I was the person to write the C++.
  - fuzztester 1y ago
    Nonsense! Different strokes for different folks! I feel very leery of people who end their sentences with exclamation marks! ;)
  - fuzztester 1y ago
    as is often said on hn, the plural of anecdote is not data. and ... different strokes for different folks. qed.
- thiht 1y ago
  If someone said that about Perl, they're lying.
  - fuzztester 1y ago
    then the person on hn who said that is a liar. hey, chatgpt, quick, what's the shrug emoji? ah disremember.
josephg 1y ago
I’ve had the same experience with old rust packages. But nothing quite so old - at least not yet!
tete 1y ago
Yes, but with all the v2 in stdlib popping up we will get a lot of outdated code and a lot of "I need to know v1 and v2, because I will come across both".
- Chiron1991 1y ago
  But "outdated code" isn't inherently bad, is it? v1 code is still supported by the stdlib and it still does its job, at least until Go 2.x drops.
  - ayuhito 1y ago
    In fact, v1 code usually uses v2 code under the hood, but with different options to maintain backwards compatibility. You still get performance improvements even if you don’t switch over to the new import!
    - Grokify 1y ago
      A good example is io/ioutil. It's useful to migrate to eliminate the deprecation messages, but you don't need to do it right away.
      - majewsky 1y ago
        Also, most of this can be automated with `go install golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest && modernize -fix ./...`
zaphirplane 1y ago
In all fairness 10 years ago the deps would have been vendored in. Which side steps a whole set of problems if security, remote api version compat and features are not a major need
pjmlp 1y ago
I have worked in C++, Java and .NET codebases older than many HNer and still keep going strong.
- generichuman 1y ago
  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".
  - pjmlp 1y ago
    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.
    - generichuman 1y ago
      All fair, but: > 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.
Grokify 1y ago
This. Maintainability and refactorability are some of the major Go superpowers for me which enables getting into any code base and updating it. These are supported by features like static typing, fast compile times, etc. Of note, I've found this to be very important with AI generated code, where it's easy to grok and refactor AI code.

doublepg23 1y ago

As a more sysadmin/ops focused guy it really is the killer feature. Static binaries and a more Java-esque resource profile than say Python are the cherries on top.

fuzztester 1y ago

i have read that same point said multiple times on hn about both common lisp and perl, including in a recent thread about perl.

keyle 1y ago
The difference is that going back to Go code you've written a few years ago, isn't nearly as bad as going back to Perl code you've written a few years ago!
- fredrikholm 1y ago
  And having written a lot of Common Lisp, Go code is extraordinarily straight forward in a sense where every developer writes in almost the exact same style. This is not true for Common Lisp (even though it's not as bad as people make it out to be). I feel the exact same way with C versus C++, even if I was the person to write the C++.
- fuzztester 1y ago
  Nonsense! Different strokes for different folks! I feel very leery of people who end their sentences with exclamation marks! ;)
- fuzztester 1y ago
  as is often said on hn, the plural of anecdote is not data. and ... different strokes for different folks. qed.
thiht 1y ago
If someone said that about Perl, they're lying.
- fuzztester 1y ago
  then the person on hn who said that is a liar. hey, chatgpt, quick, what's the shrug emoji? ah disremember.

josephg 1y ago

I’ve had the same experience with old rust packages. But nothing quite so old - at least not yet!

tete 1y ago

Yes, but with all the v2 in stdlib popping up we will get a lot of outdated code and a lot of "I need to know v1 and v2, because I will come across both".

Chiron1991 1y ago
But "outdated code" isn't inherently bad, is it? v1 code is still supported by the stdlib and it still does its job, at least until Go 2.x drops.
- ayuhito 1y ago
  In fact, v1 code usually uses v2 code under the hood, but with different options to maintain backwards compatibility. You still get performance improvements even if you don’t switch over to the new import!
  - Grokify 1y ago
    A good example is io/ioutil. It's useful to migrate to eliminate the deprecation messages, but you don't need to do it right away.
    - majewsky 1y ago
      Also, most of this can be automated with `go install golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest && modernize -fix ./...`

zaphirplane 1y ago

In all fairness 10 years ago the deps would have been vendored in. Which side steps a whole set of problems if security, remote api version compat and features are not a major need

pjmlp 1y ago

I have worked in C++, Java and .NET codebases older than many HNer and still keep going strong.

generichuman 1y ago
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".
- pjmlp 1y ago
  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.
  - generichuman 1y ago
    All fair, but: > 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.

Grokify 1y ago

This. Maintainability and refactorability are some of the major Go superpowers for me which enables getting into any code base and updating it. These are supported by features like static typing, fast compile times, etc. Of note, I've found this to be very important with AI generated code, where it's easy to grok and refactor AI code.