10 ms·

Go 1.11 and Beyond

182 points by ngaut 8y ago

ainar-g 8y ago
It will be very interesting to see, what will using Go 2 generic code from Go 1 code look like.
- deleted 8y ago
  [deleted]
howeyc 8y ago
Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X" He also hints that it would likely only be done to address major issues/concerns/changes such as: * generics * modules (perhaps done? time will tell) * errors (if err != nil {}, extra type information, chaining, etc) * context Still to early to tell if anything I listed or he listed would be part of "Go 2" or whatever it happens to be called.
- sitepodmatt 8y ago
  Don't use the word generics with golang exapple fanboys, just open a world of hate, what's wrong with StringSet.go, IntSet.go and so on (k8s), or fulfilling interface {} as a workaround. Cue hate, give me c# 1.1 anyday
  - whatpad 8y ago
    Are you referring to: https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/heketi/heketi/pkg/utils/stringset.go https://github.com/kubernetes/kubernetes/blob/master/vendor/... https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/node/intset.go https://github.com/kubernetes/kubernetes/blob/master/plugin/...
    - deleted 8y ago
      [deleted]
  - endorphone 8y ago
    The person you replied to is quoting the slides that posit that generics are a consideration for Go 2.0, so your spittle laden post betrays your own bizarre hangups. "Cue hate, give me c# 1.1 anyday" You brought the hate. Take it when you leave. Thanks.
- mseepgood 8y ago
  > Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X" Go project lead Russ Cox already talked about that on an episode of the Go Time podcast. Transcript: https://changelog.com/gotime/77#transcript-60 https://changelog.com/gotime/77#transcript-60
- fredch 8y ago
  Don't people just write helper functions to deal with the error checking spam? It's five lines at the top of the file... Anyway, I will miss our GOPATH overlords. I have enough decisions to make, I'm fine with the language making some for me.
brianolson 8y ago
One feature that could achieve generics, eliminated `if err != nill{}` stutter, and allow for backwards compatibility: macros (borrowing the '@' prefix for macros from Julia) type ConcreteStruct @macroType(int64) val := @errReturner(file.Write(data)) and backwards compatibility is allowed by running the go2 compiler in macro-expansion-only mode that creates macro expanded Go1 compatible source.
- mseepgood 8y ago
  Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".
  - thibran 8y ago
    No, they solve a complex problem. Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible. Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.
    - cageface 8y ago
      One big problem with macros is that they make it very difficult to build good tools. You can't really understand the meaning of any particular piece of syntax without completely evaluating any macros that might be in use.
      - Groxx 8y ago
        That sounds exactly like what a compiler has to do. And what all type-aware Go tools currently have to do. So we're already doing that, we just have no language-level support for doing so, so we have incredibly less-capable workarounds like makefiles and go:generate.
golergka 8y ago
Does it have generics yet?
whatpad 8y ago
> It's quite likely that "Go 2" == Go 1.15 or 1.16 That is Aug 2020 or Feb 2021 for generics.
- pietroglyph 8y ago
  They also hint to this in the slide 75 where they say "10 years is good".
dixie_land 8y ago
so coming back full cycle to realize they should've hired actual programmers that writes C++ so they don't have to invent a new language to babysit them
maxpert 8y ago
I still don't get it; so you invented a language based on idea of not doing the "evil" things C++ or say other languages did and now you have to re-invent all those "evil" things because community wants it?
- pebers 8y ago
  It isn't necessarily a bad idea to start with a minimal design and add features later once the implementation is more mature. Even if Go never gets generics, it's still a good solution for a number of problem domains (for example, it seems to have found something of a niche for infrastructure; Kubernetes, Prometheus, juju, etc.)
  - jacques_chester 8y ago
    Kubernetes has enormous masses of repetitive code that is essentially a workaround for the absence of generics or other kinds of improved types. The reliance on "union types" -- really, exclusive arcs -- gives me the heebies and also guarantees that there is a bottleneck for new features: PRs to core. And then there's the whole TypeMeta thing. An entire dynamic type system because Golang can't express what Kubernetes needs. And no, I don't see code generation as a good thing. It's fragile and difficult to safely upgrade.
    - uluyol 8y ago
      Kubernetes has more or less invented their own type system. I agree that much of it is horrible to deal with, but I don't know how you could easily express it in any language. Of course someone could always prove me wrong by doing just that.
    - pebers 8y ago
      That's kind of my point; the code might not be as beautiful as we could ever imagine, but as a product it works extremely well, and would be worse if it carried around a lot of runtime baggage and poor performance which many of the alternatives would have given.
