10 ms·

I really admire the Go team for sticking to their guns and taking their time before making language changes. Let's avoid another C++.

bsaul 7y ago
I completely agree. Although it's refreshing to have an official team leader mention generics as a priority rather than the passive-aggressive stance that used to be the norm a few years back (aka "show us why you need it, and give us a perfect design if you think that's possible). I think the "we're working on it, but it's going to take a lot of time before we get something good enough" current position is the perfect middleground.
- deleted 7y ago
  [deleted]
- JulianMorrison 7y ago
  If you look at the questionnaire[1] they ask for new changes, it's clear they still want a justification, and a design, for new proposals. And that proposals which "state a problem rather than a solution" will be rejected. It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation. [1] https://github.com/golang/proposal/blob/master/go2-language-changes.md https://github.com/golang/proposal/blob/master/go2-language-...
  - pansa2 7y ago
    > It's just that they've been convinced that generics are justified. I wonder if anybody’s actually changed their mind on this, or whether the opinion of the Go team has shifted simply because it’s made up of different people now.
    - mseepgood 7y ago
      There was no change of mind. They always had generics in their minds. See the Go FAQ: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics "Generics may well be added at some point. We don't feel an urgency for them [...] we continue to think about it. [...] The topic remains open." These sentences have been in the FAQ since Go 1.0. Maybe people should start to believe them. They have gathered experience with the current language, their generics design drafts have improved over the years, and now they feel like they have something that might fit.
    - typical182 7y ago
      As far as I have followed, I think it is more that while a fair amount of work had gone into prior designs for generics in Go, the general feeling of the core Go team was the prior designs did mesh well with the rest of the language, whereas the more recent design seems like it could work. From this blog post[1] from last year from the core Go team: We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, like we learned from check and try. Each time, we learned that the path to Go 2 is not in that exact direction, and we noticed other directions that might be interesting to explore. But by 2013 we had decided that we needed to focus on other concerns, so we put the entire topic aside for a few years. Last year we started exploring and experimenting again, and we presented a new design, based on the idea of a contract, at Gophercon last summer. We’ve continued to experiment and simplify, and we’ve been working with programming language theory experts to understand the design better. Overall, I am hopeful that we’re headed in a good direction [1] https://blog.golang.org/experiment https://blog.golang.org/experiment
- rob74 7y ago
  AFAIK the position expressed in the Go FAQ (https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics) has always been the official position on generics: "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." There's nothing passive-aggressive about that - most proponents of generics only see the advantages (i.e. more expressiveness), but fail to see the downsides.
  - bsaul 7y ago
    I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature. And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).
    - pjmlp 7y ago
      It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.
    - danieldk 7y ago
      I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
      - 7y ago
- kyrra 7y ago
  They have been iterating on the contracts proposal here: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317
dwaite 7y ago
There's been a feature I've wanted in C++ (concepts) that is finally coming after 14 years. I don't think expediency is the problem with C++ language evolution.
- zerr 7y ago
  Exactly. We're still waiting for string split/join.
  - IshKebab 7y ago
    Yeah, kind of blows my mind how many advanced features they add, but basic string handling stuff that you always use (split, join, startsWith, etc.) is never added.
    - pjmlp 7y ago
      Well, it is a matter of who is willing to submit a paper and champion the idea. I think the problem is that those features are an uphill battle with the crowd that wants performance above anything else, given the implicit allocations that they might need.
    - thestoicattack 7y ago
      For the record, std::string::starts_with and ends_with are in C++20. Split and join aren't, though. (I think join is not too tough to write, but I don't really know how you'd write split in a generic enough way for everyone to be satisfied.)
      - ryanianian 7y ago
        Join is relatively trivial using std::stringstream. I'm optimistic that split will be less contentious with C++20 ranges since you can just range-based-for loop over the split tokens in-place and/or collect them into a container using range mechanisms : best of both worlds.
  - alexhutcheson 7y ago
