14 ms·

It's a type alias, introduced for generics. By the way, Go 1.18 Beta 1 is released (with generics): https://groups.google.com/g/golang-announce/c/eAjK4Oezs_A ht

It's a type alias, introduced for generics. By the way, Go 1.18 Beta 1 is released (with generics): https://groups.google.com/g/golang-announce/c/eAjK4Oezs_A https://groups.google.com/g/golang-announce/c/eAjK4Oezs_A

exdsq 5y ago
How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change
- preseinger 5y ago
  It's not a breaking change.
- mseepgood 5y ago
  They are backwards compatible and don't break people's code, so it's 1.x.
- philwelch 5y ago
  In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.
  - keithnz 5y ago
    Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with breaking changes. For a language? Silliness. Your version is not really telling you the main things you care about. It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. If it's like other languages, generics changes the code people generate a lot, libraries start looking significantly different. It's very distinct, and if that is simply in version 1.18.0 or whatever, that is super bad usability from a language perspective.
    - pawelmurias 5y ago
      > Can upgrade without having to deal with breaking changes This is actually very important. If something is a major change or not is pretty subjective.
      - eru 5y ago
        It is pretty subjective, but not entirely so, and I would guess there's a pretty clear consensus around whether this is a big deal or not in the community?
    - lanstin 5y ago
      Not really from my perspective. I want know if there is any reason to not upgrade due to my existing code base breaking. Extra new features I could use are not such a reason. New reserved words are such a reason. If someone is using a new feature, I can just say "make sure you have the newest version, also here's my reason for keeping close to the edge of current versions, so that you amortize the labor of keeping up to date rather than pinning and then having some big migration project in 5 years."
    - robto 5y ago
      In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers seem to have very little respect for their users and constantly break backwards compatibility. In ecosystems like that, upgrading fills me with dread. When I see a library on version 4, I have learned to keep looking - if they weren't thoughtful enough about their API design for the first 3 major releases, I shouldn't expect it to be much better going forwards. For an application, I'm pretty open to version numbers signifying big features - Firefox and Chrome do this, and it's helpful with marketing. But for a programming language? A programming language is a tool, and when upgrading you need to carefully read the changelog anyways. A programming language is no different from a library (in Clojure it literally is a library), and backwards compatibility is /literally/ the main thing I care about. Is my tool going to intrude on /my/ schedule, and force me to make changes /it/ wants instead of being able to spend my time making changes /I/ care about? I want to know that. [0]This is apparently an awful example as I've just learned that Java is actually doing the major version only thing. It still sort of works because the only reason they can do that is because they Will Not Break Compatiblity.
  - stormbrew 5y ago
    I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is pervasively threaded through new code, I feel like it's hard to describe them as part of the same epoch. I don't write enough go to know if that's true for generics, but it seems like it could become true fairly quickly from my experience with other languages.
    - latortuga 5y ago
      This seems like it would apply to literally any new feature - new code won't compile on an old compiler. It isn't the purpose of semver though, semver is trying to help you upgrade old code safely.
      - stormbrew 5y ago
        I think the thing, to me, is that semver is very useful where these things are purely mechanical. This (at least usually) applies to libraries. Semver enables things like lockfiles as used by ruby bundler and later cargo and various other things. But not all systems are upgraded in mechanical ways, and not all 'breaks' are purely mechanical. This is why you can't really use semver (usefully) for everything. What's a "breaking change" in a word processor? Languages aren't used like word processors, but they also aren't exactly used like libraries either. People get stuck on language versions for different reasons than why they get stuck on library versions. At any rate I think in practice I think languages that are trying to hew to semver concepts like this just wind up with a 'fake major version'. Since Rust, for eg., might never go to 2.x the 1. in front of 54 is really just academic. That's the "real" major version as far as anyone needs to know. A lot of the arguments in this thread seem to be kinda tautological. There's no law that says they have to use semver, nor is there a law that says semver can't be imperfect. "Semver is semver because semver says so" is not a compelling argument.
    - naikrovek 5y ago
  - nine_k 5y ago
    Changing the programming approach seriously should be a major version change. A language is an interface with humans. Switching to generics is a major change in the way to think about the source code. It's not an implementation detail which is not a big deal as long as the compiler can accept earlier source syntax.
    - KronisLV 5y ago
      Heh, i think that there are plenty of opinions about how software versioning should work. Yours is a pretty good one, i think that software versions should be indicative of what it contains to the people using them, whereas some others primarily care about the compatibility with the other versions. Semantic versioning is better suited to the latter group, because it doesn't really care about what's in the software, beyond what the changes are when compared to the other versions - breaking functionality, non-breaking functionality or just fixes of some sort. My own alternative would take a slightly different approach yet - a system that would indicate when something was released, as well as whether the release is supposed to be stable (think MySQL 5.7, but in a format like 2021-stable-1234), or something more like a rolling release/nightly build with the latest changes (in format like 2021-latest-2345), an idea that in part i shamelessly stole from the Unity game engine, Ubuntu and JetBrains IDEs, since having a glance at their versions makes it apparent what you're looking at. I actually wrote about that idea on my blog: https://blog.kronis.dev/articles/stable-software-release-system https://blog.kronis.dev/articles/stable-software-release-sys... Since then, i've started using that scheme for a few internal libraries in my dayjob to see whether it will work out (where switching to something else would be a matter of updating the CI, so less than an hour), as well as some personal projects. Of course, each versioning scheme has advantages and disadvantages.