ptx 8y ago
For all the emphasis they put on stability, there is one part that doesn't seem particularly stable – on slide 32: "Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4." This is, I assume, because Go makes direct syscalls rather than going through the C library. Many operating systems, including Windows, don't consider that a stable public interface. So does this mean that older Go binaries will stop working when you upgrade the OS? I guess that would make the source compatibility extra important to them, since you must keep recompiling your old programs as you upgrade to newer a OS. (Perhaps it's also why they're dropping support for older OS versions so quickly?)
- LukeShu 8y ago
  OpenBSD doesn't make any promises about ABI stability between releases. That means that all older binaries may stop working when you upgrade the OS, not just older Go binaries.
  - zdw 8y ago
    This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem. An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.
- AnIdiotOnTheNet 8y ago
  > Many operating systems, including Windows, don't consider that a stable public interface. Windows in no way requires libc. You're right that it does require you to call their public interface dlls, but they're pretty ridiculously stable.
  - LukeShu 8y ago
    Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.
013a 8y ago
One really minor, but powerful, thing I'd love to see from the Go team is a better designed documentation experience. Here's the Google-produced Github library godoc [1]; its absolutely horrendous to browse, as is any sufficiently large package. Compare that to Elixir's [2] auto-generated documentation. There's a lot of work that can go into just improving that static HTML and making it more easily grokable. [1] https://godoc.org/github.com/google/go-github/github https://godoc.org/github.com/google/go-github/github [2] https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html
- urtrs 8y ago
  I prefer godoc. It is concise and I can find faster what I am looking for.
- shazow 8y ago
  Godoc is an excellent forcing function when it's not ignored. Designing your package's public namespace so that it looks sensible in godoc yields great results for consumers.
- thefounder 8y ago
  Godoc compensate by being more functional. The elixir example is missing links to the source code of the functions/methods etc. Godoc also generates an excerpt with all the functions/methods/types in the package.
  - q1t 8y ago
    ExDoc does not miss links to the source code. (Click on any Module/function and there should be brackets "<>" that point to the source code.) Types are also present in any module that defines them.
- weberc2 8y ago
  I've not used Elixir, but I'm surprised by the strong dislike for GoDoc. I've used Java, C#, C/C++, Python, and JavaScript and I've never found anything to be as nice as GoDoc. In particular, Godoc is absolutely effortless. No build step in your project, no cryptic documentation syntax, no need to tell the documentation generator how to link to your dependencies' documentation pages, etc. Everything just works, and the output is quite a lot cleaner than the aforementioned as well. No doubt there's a little room for improvement in how the text is layed out and organized, but it's still leagues better than all other documentation systems I've used. With Python (sphinxdocs) in particular, everything gets rendered into a giant page with no clues about what class's `__str__()` method I'm currently looking at.
deleted 8y ago
[deleted]
coldtea 8y ago
Stability is good is what's stable meets your needs. The more they stall adding stuff like generics the more painful (and more work for the tools and ecosystem to catch up) will be when they eventually cave in and do it... And there will always be all the workarounds, third party solutions, and wasted efforts that would could have been avoided if something that could have been delivered early on (like e.g. package management) didn't come a decade late for no good reason. At least now they've come up with a module/dependency system, which, even though a decade late, doesn't bring anything extraordinary to the table compared to what other platforms already had for ages. Generics and error management remain before it makes sense to make it stable and boring for eternity...
- dilatedmind 8y ago
  When I think of generics i think custom data structures. Currently you are stuck with interfaces, but you can also wrap a library returning interfaces with methods operating on a specific type. I would be interested to hear about use cases that couldn't be solved in this manner
  - tree_of_item 8y ago
    "Solved" by having lots of meaningless unsafe glue code. That's not a solution. It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.
    - dilatedmind 8y ago
      I am legitimately asking, it's not something I have personally had much issue with. If you have some compelling example, please share your experience
      - lederhosen 8y ago
        You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics. It is a bit like asking a Java-programmer to use Java 1.4. When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.