mantap 7y ago
C++ is 35 years old. The problem is that it has 35 years of backwards compatibility. Go will not avoid this problem by taking time to make changes, it can only be resolved by being prepared to break backwards compatibility.
- sammorrowdrums 7y ago
  It's quite an amazing feat that C++ has maintained backwards compatibility. Watching the ~11 years of Python 2 to 3 adoption has been somewhat painful, and many libraries have had to offer support for both across much of that time. (And I believe at time of writing Google isn't even 100% ported to 3 yet - please correct this if I'm wrong). I couldn't be happier that Python 3 is finally king though, and major projects like Django are able to go entirely to 3 now. Breaking changes in languages can be important and good, but they really can affect adoption of the new version by existing users, which is tough as often major users hold some sway in the ecosystem. JavaScript has the no breaking changes problem even worse, because you have to support (within reason) all major interpreters existing in the wild, and cannot easily change the code, so "transpiling" has become the normal. Microsofts support lifetime for IE11 also means this isn't changing soon. Lots of old browsers in the wild (even though it has improved dramatically over last few years).
  - mantap 7y ago
    It is much easier to do breaking changes in a compiled and statically typed language, as long as it doesn't use a preprocessor. Because you can do automatic upgrades. Some Python 3 changes were not fixable by 2to3 which meant all source needed to be checked manually line by line, vastly increasing the cost of upgrading. Worse, Python 2 wasn't forward compatible with Python 3 in many cases, which required libraries like six to get a transition period through the back door. The whole process was managed horrifically.
    - IshKebab 7y ago
      C++ has not maintained backwards compatibility by doing automatic upgrades. I don't think that would even count. Backwards compatibility for a language means that old source code still works without having to update it, even if you can do so automatically. Also worth pointing out that C++ has broken backwards compatibility in a very small number of cases, e.g. the `auto` keyword has changed meaning. Nobody ever used it before so it wasn't a problem in practice.
tapirl 7y ago
Several years ago, I very don't like the way and the pace C++ introduces new features. But now the way and pace has become normal, I change my mind some. I think it is the time I should re-use C++ for some projects. It would be some restricted if these projects are written in Go, for lacking of some key features.
- sethammons 7y ago
  Which features and why?
  - tapirl 7y ago
    Specifically, generics and immutable values. Lacking of generics lead to much repetitive code. I don't like using exported variables as final values, so I need to use functions to return the final values, which is verbose and not elegant. Lacking of read-only values also causes some unnecessary performance losses. Too network/tools oriented is also a reason. Porting C/C++ gfx libraries is not an easy job, especially multiple C/C++ gfx libraries are involved. And the performance is not high as C/C++ even if the porting is done.
    - chooseaname 7y ago
      > I don't like using exported variables as final values, so I need to use functions to return the final values, which is verbose and not elegant. Lacking of read-only values also causes some unnecessary performance losses. This sounds like you're fighting against the language. I think a lot of developers do this. I think one should either embrace the language or find another (you did mention moving to C++).
      - tapirl 7y ago
        I do this to adapt it, to make code more secure and serious. I embrace other features in Go but not this one. This one makes Go some like a non-serious language.
mhd 7y ago
I wouldn't mind one major thing from C++: A standard.
- dgellow 7y ago
  I’m not sure what you mean: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard
  - pjmlp 7y ago
    I think the idea is having either ECMA or ISO Go.
    - dgellow 7y ago
      I see, I misread the comment I was responding to. For some reason I got the opposite: "C++ is missing a standard", instead of "Go is missing a standard". Makes sense then.
- rob74 7y ago
  If you're talking about Go, they have an official specification (https://golang.org/ref/spec https://golang.org/ref/spec), which is probably what you mean when you write "standard", and the two official implementations (the Go compiler and the GCC-Go compiler) are based on this spec. Which is more than other up-and-coming languages (which I won't name right now) have to offer ;)
  - mhd 7y ago
    ISO/ANSI would be my preference. That's still not the best model of language governance, but at least it's not down to one company. Also a decent sign of stability.
    - jhoechtl 7y ago
      So you like to pay for specs?
kortex 7y ago
I'm really glad they don't have C++ style generics, and I hope whatever way they do it if/when they do, it keeps that Go minimalism. I'd like to see the Interface system more powerful. You can already do some very un-gothonic things with map[string]interface{}. I'd like to be able to compose functions already based on an interface, to implicitly implement other types, rather than spelling out each function (maybe you can already, I'm still only a few months in to Go). I liked the concept of "try" but I agree with the peanut gallery, the syntax needs work. But many gophers (it seems) agree there should be a shorthand for "I got an error, bubble it up to the caller" aka "if err != nil {return nil, err}" Or maybe not. In some ways, the verbosity of err != nil everywhere makes me look for ways to solve problems with less error returning.
- gtycomb 7y ago
  I don't miss generics either, not in the least. The interface system, Go's particular approach to it, takes me a long way ... I won't ask for any new feature for today or tomorrow. But for day after tommorow, within a longer time research horizon, I wonder whether compiled and distributed Go applications can be made to interact along the lines of interfaces within an application now. May be its my struggle with Kubernates (as a newbie) that makes me want: Can there be secure language mechanisms supporting clustering, scheduling etc in a distributed enviroment with an external agent armed only with prior package interface definitions of a deployed Go application. Please don't sacrifice performance, and fast compilation times. That module system is looking good!
jhoechtl 7y ago
string(int) to result in the string representation of the int value rather than the code point int represents comes at surprise and is orthogonal to the other conversion functions. Please don't do it. That direction of conversion, if done right, requires respecting locale which string(int) is fully unaware.
- morelisp 7y ago
  The change is to warn people against using `string(int)`, not to change its behavior. The goal is to remove the conversion, not make it replace `Itoa`.

bsaul 7y ago

I completely agree. Although it's refreshing to have an official team leader mention generics as a priority rather than the passive-aggressive stance that used to be the norm a few years back (aka "show us why you need it, and give us a perfect design if you think that's possible). I think the "we're working on it, but it's going to take a lot of time before we get something good enough" current position is the perfect middleground.

