> It has become out of fashion now here

Are you sure ? I don't get that feeling from HN at all.

My impression that Rust nowadays gets more attention/upvotes than Go. But Go is still very fashionable compare to C/C++/Perl/PHP.

It's also very fashionable compared to other garbage-collected languages, which is arguably a more sensible comparison. Though one could argue that ReasonML (an Ocaml frontend with vaguely Go-ish syntax) has the better overall design.

> ReasonML (an Ocaml frontend with vaguely Go-ish syntax)

Sorry to be a pedant, but ReasonML was developed to make OCaml accessible to developers with JavaScript experience.

I think it has become out of fashion everywhere to be fair.

Not in the sense that it's a bad language, but just that it's not used much anymore.

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

(Funnily enough, it still absolutely dwarfs Rust in Google Trends, which highlights how much HN, Reddit and such are echo-chambers)

It's not only about echo-chambers. Rust is an emerging language, it's enthusiasts feel compelled to promote it to help it grow faster. Go is already well established and it's users likely feel that this language will be fine without their advocacy and more likely to stay silent. Go generated much more excitement on HN when it was not yet widely used but was growing and promising.

> it's enthusiasts feel compelled to promote it to help it grow faster.

I have no problem with language-fans promoting it and singing praise to it. I do the same with languages I happen to like.

What I do have a problem with, is evangelizing.

https://gist.github.com/graninas/22ab535d2913311e47a742c70f1...

Go is a wildly used language not sure what you mean by it's not used anyway, it's a growing and very popular language.

If you look at github stats go is still growing I don't see how you think it is its not used anymore it is the only largly used language that is still growing.

https://madnight.github.io/githut/#/pull_requests/2023/3

> Not in the sense that it's a bad language, but just that it's not used much anymore.

What are you talking about? Go is a popular language. Many of the successful software projects released in recent years are written in Go.

Google Trends is a terrible indicator.

Go has entered the "boring technology" phase, along with Java, .NET, etc. It's a safe, productive choice, with well understood upsides and downsides. There's not much to talk about... and that's ok!

"Choose Boring Technology": https://boringtechnology.club/

Is .NET still around?

I believe it’s more widely used than Go

The nice thing is that even if Go goes out of fashion, it won’t really matter. Your old Go 1.15 programs will continue to compile and work for the foreseeable future.

Isn't this true of all languages?

It's not true of the javascript ecosystem where extensive dependencies are encouraged and therefore code rot and dependency hell is a real problem.

No. Lots of frameworks ecosystems and languages break backwards compatibility all the time. Node stuff won't build a year from now even with the same lock file.

How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?

I had to compile Node 14 for Mac Arm last week, because there was no V8 for it.

It actually worked, remarkably, but I wouldn’t trust it on production.

Software is either maintained or abandoned. There’s no “done”, as much as we want it to.

Because node 18 will be EOL by then and you won't be using node 18. A Go 1.15 program will be working just fine on Go 1.41 in 10 years

> How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?

funny enough i have a simple but old app created with “create react app” that doesn’t run on anything other than node 16 and below.

It definitely won't run, but I can't tell you why. Nobody can tell you why, because everything in that ecosystem is such an immensely complicated & fragile mess that there's no telling what will break; anything's fair game. Random module pulled from NPM? Surprise build step that depends on a random combination of C libraries? People reflecting implementation details of other modules that get changed with a point release? Some world conflict somewhere evoking a blackout in libReplaceCommaWithUnderscore? I don't know, but I've spent too many days of my life debugging Node module installs on the latest version, I'm certain it won't be any easier in 10 years.

But we're not talking about installing the latest versions of your libraries. Otherwise, Go will definitely break after 10 years

Yes I know, the situations I described would apply if you used libraries with the same version 10 years from now.

In the case of the "internal dependency" one, plenty of people regularly patch stuff in NPM and keep the same version number.

Even with same lock file, modules that depend on native compilations will have problem with changing c compilers, libraries etc. Some libraries are fixed to minor version of node or node-gyp, so they won't compile with newer node. I had run into these issues both in both python and nodejs.

so, you do concede it won't work on whatever Node version is current then.

how confident are you that Node 18 will run on whatever platform you're using then? or will you be stuck on a 2023 OS image also? will all the deps be available? will the many layers of tooling still work? will they work on Node 18, or will you need to get Node 18 and Node 2033 running in the same space? etc etc.

it's already a nightmare running things a year or two apart in time in the Node world, I would guess in 2033 you'd need an entire frozen-in-amber VM image with all tooling also frozen in the same amber/.

Well, having a working Node 18 in 10 years might prove really difficult.

Recreating the whole outdated stack is often doable, but it's really time consuming and often feels more like archeology than Computer Science.

What you really want is strong backward compatibility so that Node "30" still manages to build projects from 10 years ago.

If OpenSSL pulls another one of their major api changes node 18 won’t even build anywhere outside of museums.

The parent wasn't talking about backwards compatibility. They specifically mentioned forward compatibility. Something that requires continued maintenance effort, and the more versions you roll out, the bigger the effort.

I seriously doubt Go is advertised as forward compatible or that it is such in practice. Just like any similar programming language, they depend on system interfaces, and those change, albeit at a slow rate. If all older versions of Go aren't on life support, then some will become obsolete over time.

Depends. I remember bringing a C++ code base ~15 years ago to a compilable state for a then-new g++. Wasn’t fun.