Go 1.11 and Beyond

182 points by ngaut 8y ago

ainar-g 8y ago

It will be very interesting to see, what will using Go 2 generic code from Go 1 code look like.

deleted 8y ago
[deleted]

howeyc 8y ago

Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X" He also hints that it would likely only be done to address major issues/concerns/changes such as: * generics * modules (perhaps done? time will tell) * errors (if err != nil {}, extra type information, chaining, etc) * context Still to early to tell if anything I listed or he listed would be part of "Go 2" or whatever it happens to be called.

sitepodmatt 8y ago
Don't use the word generics with golang exapple fanboys, just open a world of hate, what's wrong with StringSet.go, IntSet.go and so on (k8s), or fulfilling interface {} as a workaround. Cue hate, give me c# 1.1 anyday
- whatpad 8y ago
  Are you referring to: https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/heketi/heketi/pkg/utils/stringset.go https://github.com/kubernetes/kubernetes/blob/master/vendor/... https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/node/intset.go https://github.com/kubernetes/kubernetes/blob/master/plugin/...
  - deleted 8y ago
    [deleted]
- endorphone 8y ago
  The person you replied to is quoting the slides that posit that generics are a consideration for Go 2.0, so your spittle laden post betrays your own bizarre hangups. "Cue hate, give me c# 1.1 anyday" You brought the hate. Take it when you leave. Thanks.
mseepgood 8y ago
> Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X" Go project lead Russ Cox already talked about that on an episode of the Go Time podcast. Transcript: https://changelog.com/gotime/77#transcript-60 https://changelog.com/gotime/77#transcript-60
fredch 8y ago
Don't people just write helper functions to deal with the error checking spam? It's five lines at the top of the file... Anyway, I will miss our GOPATH overlords. I have enough decisions to make, I'm fine with the language making some for me.

brianolson 8y ago

One feature that could achieve generics, eliminated `if err != nill{}` stutter, and allow for backwards compatibility: macros (borrowing the '@' prefix for macros from Julia) type ConcreteStruct @macroType(int64) val := @errReturner(file.Write(data)) and backwards compatibility is allowed by running the go2 compiler in macro-expansion-only mode that creates macro expanded Go1 compatible source.

mseepgood 8y ago
Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".
- thibran 8y ago
  No, they solve a complex problem. Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible. Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.
  - cageface 8y ago
    One big problem with macros is that they make it very difficult to build good tools. You can't really understand the meaning of any particular piece of syntax without completely evaluating any macros that might be in use.
    - Groxx 8y ago
      That sounds exactly like what a compiler has to do. And what all type-aware Go tools currently have to do. So we're already doing that, we just have no language-level support for doing so, so we have incredibly less-capable workarounds like makefiles and go:generate.

golergka 8y ago

Does it have generics yet?

whatpad 8y ago

> It's quite likely that "Go 2" == Go 1.15 or 1.16 That is Aug 2020 or Feb 2021 for generics.

pietroglyph 8y ago
They also hint to this in the slide 75 where they say "10 years is good".

dixie_land 8y ago

so coming back full cycle to realize they should've hired actual programmers that writes C++ so they don't have to invent a new language to babysit them

maxpert 8y ago

I still don't get it; so you invented a language based on idea of not doing the "evil" things C++ or say other languages did and now you have to re-invent all those "evil" things because community wants it?

pebers 8y ago
It isn't necessarily a bad idea to start with a minimal design and add features later once the implementation is more mature. Even if Go never gets generics, it's still a good solution for a number of problem domains (for example, it seems to have found something of a niche for infrastructure; Kubernetes, Prometheus, juju, etc.)
- jacques_chester 8y ago
  Kubernetes has enormous masses of repetitive code that is essentially a workaround for the absence of generics or other kinds of improved types. The reliance on "union types" -- really, exclusive arcs -- gives me the heebies and also guarantees that there is a bottleneck for new features: PRs to core. And then there's the whole TypeMeta thing. An entire dynamic type system because Golang can't express what Kubernetes needs. And no, I don't see code generation as a good thing. It's fragile and difficult to safely upgrade.
  - uluyol 8y ago
    Kubernetes has more or less invented their own type system. I agree that much of it is horrible to deal with, but I don't know how you could easily express it in any language. Of course someone could always prove me wrong by doing just that.
  - pebers 8y ago
    That's kind of my point; the code might not be as beautiful as we could ever imagine, but as a product it works extremely well, and would be worse if it carried around a lot of runtime baggage and poor performance which many of the alternatives would have given.