- bastardoperator 5y ago
  See https://semver.org/ https://semver.org/ for more details. https://0ver.org/ https://0ver.org/ is fairly popular, and I see https://calver.org/ https://calver.org/ pretty often too.
  - ignoramous 5y ago
    0ver is parody, right?
    - jonathankoren 5y ago
      Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/ https://www.greenwoodsoftware.com/less/
      - meowface 5y ago
        My favorite has become just making the version number the release date.
        ViViDboarder 5y ago
        See CalVer. The date is definitely helpful for something with fairly stable APIs where breaking changes aren’t really happening. Perfect for things like Ubuntu, pytz, and ca-certificates. Less for something like a library who’s API could change and break your implementation.
        eru 5y ago
        CalVer is useful for Ubuntu. But not because it's stable, just the opposite: It's useful for Ubuntu, because each Ubuntu release is a hodgepodge of lots of unrelated updates. Some will be breaking, some will be fine.
        ljm 5y ago
        Also for systems relying on continuous delivery in some form, like websites and web apps and SaaS. Because as a user you don't actually have a choice to use an update or stay on an old one. Considering most places I've worked at just bump the minor number in perpetuity, a date-based version conveys a bit more info. Also so much easier to know when it's going out if you have a release cycle (e.g. you don't have to guess what date 3.12354.0 is going to prod, you would know it already from a version like 2021.12.25).
- planb 5y ago
  Was "any" a reserved word in Go before? Because if not, this would be a breaking chnage for all code that uses a var named "any".
  - dharmab 5y ago
    I just tested on the dev branch and you can still use variables named `any`. The compiler is smart enough to tell variable names and types apart. You can even create a variable named any with type any with `var any any`
  - mseepgood 5y ago
    "any" is a new identifier, not a keyword. The usual shadowing rules apply.
egeozcan 5y ago
AFAICT, its usage is not restricted to generics. It seems to be suggested to use anywhere you would use interface{}. For the release announcement: https://news.ycombinator.com/item?id=29556646 https://news.ycombinator.com/item?id=29556646
- mseepgood 5y ago
  Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}
  - eweise 5y ago
    Couldn't unbounded just be [T]? Why the extra typing?
    - Intermernet 5y ago
      It's not really extra typing. It's just a syntactic convenience considered beneficial by the core team. It doesn't actually break compiler parsing in any way, but it may lead to human confusion in cases where a variable or constant has been named "any". This is probably very rare, and the code will still compile.
    - mseepgood 5y ago
      No, that would be a parsing ambiguity with arrays. And the consistency of type parameter lists with normal parameter lists where types are mandatory is an additional benefit.
    - handrous 5y ago
      Makes it much less likely someone will accidentally define a type as "any".
    - 5y ago
lolive 5y ago
Disclaimer: I am totally newbie in Go. But quite experienced in Java and Js/Ts. I never jumped the Go bandwagon because of the lack of generics. Can I now try Go? The following article seems to say that the lack of other features can be frustrating (the lack of lambdas and the lack of the functional handling of collections seems problematic to me) Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete) Would the local gurus here please comment? [the idea for me is to replace my tricky shell scripts with Go scripts.] https://medium.com/webstep/a-java-developers-adventures-through-the-strange-landscape-of-go-b49b3c9225eb https://medium.com/webstep/a-java-developers-adventures-thro...
- selljamhere 5y ago
  > Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete) Jet Brains makes GoLand, which is about as good as they come. It should feel familiar if you're used to IntelliJ. https://www.jetbrains.com/go/ https://www.jetbrains.com/go/
