14 ms·

Many like Go because it is an opinionated language. I'm not sure that a 'community' run language will create something like that because there are too many opin

by pa7ch 7y ago

Many like Go because it is an opinionated language. I'm not sure that a 'community' run language will create something like that because there are too many opinions. Many claim to represent the community, but not the community that doesn't share their opinion. Without clear leaders I fear technical direction and taste will be about politics which seems more uncertain/risky. I like that there is a tight cohesive group in control over Go and that they are largely the original designers. I might be more interested in alternative government structures and Google having too much control only if those original authors all stepped down.

theshrike79 7y ago
In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.
- crimsonalucard 7y ago
  Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.
  - nnq 7y ago
    > Parametric polymorphism is a real world issue. ...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.
    - masklinn 7y ago
      > ...what in the world makes you thing that? Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.
      - foldr 7y ago
        Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
        masklinn 7y ago
        > Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
        foldr 7y ago
        According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". >Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths. This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
    - calcifer 7y ago
      > but nothing stops you from writing the most complex computer programs you can imagine without it. Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.
  - B-Con 7y ago
    This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box. Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.
    - chrisweekly 7y ago
      WAI?
      - alach11 7y ago
        I would guess Working As Intended.
      - deleted 7y ago
        [deleted]
  - xyproto 7y ago
    Parametric polymorphism is a tool to solve real world issues with. It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.
  - _ph_ 7y ago
    But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings. Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.
    - pjmlp 7y ago
      ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.
      - _ph_ 7y ago
        No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.
        pjmlp 7y ago
        Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work. "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
  - throwaway34241 7y ago
    I'm not sure what GP meant by real world issues, but they do have some specific constraints that they want their implementation of generics to achieve, one of the core team members tried to nail down the details over a period of years but there were issues with the previous proposals before the latest one. So I don't think the issue is parametric polymorphism or not, it's more about things like keeping fast compile times, avoiding boxing value types, etc.
  - baby 7y ago
    It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.
    - erik_seaberg 7y ago
      Uses of https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.
      - baby 7y ago
        Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.
  - karmakaze 7y ago
    The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void. Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.
fileeditview 7y ago
Absolutely agree.. look what happened to C++ over the last decade(s).
- 72deluxe 7y ago
  Not sure - I thought it got significantly better with C++11/14? Admittedly it also became rather more complicated, but the changes were generally for the best I thought?
  - lasagnaphil 7y ago
    From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...
    - 0815test 7y ago
      > From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me... This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit .clone() operations, like in some other languages, or the move construct can implicitly copy when the type is a POD-equivalent that makes this possible (identified by the Copy "trait"). Very simple, and nothing like the whole C++ move mess.
      - 72deluxe 7y ago
        So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.
        7y ago
ehsankia 7y ago
Is there any example of a successful large open source project that's truly lead by the community, and not a handful of people that decide what goes in and what doesn't? What would such a model even look like?
- kkarakk 7y ago
  you can see it already on github - survival of the fittest fork
  - Cthulhu_ 7y ago
    In theory yes, in practice though, there's a lot of projects where the lead maintainer has vanished or doesn't spend a lot of time on it anymore making the future of the whole project and its forks debatable. Most forks aren't interested in taking the lead. The only exception I can think of was the nodejs fork, IO.js, which ended up being more of a political move and a kick up the arse for the Node team. A similar kick was given to the NPM team when Yarn started making waves.
    - jon-wood 7y ago
      The Rails/Murb drama a few years ago is another good example I think. A bunch of people decided they didn’t like the directions Rails was going in, created a competing framework, and after proving the concept was sound ended up introducing a lot of the unique features back into what became Rails 3.
- PrototypeNM1 7y ago
  I think the key component of such a model is a clearly communicated method where the community can participate in the project direction, and evidence that the method is being respected. It's been brought up in this thread but Rust's governance/RFC process comes to mind. https://www.rust-lang.org/governance https://www.rust-lang.org/governance
rob74 7y ago
My thoughts exactly! It's important to have a community and to work with it, but, especially for a programming language, there has to be a clear concept of which features should be implemented and which not - just accepting community contributions for the sake of making the community feel good would be the wrong way. Otherwise you end up with a feature monster like innumerable other programming languages, and that's exactly what Go doesn't want to be.
- sam_lowry_ 7y ago
  Go is somewhere in the middle of the spectrum between Lua (dictatorship) and C++ (endless politicking).
- baby 7y ago
  My fear is that they end up integrating generics just to please some vocal group of java/c++ programmers.