ptx 8y ago

For all the emphasis they put on stability, there is one part that doesn't seem particularly stable – on slide 32: "Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4." This is, I assume, because Go makes direct syscalls rather than going through the C library. Many operating systems, including Windows, don't consider that a stable public interface. So does this mean that older Go binaries will stop working when you upgrade the OS? I guess that would make the source compatibility extra important to them, since you must keep recompiling your old programs as you upgrade to newer a OS. (Perhaps it's also why they're dropping support for older OS versions so quickly?)

LukeShu 8y ago
OpenBSD doesn't make any promises about ABI stability between releases. That means that all older binaries may stop working when you upgrade the OS, not just older Go binaries.
- zdw 8y ago
  This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem. An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.
AnIdiotOnTheNet 8y ago
> Many operating systems, including Windows, don't consider that a stable public interface. Windows in no way requires libc. You're right that it does require you to call their public interface dlls, but they're pretty ridiculously stable.
- LukeShu 8y ago
  Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.

013a 8y ago

One really minor, but powerful, thing I'd love to see from the Go team is a better designed documentation experience. Here's the Google-produced Github library godoc [1]; its absolutely horrendous to browse, as is any sufficiently large package. Compare that to Elixir's [2] auto-generated documentation. There's a lot of work that can go into just improving that static HTML and making it more easily grokable. [1] https://godoc.org/github.com/google/go-github/github https://godoc.org/github.com/google/go-github/github [2] https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html

urtrs 8y ago
I prefer godoc. It is concise and I can find faster what I am looking for.
shazow 8y ago
Godoc is an excellent forcing function when it's not ignored. Designing your package's public namespace so that it looks sensible in godoc yields great results for consumers.
thefounder 8y ago
Godoc compensate by being more functional. The elixir example is missing links to the source code of the functions/methods etc. Godoc also generates an excerpt with all the functions/methods/types in the package.
- q1t 8y ago
  ExDoc does not miss links to the source code. (Click on any Module/function and there should be brackets "<>" that point to the source code.) Types are also present in any module that defines them.
weberc2 8y ago
I've not used Elixir, but I'm surprised by the strong dislike for GoDoc. I've used Java, C#, C/C++, Python, and JavaScript and I've never found anything to be as nice as GoDoc. In particular, Godoc is absolutely effortless. No build step in your project, no cryptic documentation syntax, no need to tell the documentation generator how to link to your dependencies' documentation pages, etc. Everything just works, and the output is quite a lot cleaner than the aforementioned as well. No doubt there's a little room for improvement in how the text is layed out and organized, but it's still leagues better than all other documentation systems I've used. With Python (sphinxdocs) in particular, everything gets rendered into a giant page with no clues about what class's `__str__()` method I'm currently looking at.

deleted 8y ago

[deleted]

coldtea 8y ago

Stability is good is what's stable meets your needs. The more they stall adding stuff like generics the more painful (and more work for the tools and ecosystem to catch up) will be when they eventually cave in and do it... And there will always be all the workarounds, third party solutions, and wasted efforts that would could have been avoided if something that could have been delivered early on (like e.g. package management) didn't come a decade late for no good reason. At least now they've come up with a module/dependency system, which, even though a decade late, doesn't bring anything extraordinary to the table compared to what other platforms already had for ages. Generics and error management remain before it makes sense to make it stable and boring for eternity...

dilatedmind 8y ago
When I think of generics i think custom data structures. Currently you are stuck with interfaces, but you can also wrap a library returning interfaces with methods operating on a specific type. I would be interested to hear about use cases that couldn't be solved in this manner
- tree_of_item 8y ago
  "Solved" by having lots of meaningless unsafe glue code. That's not a solution. It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.
  - dilatedmind 8y ago
    I am legitimately asking, it's not something I have personally had much issue with. If you have some compelling example, please share your experience
    - lederhosen 8y ago
      You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics. It is a bit like asking a Java-programmer to use Java 1.4. When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.