- bearcherian 5y ago
  If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.
  - lolive 5y ago
    Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]
    - lolive 5y ago
      Oh. And and at one moment in my career, I had to jump into serious web dev ;( But it was just after the death of IE ;) [Call me lucky] My 2 cents: widespread adoption is not synonym with long term perenity.

exdsq 5y ago

How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change

preseinger 5y ago
It's not a breaking change.
mseepgood 5y ago
They are backwards compatible and don't break people's code, so it's 1.x.
philwelch 5y ago
In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.
- keithnz 5y ago
  Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with breaking changes. For a language? Silliness. Your version is not really telling you the main things you care about. It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. If it's like other languages, generics changes the code people generate a lot, libraries start looking significantly different. It's very distinct, and if that is simply in version 1.18.0 or whatever, that is super bad usability from a language perspective.
  - pawelmurias 5y ago
    > Can upgrade without having to deal with breaking changes This is actually very important. If something is a major change or not is pretty subjective.
    - eru 5y ago
      It is pretty subjective, but not entirely so, and I would guess there's a pretty clear consensus around whether this is a big deal or not in the community?
  - lanstin 5y ago
    Not really from my perspective. I want know if there is any reason to not upgrade due to my existing code base breaking. Extra new features I could use are not such a reason. New reserved words are such a reason. If someone is using a new feature, I can just say "make sure you have the newest version, also here's my reason for keeping close to the edge of current versions, so that you amortize the labor of keeping up to date rather than pinning and then having some big migration project in 5 years."
  - robto 5y ago
    In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers seem to have very little respect for their users and constantly break backwards compatibility. In ecosystems like that, upgrading fills me with dread. When I see a library on version 4, I have learned to keep looking - if they weren't thoughtful enough about their API design for the first 3 major releases, I shouldn't expect it to be much better going forwards. For an application, I'm pretty open to version numbers signifying big features - Firefox and Chrome do this, and it's helpful with marketing. But for a programming language? A programming language is a tool, and when upgrading you need to carefully read the changelog anyways. A programming language is no different from a library (in Clojure it literally is a library), and backwards compatibility is /literally/ the main thing I care about. Is my tool going to intrude on /my/ schedule, and force me to make changes /it/ wants instead of being able to spend my time making changes /I/ care about? I want to know that. [0]This is apparently an awful example as I've just learned that Java is actually doing the major version only thing. It still sort of works because the only reason they can do that is because they Will Not Break Compatiblity.
- stormbrew 5y ago
  I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is pervasively threaded through new code, I feel like it's hard to describe them as part of the same epoch. I don't write enough go to know if that's true for generics, but it seems like it could become true fairly quickly from my experience with other languages.
  - latortuga 5y ago
    This seems like it would apply to literally any new feature - new code won't compile on an old compiler. It isn't the purpose of semver though, semver is trying to help you upgrade old code safely.
    - stormbrew 5y ago
      I think the thing, to me, is that semver is very useful where these things are purely mechanical. This (at least usually) applies to libraries. Semver enables things like lockfiles as used by ruby bundler and later cargo and various other things. But not all systems are upgraded in mechanical ways, and not all 'breaks' are purely mechanical. This is why you can't really use semver (usefully) for everything. What's a "breaking change" in a word processor? Languages aren't used like word processors, but they also aren't exactly used like libraries either. People get stuck on language versions for different reasons than why they get stuck on library versions. At any rate I think in practice I think languages that are trying to hew to semver concepts like this just wind up with a 'fake major version'. Since Rust, for eg., might never go to 2.x the 1. in front of 54 is really just academic. That's the "real" major version as far as anyone needs to know. A lot of the arguments in this thread seem to be kinda tautological. There's no law that says they have to use semver, nor is there a law that says semver can't be imperfect. "Semver is semver because semver says so" is not a compelling argument.
  - naikrovek 5y ago
- nine_k 5y ago
  Changing the programming approach seriously should be a major version change. A language is an interface with humans. Switching to generics is a major change in the way to think about the source code. It's not an implementation detail which is not a big deal as long as the compiler can accept earlier source syntax.
  - KronisLV 5y ago
    Heh, i think that there are plenty of opinions about how software versioning should work. Yours is a pretty good one, i think that software versions should be indicative of what it contains to the people using them, whereas some others primarily care about the compatibility with the other versions. Semantic versioning is better suited to the latter group, because it doesn't really care about what's in the software, beyond what the changes are when compared to the other versions - breaking functionality, non-breaking functionality or just fixes of some sort. My own alternative would take a slightly different approach yet - a system that would indicate when something was released, as well as whether the release is supposed to be stable (think MySQL 5.7, but in a format like 2021-stable-1234), or something more like a rolling release/nightly build with the latest changes (in format like 2021-latest-2345), an idea that in part i shamelessly stole from the Unity game engine, Ubuntu and JetBrains IDEs, since having a glance at their versions makes it apparent what you're looking at. I actually wrote about that idea on my blog: https://blog.kronis.dev/articles/stable-software-release-system https://blog.kronis.dev/articles/stable-software-release-sys... Since then, i've started using that scheme for a few internal libraries in my dayjob to see whether it will work out (where switching to something else would be a matter of updating the CI, so less than an hour), as well as some personal projects. Of course, each versioning scheme has advantages and disadvantages.