szuze 7y ago
If you give Go to the community, the community will add exceptions... yuck.
- josefx 7y ago
  Go already has panic/recover which where explicitly proposed as an exception like mechanism for go.
  - BrandoElFollito 7y ago
    The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. -- https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)
- baby 7y ago
  And generics, ew

by pa7ch 7y ago

theshrike79 7y ago

In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.

crimsonalucard 7y ago
Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.
- nnq 7y ago
  > Parametric polymorphism is a real world issue. ...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.
  - masklinn 7y ago
    > ...what in the world makes you thing that? Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.
    - foldr 7y ago
      Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
      - masklinn 7y ago
        > Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
        foldr 7y ago
        According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". >Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths. This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
  - calcifer 7y ago
    > but nothing stops you from writing the most complex computer programs you can imagine without it. Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.
- B-Con 7y ago
  This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box. Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.
  - chrisweekly 7y ago
    WAI?
    - alach11 7y ago
      I would guess Working As Intended.
    - deleted 7y ago
      [deleted]
- xyproto 7y ago
  Parametric polymorphism is a tool to solve real world issues with. It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.
- _ph_ 7y ago
  But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings. Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.
  - pjmlp 7y ago
    ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.
    - _ph_ 7y ago
      No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.
      - pjmlp 7y ago
        Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work. "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
- throwaway34241 7y ago
  I'm not sure what GP meant by real world issues, but they do have some specific constraints that they want their implementation of generics to achieve, one of the core team members tried to nail down the details over a period of years but there were issues with the previous proposals before the latest one. So I don't think the issue is parametric polymorphism or not, it's more about things like keeping fast compile times, avoiding boxing value types, etc.
- baby 7y ago
  It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.
  - erik_seaberg 7y ago
    Uses of https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.
    - baby 7y ago
      Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.
- karmakaze 7y ago
  The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void. Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.

fileeditview 7y ago

Absolutely agree.. look what happened to C++ over the last decade(s).

72deluxe 7y ago
Not sure - I thought it got significantly better with C++11/14? Admittedly it also became rather more complicated, but the changes were generally for the best I thought?
- lasagnaphil 7y ago
  From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...
  - 0815test 7y ago
    > From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me... This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit .clone() operations, like in some other languages, or the move construct can implicitly copy when the type is a POD-equivalent that makes this possible (identified by the Copy "trait"). Very simple, and nothing like the whole C++ move mess.
    - 72deluxe 7y ago
      So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.
      - 7y ago

ehsankia 7y ago

Is there any example of a successful large open source project that's truly lead by the community, and not a handful of people that decide what goes in and what doesn't? What would such a model even look like?

kkarakk 7y ago
you can see it already on github - survival of the fittest fork
- Cthulhu_ 7y ago
  In theory yes, in practice though, there's a lot of projects where the lead maintainer has vanished or doesn't spend a lot of time on it anymore making the future of the whole project and its forks debatable. Most forks aren't interested in taking the lead. The only exception I can think of was the nodejs fork, IO.js, which ended up being more of a political move and a kick up the arse for the Node team. A similar kick was given to the NPM team when Yarn started making waves.
  - jon-wood 7y ago
    The Rails/Murb drama a few years ago is another good example I think. A bunch of people decided they didn’t like the directions Rails was going in, created a competing framework, and after proving the concept was sound ended up introducing a lot of the unique features back into what became Rails 3.
PrototypeNM1 7y ago
I think the key component of such a model is a clearly communicated method where the community can participate in the project direction, and evidence that the method is being respected. It's been brought up in this thread but Rust's governance/RFC process comes to mind. https://www.rust-lang.org/governance https://www.rust-lang.org/governance

rob74 7y ago

My thoughts exactly! It's important to have a community and to work with it, but, especially for a programming language, there has to be a clear concept of which features should be implemented and which not - just accepting community contributions for the sake of making the community feel good would be the wrong way. Otherwise you end up with a feature monster like innumerable other programming languages, and that's exactly what Go doesn't want to be.

sam_lowry_ 7y ago
Go is somewhere in the middle of the spectrum between Lua (dictatorship) and C++ (endless politicking).
baby 7y ago
My fear is that they end up integrating generics just to please some vocal group of java/c++ programmers.

szuze 7y ago

If you give Go to the community, the community will add exceptions... yuck.

josefx 7y ago
Go already has panic/recover which where explicitly proposed as an exception like mechanism for go.
- BrandoElFollito 7y ago
  The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. -- https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)
baby 7y ago
And generics, ew