1. 41
  1. 42

    I think not rushing features just because they could is starting to become my favorite feature of Go.

    I have a great distate for a new major breaking release being required every few months because something went given the time to be thought through or tested in real life.

    Then one quickly ends up with deprecated features, code, documentation, etc. and most importantly the amount of maintainance for everyone rises, often leading to switching to the “next big thing” being the more approachable way.

    1. 28

      Go is like the Debian Stable of languages, and I quite enjoy that at this point in my career.

      1. 14

        Whilst I agree that the language has remained super stable over the years, let’s also note that the tooling around the language hasn’t. I personally had to migrate from GOPATH to vendoring dependencies, then to Godeps and now finally to Go modules.

        Two stories about working with Go:

        1. We run Jenkins on AWS and around year 2017 fetching Go dependencies would fail once in a while. It turned out that Google was blocking requests from AWS network. Once we configured a proxy running in GCP problems disappeared. Nowadays, we no longer need that proxy.
        2. I initially created a backend project in Go and then quit the company. I rejoined them 3-4 years after and to my surprise the project hasn’t undergone much work. Once I installed the latest Go version the project would just run so I didn’t need to migrate any of the code nor dependencies. That was such a nice experience especially compared to me migrating from Java 8 to Java 11… But that’s a totally different story and not the pleasant one.
        1. 5

          Yes, once on Reddit someone made a comment about the stability of Go vs Node, so I dug up an archived project from only 2 or so years before (predating Go modules). Getting it to run on the current version of Go with Go modules was trivial. I gave up on getting it to run with the current version of Node because even with a Yarn lock, it just did not want to install. Maybe I could have fixed it within a day, but it was different from “just working” as Go did.

        2. 13

          Working in the Go ecosystem has made aware of how much breakage in other ecosystems is basically needless churn. Go even has a code rewriter as part of the core toolset and they still never break stuff as a matter of principle. Other projects are like “someone could someday make a rewriter therefore let’s break the code now.”

          1. 8

            I am quite excited for generics, since the lack of generics was holding me back from using it much. Now that they have it, I think I will also enjoy the stability of Go.

          2. 5

            The negative side of this change is that it makes life a bit harder and less obvious for people who want to do things with generics that go beyond just a ‘comparable’ constraint. In turn this seems likely to reduce the number of people doing this, which means that we’ll get less such experimentation and use of generics.

            The package will not be in the standard library, but it will still exist. I don’t think it makes a significant difference if you want to experiment with generics, whether you import “constraints” or “golang.org/x/exp/constraints”.

            1. 1

              But you would have to know about the external lib. The standard library is more discoverable.

              1. 3

                If someone is interested in generics on day 1, I assume they would read the release notes that explain all of this.