deleted 7y ago
[deleted]
JulianMorrison 7y ago
If you look at the questionnaire[1] they ask for new changes, it's clear they still want a justification, and a design, for new proposals. And that proposals which "state a problem rather than a solution" will be rejected. It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation. [1] https://github.com/golang/proposal/blob/master/go2-language-changes.md https://github.com/golang/proposal/blob/master/go2-language-...
- pansa2 7y ago
  > It's just that they've been convinced that generics are justified. I wonder if anybody’s actually changed their mind on this, or whether the opinion of the Go team has shifted simply because it’s made up of different people now.
  - mseepgood 7y ago
    There was no change of mind. They always had generics in their minds. See the Go FAQ: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics "Generics may well be added at some point. We don't feel an urgency for them [...] we continue to think about it. [...] The topic remains open." These sentences have been in the FAQ since Go 1.0. Maybe people should start to believe them. They have gathered experience with the current language, their generics design drafts have improved over the years, and now they feel like they have something that might fit.
  - typical182 7y ago
    As far as I have followed, I think it is more that while a fair amount of work had gone into prior designs for generics in Go, the general feeling of the core Go team was the prior designs did mesh well with the rest of the language, whereas the more recent design seems like it could work. From this blog post[1] from last year from the core Go team: We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, like we learned from check and try. Each time, we learned that the path to Go 2 is not in that exact direction, and we noticed other directions that might be interesting to explore. But by 2013 we had decided that we needed to focus on other concerns, so we put the entire topic aside for a few years. Last year we started exploring and experimenting again, and we presented a new design, based on the idea of a contract, at Gophercon last summer. We’ve continued to experiment and simplify, and we’ve been working with programming language theory experts to understand the design better. Overall, I am hopeful that we’re headed in a good direction [1] https://blog.golang.org/experiment https://blog.golang.org/experiment
rob74 7y ago
AFAIK the position expressed in the Go FAQ (https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics) has always been the official position on generics: "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." There's nothing passive-aggressive about that - most proponents of generics only see the advantages (i.e. more expressiveness), but fail to see the downsides.
- bsaul 7y ago
  I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature. And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).
  - pjmlp 7y ago
    It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.
  - danieldk 7y ago
    I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
    - 7y ago
kyrra 7y ago
They have been iterating on the contracts proposal here: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317

dwaite 7y ago

There's been a feature I've wanted in C++ (concepts) that is finally coming after 14 years. I don't think expediency is the problem with C++ language evolution.

zerr 7y ago
Exactly. We're still waiting for string split/join.
- IshKebab 7y ago
  Yeah, kind of blows my mind how many advanced features they add, but basic string handling stuff that you always use (split, join, startsWith, etc.) is never added.
  - pjmlp 7y ago
    Well, it is a matter of who is willing to submit a paper and champion the idea. I think the problem is that those features are an uphill battle with the crowd that wants performance above anything else, given the implicit allocations that they might need.
  - thestoicattack 7y ago
    For the record, std::string::starts_with and ends_with are in C++20. Split and join aren't, though. (I think join is not too tough to write, but I don't really know how you'd write split in a generic enough way for everyone to be satisfied.)
    - ryanianian 7y ago
      Join is relatively trivial using std::stringstream. I'm optimistic that split will be less contentious with C++20 ranges since you can just range-based-for loop over the split tokens in-place and/or collect them into a container using range mechanisms : best of both worlds.
- alexhutcheson 7y ago

mantap 7y ago

C++ is 35 years old. The problem is that it has 35 years of backwards compatibility. Go will not avoid this problem by taking time to make changes, it can only be resolved by being prepared to break backwards compatibility.