bastardoperator 5y ago
See https://semver.org/ https://semver.org/ for more details. https://0ver.org/ https://0ver.org/ is fairly popular, and I see https://calver.org/ https://calver.org/ pretty often too.
- ignoramous 5y ago
  0ver is parody, right?
  - jonathankoren 5y ago
    Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/ https://www.greenwoodsoftware.com/less/
    - meowface 5y ago
      My favorite has become just making the version number the release date.
      - ViViDboarder 5y ago
        See CalVer. The date is definitely helpful for something with fairly stable APIs where breaking changes aren’t really happening. Perfect for things like Ubuntu, pytz, and ca-certificates. Less for something like a library who’s API could change and break your implementation.
        eru 5y ago
        CalVer is useful for Ubuntu. But not because it's stable, just the opposite: It's useful for Ubuntu, because each Ubuntu release is a hodgepodge of lots of unrelated updates. Some will be breaking, some will be fine.
        ljm 5y ago
        Also for systems relying on continuous delivery in some form, like websites and web apps and SaaS. Because as a user you don't actually have a choice to use an update or stay on an old one. Considering most places I've worked at just bump the minor number in perpetuity, a date-based version conveys a bit more info. Also so much easier to know when it's going out if you have a release cycle (e.g. you don't have to guess what date 3.12354.0 is going to prod, you would know it already from a version like 2021.12.25).
planb 5y ago
Was "any" a reserved word in Go before? Because if not, this would be a breaking chnage for all code that uses a var named "any".
- dharmab 5y ago
  I just tested on the dev branch and you can still use variables named `any`. The compiler is smart enough to tell variable names and types apart. You can even create a variable named any with type any with `var any any`
- mseepgood 5y ago
  "any" is a new identifier, not a keyword. The usual shadowing rules apply.

egeozcan 5y ago

AFAICT, its usage is not restricted to generics. It seems to be suggested to use anywhere you would use interface{}. For the release announcement: https://news.ycombinator.com/item?id=29556646 https://news.ycombinator.com/item?id=29556646

mseepgood 5y ago
Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}
- eweise 5y ago
  Couldn't unbounded just be [T]? Why the extra typing?
  - Intermernet 5y ago
    It's not really extra typing. It's just a syntactic convenience considered beneficial by the core team. It doesn't actually break compiler parsing in any way, but it may lead to human confusion in cases where a variable or constant has been named "any". This is probably very rare, and the code will still compile.
  - mseepgood 5y ago
    No, that would be a parsing ambiguity with arrays. And the consistency of type parameter lists with normal parameter lists where types are mandatory is an additional benefit.
  - handrous 5y ago
    Makes it much less likely someone will accidentally define a type as "any".
  - 5y ago

lolive 5y ago

Disclaimer: I am totally newbie in Go. But quite experienced in Java and Js/Ts. I never jumped the Go bandwagon because of the lack of generics. Can I now try Go? The following article seems to say that the lack of other features can be frustrating (the lack of lambdas and the lack of the functional handling of collections seems problematic to me) Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete) Would the local gurus here please comment? [the idea for me is to replace my tricky shell scripts with Go scripts.] https://medium.com/webstep/a-java-developers-adventures-through-the-strange-landscape-of-go-b49b3c9225eb https://medium.com/webstep/a-java-developers-adventures-thro...

selljamhere 5y ago
> Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete) Jet Brains makes GoLand, which is about as good as they come. It should feel familiar if you're used to IntelliJ. https://www.jetbrains.com/go/ https://www.jetbrains.com/go/
bearcherian 5y ago
If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.
- lolive 5y ago
  Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]
  - lolive 5y ago
    Oh. And and at one moment in my career, I had to jump into serious web dev ;( But it was just after the death of IE ;) [Call me lucky] My 2 cents: widespread adoption is not synonym with long term perenity.