In go, code from a decade ago should just work, unless the underlying system changes too much.

Definitely not with Python. I'm currently maintaining a Python application and every minor version update for the language or even some of the frameworks involved comes as a high-stress process with numerous potential breakages.

Sure, but if you don’t keep moving to the new version, your application will continue to work for the foreseeable future, no? It wouldn’t surprise me to hear there are still some Python 2.7 holdouts.

But then you have to keep old interpreter installed and you won't benefit from improvement in new versions of the interpreter.

Your old Go code not only will work with new versions of the compiler - it probably will run faster.

I'm certainly not gonna defend Python here, but...

>But then you have to keep old interpreter installed

...thanks to `pyenv` that really is a solved problem, even outside containerized environments.

This is incorrect. Go does make breaking changes all the time. I've seen it. I've helped maintain stdlib forks because of breakages.

Still compiles is not the same thing as "works".

I've got an inherited Django project that still runs in 2.7 in a container. One day, I'll get the opportunity to rewrite it into something more suited to the task, and that'll be the end of 2.7 for me, but for now, it still does its thing.

Not at all. Python 3.7 and older cannot be even built on current Linux + GCC. Python has few important system dependencies s.a. libffi and libssl that since changed major versions and aren't compatible with the interfaces used by Python 3.7 (what happens in Python 2.7 world -- heaven only knows).

Python has no standard. There's no implementation of Python that say "we support versions X, Y and Z" of Python. It just keeps going and as the platform changes, it changes too. Old versions lose support relatively quickly. Three or four years if memory serves. If you go beyond that horizon, things start to fall apart, the further you go, the more likely it just be too hard to fix.

Compare this to C, where compilers typically support all C standards up to something moderately recent. Your C89 code would compile and work today to the extent guaranteed by the standard. Actual programs will have experienced bitrot of course. Same reason: system interface changes, but, unlike in Python, those aren't part of the language.

> Not at all. Python 3.7 and older cannot be even built on current Linux + GCC.

They can still be built in a suitable build environment (which is easy eg. with a container, and it is trivially easy to install a python 3.7 environment on a current linux, using precompiled binaries, without impacting the systems current python version, thanks to `pyenv`

    pyenv install 3.7.17

In fact I could install all the way down to 3.0.1 if I wanted (and ofc Python2 versions).

That's like saying that Mac Lisp still works because you can put soldering iron to work and resurrect on of the two remaining Lambdas in existence.

The whole point of what I said is that it doesn't work on modern systems. If you emulate old systems where it worked, then it's a nobrainer that it will work. Like, what are you even trying to prove with this?

Probably? At the expense of not being able to update too much the OS running the thing within Docker, which by itself comes with a security risk.

It's very far from true for many of languages.

Tried to gradually upgrade projects written Ruby and Python, that were not touched in 10 years. The dependencies were based on C extensions that depended on libs not existing anymore. It was even impossible to get the original version compiled, because in was dependent on a Linux distro version that doesn't exist anymore, even as docker images.

That was the hard lesson: depending on dynamically loaded libs means you need to constantly maintain the project and even if it has no visible bugs, or doesn't depend on the code having security vulnerabilities, you need to adapt it to evolve together with the libs, and that is needed even if you actually use only what's "old" in the libs. But we're not saving every megabyte of a disk space anymore like in 90s. Switching to static compilation does wonders for maintainability.

You can vendor compiled dynamically loaded libraries, too, installing them with your program if not available.

If you actually need them to be the same version used by something else on the system, that's still a peoblem, but static compilation doesn't solve that, anyway.

It is not about vendoring. Vendored dynamic libs would be depending or other libs or even on glibc that does not exist anymore. You can't recreate the dynamic libs environment.

With static you don't need that environment, only the kernel, so yes, static compilation solves the problem.

I think the only option to make sure it will run in the 10 years is to package the linking libraries and all the dependencies. Container (e.g. Docker) or Nix can solve this, provided that these technology still live in the next 10 years.

This isn’t true at all and I’ve complained about it before but the go maintainers introduced a big breaking change in the x.509 standard library that caused a lot of scrambling.

https://github.com/golang/go/issues/39568

As far as I know every other language standard library still allows CN to be used to validate the hostname when the SAN field doesn’t exist.

I disagree that TLS is a good example of a breaking change, since this is a specific library dealing with a developing and dynamic area of security. If this weren’t “broken” (you have to set one flag to get the old behavior) it would compromise PKI cert integrity by allowing deprecated fields. The fact that other languages are lagging here reflects badly on them.

As discussed in the link, CommonName has been deprecated in x.509 serverAuth certificates for decades, and all major browsers dropped support for the field (even as a fallback) years ago.

You can’t get the old behavior back with a flag as of 1.17 and if you could I wouldn’t be complaining.

Also, the reason CN is deprecated has nothing to do with security but the maximum length of the field in the spec. Chrome ignores it but every cert I’ve seen recently still includes it for legacy compatibility.

It’s not a huge dealbreaker but it forced me to go make 3rd parties regenerate their certs before I could upgrade my version of go.

It is still HN’s darling for some strange reason - I think it is the most often featured language on HN now, with Rust being only second.

Touche. Got into Wails/Go recently for a desktop app. Everything fell in place in a short time. Even the junior contractor offshore with zero experience is able to contribute! (thanks to Wails also here .. using Svelte for the frontend .. love the lightning fast builds)