sammorrowdrums 7y ago
It's quite an amazing feat that C++ has maintained backwards compatibility. Watching the ~11 years of Python 2 to 3 adoption has been somewhat painful, and many libraries have had to offer support for both across much of that time. (And I believe at time of writing Google isn't even 100% ported to 3 yet - please correct this if I'm wrong). I couldn't be happier that Python 3 is finally king though, and major projects like Django are able to go entirely to 3 now. Breaking changes in languages can be important and good, but they really can affect adoption of the new version by existing users, which is tough as often major users hold some sway in the ecosystem. JavaScript has the no breaking changes problem even worse, because you have to support (within reason) all major interpreters existing in the wild, and cannot easily change the code, so "transpiling" has become the normal. Microsofts support lifetime for IE11 also means this isn't changing soon. Lots of old browsers in the wild (even though it has improved dramatically over last few years).
- mantap 7y ago
  It is much easier to do breaking changes in a compiled and statically typed language, as long as it doesn't use a preprocessor. Because you can do automatic upgrades. Some Python 3 changes were not fixable by 2to3 which meant all source needed to be checked manually line by line, vastly increasing the cost of upgrading. Worse, Python 2 wasn't forward compatible with Python 3 in many cases, which required libraries like six to get a transition period through the back door. The whole process was managed horrifically.
  - IshKebab 7y ago
    C++ has not maintained backwards compatibility by doing automatic upgrades. I don't think that would even count. Backwards compatibility for a language means that old source code still works without having to update it, even if you can do so automatically. Also worth pointing out that C++ has broken backwards compatibility in a very small number of cases, e.g. the `auto` keyword has changed meaning. Nobody ever used it before so it wasn't a problem in practice.

tapirl 7y ago

Several years ago, I very don't like the way and the pace C++ introduces new features. But now the way and pace has become normal, I change my mind some. I think it is the time I should re-use C++ for some projects. It would be some restricted if these projects are written in Go, for lacking of some key features.

sethammons 7y ago
Which features and why?
- tapirl 7y ago
  Specifically, generics and immutable values. Lacking of generics lead to much repetitive code. I don't like using exported variables as final values, so I need to use functions to return the final values, which is verbose and not elegant. Lacking of read-only values also causes some unnecessary performance losses. Too network/tools oriented is also a reason. Porting C/C++ gfx libraries is not an easy job, especially multiple C/C++ gfx libraries are involved. And the performance is not high as C/C++ even if the porting is done.
  - chooseaname 7y ago
    > I don't like using exported variables as final values, so I need to use functions to return the final values, which is verbose and not elegant. Lacking of read-only values also causes some unnecessary performance losses. This sounds like you're fighting against the language. I think a lot of developers do this. I think one should either embrace the language or find another (you did mention moving to C++).
    - tapirl 7y ago
      I do this to adapt it, to make code more secure and serious. I embrace other features in Go but not this one. This one makes Go some like a non-serious language.

mhd 7y ago

I wouldn't mind one major thing from C++: A standard.

dgellow 7y ago
I’m not sure what you mean: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard
- pjmlp 7y ago
  I think the idea is having either ECMA or ISO Go.
  - dgellow 7y ago
    I see, I misread the comment I was responding to. For some reason I got the opposite: "C++ is missing a standard", instead of "Go is missing a standard". Makes sense then.
rob74 7y ago
If you're talking about Go, they have an official specification (https://golang.org/ref/spec https://golang.org/ref/spec), which is probably what you mean when you write "standard", and the two official implementations (the Go compiler and the GCC-Go compiler) are based on this spec. Which is more than other up-and-coming languages (which I won't name right now) have to offer ;)
- mhd 7y ago
  ISO/ANSI would be my preference. That's still not the best model of language governance, but at least it's not down to one company. Also a decent sign of stability.
  - jhoechtl 7y ago
    So you like to pay for specs?

kortex 7y ago

I'm really glad they don't have C++ style generics, and I hope whatever way they do it if/when they do, it keeps that Go minimalism. I'd like to see the Interface system more powerful. You can already do some very un-gothonic things with map[string]interface{}. I'd like to be able to compose functions already based on an interface, to implicitly implement other types, rather than spelling out each function (maybe you can already, I'm still only a few months in to Go). I liked the concept of "try" but I agree with the peanut gallery, the syntax needs work. But many gophers (it seems) agree there should be a shorthand for "I got an error, bubble it up to the caller" aka "if err != nil {return nil, err}" Or maybe not. In some ways, the verbosity of err != nil everywhere makes me look for ways to solve problems with less error returning.

gtycomb 7y ago
I don't miss generics either, not in the least. The interface system, Go's particular approach to it, takes me a long way ... I won't ask for any new feature for today or tomorrow. But for day after tommorow, within a longer time research horizon, I wonder whether compiled and distributed Go applications can be made to interact along the lines of interfaces within an application now. May be its my struggle with Kubernates (as a newbie) that makes me want: Can there be secure language mechanisms supporting clustering, scheduling etc in a distributed enviroment with an external agent armed only with prior package interface definitions of a deployed Go application. Please don't sacrifice performance, and fast compilation times. That module system is looking good!

jhoechtl 7y ago

string(int) to result in the string representation of the int value rather than the code point int represents comes at surprise and is orthogonal to the other conversion functions. Please don't do it. That direction of conversion, if done right, requires respecting locale which string(int) is fully unaware.

morelisp 7y ago
The change is to warn people against using `string(int)`, not to change its behavior. The goal is to remove the conversion, not make it replace `Itoa`.