10 ms·

Go Type Parameters – Draft Design

183 points by wwarner 6y ago

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
leric 6y ago
finally
barnacled 6y ago
While I am a fan of go and like it's simplicity it does sadden me the degree to which it is a 100% google project on any significant change like this. It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. I worked on the compiler in 2011 as an open source contributor and firmly got this impression back then which seriously put me off and the absolute farce of how modules were handled (community heavily involved put a ton of work in then out of nowhere Russ Cox just did his own thing anyway) suggests to me nothing has changed. Generics have been heavily discussed and desired from the beginning of the language and many have contributed thoughts and concepts. At first the designers said more or less 'nope not needed' which changed to 'if somebody suggests a good implementation we will do it'. But would they really? If this design document had come from outside the go team would they even give it a glance? I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary.
- coldtea 6y ago
  Go appears to be whatever the very small core team says. The rest of the community can help with some (not basic) tooling and libraries, at best.
  - barnacled 6y ago
    The thing is I wouldn't mind that and maybe that is what a programming language needs, but they constantly suggest otherwise. The modules situation was pretty shocking to me. Just tell everybody this is how it is and it's all good. I wonder how many people have wasted time suggesting more significant features/changes under the impression they would be listened to?
- serial_dev 6y ago
  > It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. While it's might be true that most big changes come from the core team, open source doesn't mean that they have the obligation to merge (and support) extra features they don't think is necessary. Simplicity doesn't just happen, it happens because they reject code that increases complexity and would need to supported and maintained.
  - barnacled 6y ago
    No, not most, all. Projects like the Linux kernel are equally highly selective and reject code that they don't like big or small, but they do at least sometimes accept significant changes. As I responded in another comment, I accept that might be necessary to maintain the approach of the language but the go team seriously misrepresent this. That is my main issue with them. How many people have put a lot of work in only to find out that actually the go team aren't accepting significant patches? Look to the go modules fiasco for a good example of this. Honesty matters.
    - clktmr 6y ago
      The Linux kernel is very different in this regard. Changes can be reverted easily. A change to the Go language will propagate quickly in it's users projects and probably stick with you forever.
      - a1369209993 6y ago
        > The Linux kernel is very different in this regard. Changes can be reverted easily. Only if nothing in userspace (the equivalent of "[Go]'s users projects") has started to depend on it. A OS kernel is perhaps slower than a programming language to see uptake of new features, but the dependencies are still there.
      - barnacled 6y ago
        Sure, but as I've said a couple times already, the issue is that the go team have indicated they _would_ accept major changes (they explicitly said they would on generics for a long while, which I suggest is just not true, and actually had people work on modules stuff then just stiffed them with their own solution - See Sam Boyer's (long) twitter thread on the whole go dep thing - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713). Either they should say 'nope the BDFL accepts nothing significant except from the go core team' or they should change their ways. You can't have both. Obviously other languages do manage the balance - eg. python, rust, so it's possible but I totally accept that given go's minimalism and opinionated approach they might not want that. But be honest about it. And good luck reverting a released kernel buried on a server :) especially once users start relying on e.g. a syscall. You might find that it's not quite as different as you want it to be...
- 02020202 6y ago
  i am no fan of gulag and i do not like the ties of go to gulag but i think it is not as bad as gulag monopolizing the web browser industry. also i think that people running the project are way smarter than any of us and the community argument is not a good one, for me. because if someone does not do the gatekeeping the language would become yet another bloated "modern" monstrostity with all the batteries included. also i think a programming language should not even have a community when it comes to development. it should all scientifics papers and top brains working on it and not anyone with github account. since this is the most basic brick in the entire software chain, there is no place for politics, feelings, quick fixes and cleverness. the language should be a "perfect" too that does only one thing but it does it incredibly well.
- papaf 6y ago
  It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. It is absolutely an open source project. However, it is closer to Cathedral style development rather than Bazaar [1]. [1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
  - barnacled 6y ago
    that's why I said 'in the sense of most other major OSS projects' :) Most well-known projects operate in the bazaar model and the Go team claim to also but in fact are operating a cathedral.
- geodel 6y ago
  Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. > I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary. To me it seems like nature of things. People who are talented and in control are just not going to take any contribution come their way. For people outside if their thinking aligned with core team they will feel welcome and others will feel unwelcome due to high handedness of core team.
  - Cthulhu_ 6y ago
    I dunno about Java, it's often cited as a design-by-committee failure of a language, and it took years to escape it. It did not have a singular owner but a number of very large, very bureaucratic and very rich companies with vested interests. In my outsider's perspective, this caused the language to effectively deadlock for the better part of a decade. Go in the meantime is chooching along gradually, trying hard not to do anything too big in one go. Modules was the big thing this year, and people are still adjusting and transitioning. Generics MIGHT be the next big thing (idk if the draft design is finished, approved, and work on implementing it is underway). But they spent years considering, humming and hawing, objecting, polling and reconsidering this particular one. They could have pushed for it much harder and much earlier on, but they wanted for the language to settle first, for use cases to be discovered, etc. They learned from the past, e.g. Java's implementation, and how it added so much complexity to the language spec, compiler, and all the build tooling - which they really wanted to avoid, because of the use cases of Go as a language and the problems it wanted to avoid (including complicated and slow compilation).
    - geodel 6y ago
      Java had /EE part which was much more designed by committee. Oracle last year dumped that on to Eclipse foundation. Now Java release is every 6 months like Go and it looks lot less designed by committee.
  - yakubin 6y ago
    > Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. How is that true about Rust? Mozilla fired people working on Rust. Now there's a foundation and from the looks of it there are lots of contributions from individual contributors coming through GitHub.
- tacitusarc 6y ago
  I remember reading the proposal from a couple years back and disliking it immensely. I and many others left feedback to that effect, and this updated draft document reflects that feedback. I think the go team has messed up packaging because they didn't correctly understand the problem space, but the multi-year effort to deeply understand parametric polymorphism means this draft is actually quite reasonable. I, for one, am excited for this addition to the language.
- yencabulator 6y ago
  godep deserved to be scrapped for purely technical reasons (no matter how much the people who wrote it whine about it). Do you have a second example?
cientifico 6y ago
I miss on this kind of design draft a literal diff to the language spec. The go language spec is one of my favorite things about go. Is a learnxiny on steroids. In less than an hour, you fully understand the language. I am curious to see how this functionality will change the spec. Will it double it in size?
- EE84M3i 6y ago
  Huh, what about the go spec do you like? To me it always struck me as overly casual and loose compared to other languages, and reads more like a guide.
  - yiyus 6y ago
    Any specific example of where the spec is loose?
  - dilap 6y ago
    Personally, I've never found the Go spec to be too ambiguous, and it's always answered my questions and in an easy and clear way. I'm a fan! For example, what does the following C# code print? UInt32 x = 1; UInt32 s = x >> 32; Console.WriteLine("" + s); How about the following Go code? var x uint32 = 1 var s uint32 = x >> 32 fmt.Println(s) I can easily answer the question for Go looking at the Go spec, but I cannot seem to find anywhere documented in the C# spec its (more surprising) behavior.
    - Someone 6y ago
      What’s missing in https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#shift-operators https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...? “For the predefined operators, the number of bits to shift is computed as follows: - When the type of x is int or uint, the shift count is given by the low-order five bits of count. In other words, the shift count is computed from count & 0x1F. - When the type of x is long or ulong, the shift count is given by the low-order six bits of count. In other words, the shift count is computed from count & 0x3F.”
gwd 6y ago
What's interesting about this design is that with one minor relaxation, the "type list in an interface" could become one of the other big things that Go is missing; namely, sum types: > Interface types with type lists may only be used as constraints on type parameters. They may not be used as ordinary interface types. ...This restriction may be lifted in future language versions. An interface type with a type list may be useful as a form of sum type, albeit one that can have the value nil.
- yiyus 6y ago
  There is an active discussion about this on in the issue tracker: https://github.com/golang/go/issues/41716 https://github.com/golang/go/issues/41716 It looks like there is a willingness to do this, but not a clear solution yet.
  - wwarner 6y ago
    Oh that's awesome.
gfaure 6y ago
This reminded me of a certain creative "solution" to the lack of generics in Go: https://old.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://old.reddit.com/r/rust/comments/5penft/parallelizing_...
coldtea 6y ago
A Golang with generic and algebraic types, and Optionals would be close to a great pragmatic language with not much fluff... One can dream...
- lf-non 6y ago
  The V language seems to be exactly this combination: https://vlang.io https://vlang.io. It is not as stable/mature - but well, its open source.
  - pansa2 6y ago
    V is for Vaporware. https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
    - hu3 6y ago
      That post is from 2019-6. I don't know how the v repo looked at that time but just in the last 7 days it had 19 Pull Requests authored by 11 different people merged. Along other strong activity indicators. https://github.com/vlang/v/pulse https://github.com/vlang/v/pulse That's gotta be the most active vapoware project I've seen to date.
    - capableweb 6y ago
      That article seems OK on it's own, but what a weird title, it's not at all supported by the article. Nothing in the article says vaporware or describes anything that could be said to be vaporware. V could maybe use "misleading marketing" at best, but it's in no way vaporware, as if it was, the author would not be able to perform all the things they did in the blogpost. It's also over a year old, would love to see the author to revisit the claims of V like they did in the post, but with the latest versions.
    - gnufied 6y ago
      I can't speak for other stuff in the blog but it does not depend on libcurl anymore at least and has its own http implementation.
erik_seaberg 6y ago
This is well thought out, especially the “Omissions” section that explains what’s not in scope. I wish they had defined a constraint for types that have a usable zero value that doesn’t immediately blow up (like maps and struct pointers). > That may in turn lead to pressure to modify the language to add some mechanism for using an Iterator with the range clause. Yes please, there’s so much grammar that just refuses to support any user-defined type.
- ignoramous 6y ago
  > Yes please, there’s so much grammar that just refuses to support any user-defined type. Nothing embodies "the tale of two cities" esque paradox like Go does. If you're a programmer, Go is so simple that it isn't easy to do anything but the simplest thing.
  - tptacek 6y ago
    Go is so simple that it usually doesn't make sense to express things in anything but simple terms. What surprised me about working in that kind of environment was how much it freed me to be creative about my algorithms and problem domain, rather than how concisely I was describing boring algorithms. I work mostly in Rust now, and that's a property I miss about Go.
    - ignoramous 6y ago
      > ...freed me to be creative about my algorithms and problem domain, rather than how concisely I was describing boring algorithms. Agree. I dabble in Kotlin and Golang at work. Those languages can't be further apart. I occasionally need to read Rust code, but it has been a struggle compared to how easy it is to read Go.
    - kibwen 6y ago
      Fascinated to hear that you're using Rust in any capacity, from your comment history I assumed you were mostly Go. What domain, can I ask? Security research, cryptography?
jhoechtl 6y ago
I like that they are exploring ways which are not comparable to the way it's done in other languages: > Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same. Many critics complained in the past that Go ignores language resaerch results of decades. Thats true for a certain extend but in the same time they are exploring new ways to approach language design problems.
- yxhuvud 6y ago
  Sure, that part is good and in some cases their approach has improved the state of the art (adding an automatic formatter to the language is perhaps the most obvious?), but at the same time I'm happy to use another language and not be a labrat, because not all the choices have been great.
  - clktmr 6y ago
    Go is one of the most stable languages maintaining backwards compatibility since it's creation. Calling it's users labrats because you disagree with some decisions is totally misleading.
    - solidasparagus 6y ago
      I think it’s fair to call the users labrats - it’s not really impugning on Go’s good history of backwards compatibility. Golang has done some real experimenting with what a programming language should be, and while some of the ideas have turned out great (a language designed for large teams of junior software engineers), others have been so-so (IMO error handling) while others have been massive mistakes (dependency management).
      - AnimalMuppet 6y ago
        OK, that may have been true a decade ago. But at this point you're not being a labrat. You're not being experimented on. Go has made design choices, you know what they are, and you know most of the upsides and downsides of those choices. You know what you're getting into. If it has value for you, use it. If not, use something else.
sagitariusrex 6y ago
Revolutionary technology right here lads. This is what happens when you ignore the entire history of programming languages and all the lessons learned along the way. You end up with a proposal to add type parameters, 8 or so years after its release.
- ghthor 6y ago
  Thanks for you contribution.
- valenterry 6y ago
  True
- Cthulhu_ 6y ago
  Java took 8 or so years to add generics to its language, what's your point? They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics There's a trend going on in the past decade or so where every language goes to adopt features from other languages, adding complexity without actually solving a problem other than "I use this feature in language X, why doesn't YOUR language have it?" Which lead to pretty shitty decisions, like half implementations of OOP in PHP and Javascript (have some classes, but not access modifiers), functional programming in Java, or every paradigm ever invented all at the same time in Scala.
  - hajile 6y ago
    > They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics That's simply not true. Languages like StandardML, Ocaml, or Haskell have already solved the major issues 40 years ago with types vastly superior to what go offers. Since then, nothing has come even close to that level of utility and usability. Like so many other things in go, it seems a combination of Hubris and NIH syndrome.
znpy 6y ago
Since we're talking Go, is "The Go Programming Language" still worth reading as an introduction to the language? I've seen some language changes be announced in the past, can't asses on my own how breaking they are, does the book still reflect the language to a reasonable degree ?
- benhoyt 6y ago
  Yes, most definitely. It's an excellent book, and the language has changed almost zero (the libraries a little, but not enough to worry about). The only addition that might be nice would be "modules". Link for the lazy: https://www.gopl.io/ https://www.gopl.io/
  - znpy 6y ago
    Thanks!
  - ghthor 6y ago
    Is Context discussed in that book? It's a pretty big game changer when writing concurrent algorithms.
    - Cthulhu_ 6y ago
      It's an important concept to learn nowadays, but it's not a language change; it's more of a design pattern adopted across Go's API.
_old_dude_ 6y ago
It's far better than the previous drafts, another couple of drafts and it will be very good. I think that listing the possible types with "type" inside an interface is a mistake. It means that instead of providing builtin interfaces for existing primitive types, Go asks its users to list the primitive types in user defined interfaces. This will not go well if at some point in a future, the Go team want to add a new primitive type because the user codes will need to be upgraded. And not providing inference when directly referencing a function is a weird choice (see section Type inference for generic function arguments).
- marcus_holmes 6y ago
  Agree. I think it'd be preferable to provide instances for existing primitives, even if those would need to be "special" to work (there's already "special" cases in the language for primitives, it's no biggy).
- yencabulator 6y ago
  The problem with defining `numeric` somewhere, and programmer saying `interface I { numeric }` instead of `interface I { type uint8, uint16, blahblah }` is that the idea is to have exhaustive type switches for those: > This kind of type switch would only be permitted if the constraint lists explicit types, and only types listed in the constraint would be permitted as cases. So adding a new primitive type `uint128` to `numeric` would break all that code anyway: they would no longer be exhaustive type switches. Putting the programmer in charge means they can add support for `uint128` in the library at any time after the language change. I think type inference for generic function arguments is intentionally postponed to have a more reasonably-sized change going in first. It can be added later, making the explicit type parameter optional.
physicles 6y ago
I’m so glad they dispensed with the “constraint” language construct from earlier drafts, and just folded it into “interface”. The solution for supporting < and > — or rather, continuing to support them only for built-in types — feels powerful enough without introducing full-on operator overloading. If I read correctly, this does mean we’ll still need multiple versions of some common functions like min/max depending on whether the type is a built-in or something else that’s comparable (like bigint.Num or time.Time), but that feels ok to me. I wonder how the standard library will accommodate this — perhaps you just redefine math.Max to be generic, since such a change would be backwards-compatible for the vast majority of uses. Like other posters, I’d also appreciate support for user-defined types in language constructs like for..range and [ ], but that’s orthogonal to generics and can be added in a later 2.x revision (just need to define a built-in constraint-interface for these).

183 points by wwarner 6y ago

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

leric 6y ago

finally

barnacled 6y ago

While I am a fan of go and like it's simplicity it does sadden me the degree to which it is a 100% google project on any significant change like this. It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. I worked on the compiler in 2011 as an open source contributor and firmly got this impression back then which seriously put me off and the absolute farce of how modules were handled (community heavily involved put a ton of work in then out of nowhere Russ Cox just did his own thing anyway) suggests to me nothing has changed. Generics have been heavily discussed and desired from the beginning of the language and many have contributed thoughts and concepts. At first the designers said more or less 'nope not needed' which changed to 'if somebody suggests a good implementation we will do it'. But would they really? If this design document had come from outside the go team would they even give it a glance? I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary.

coldtea 6y ago
Go appears to be whatever the very small core team says. The rest of the community can help with some (not basic) tooling and libraries, at best.
- barnacled 6y ago
  The thing is I wouldn't mind that and maybe that is what a programming language needs, but they constantly suggest otherwise. The modules situation was pretty shocking to me. Just tell everybody this is how it is and it's all good. I wonder how many people have wasted time suggesting more significant features/changes under the impression they would be listened to?
serial_dev 6y ago
> It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. While it's might be true that most big changes come from the core team, open source doesn't mean that they have the obligation to merge (and support) extra features they don't think is necessary. Simplicity doesn't just happen, it happens because they reject code that increases complexity and would need to supported and maintained.
- barnacled 6y ago
  No, not most, all. Projects like the Linux kernel are equally highly selective and reject code that they don't like big or small, but they do at least sometimes accept significant changes. As I responded in another comment, I accept that might be necessary to maintain the approach of the language but the go team seriously misrepresent this. That is my main issue with them. How many people have put a lot of work in only to find out that actually the go team aren't accepting significant patches? Look to the go modules fiasco for a good example of this. Honesty matters.
  - clktmr 6y ago
    The Linux kernel is very different in this regard. Changes can be reverted easily. A change to the Go language will propagate quickly in it's users projects and probably stick with you forever.
    - a1369209993 6y ago
      > The Linux kernel is very different in this regard. Changes can be reverted easily. Only if nothing in userspace (the equivalent of "[Go]'s users projects") has started to depend on it. A OS kernel is perhaps slower than a programming language to see uptake of new features, but the dependencies are still there.
    - barnacled 6y ago
      Sure, but as I've said a couple times already, the issue is that the go team have indicated they _would_ accept major changes (they explicitly said they would on generics for a long while, which I suggest is just not true, and actually had people work on modules stuff then just stiffed them with their own solution - See Sam Boyer's (long) twitter thread on the whole go dep thing - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713). Either they should say 'nope the BDFL accepts nothing significant except from the go core team' or they should change their ways. You can't have both. Obviously other languages do manage the balance - eg. python, rust, so it's possible but I totally accept that given go's minimalism and opinionated approach they might not want that. But be honest about it. And good luck reverting a released kernel buried on a server :) especially once users start relying on e.g. a syscall. You might find that it's not quite as different as you want it to be...
02020202 6y ago
i am no fan of gulag and i do not like the ties of go to gulag but i think it is not as bad as gulag monopolizing the web browser industry. also i think that people running the project are way smarter than any of us and the community argument is not a good one, for me. because if someone does not do the gatekeeping the language would become yet another bloated "modern" monstrostity with all the batteries included. also i think a programming language should not even have a community when it comes to development. it should all scientifics papers and top brains working on it and not anyone with github account. since this is the most basic brick in the entire software chain, there is no place for politics, feelings, quick fixes and cleverness. the language should be a "perfect" too that does only one thing but it does it incredibly well.
papaf 6y ago
It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. It is absolutely an open source project. However, it is closer to Cathedral style development rather than Bazaar [1]. [1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
- barnacled 6y ago
  that's why I said 'in the sense of most other major OSS projects' :) Most well-known projects operate in the bazaar model and the Go team claim to also but in fact are operating a cathedral.
geodel 6y ago
Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. > I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary. To me it seems like nature of things. People who are talented and in control are just not going to take any contribution come their way. For people outside if their thinking aligned with core team they will feel welcome and others will feel unwelcome due to high handedness of core team.
- Cthulhu_ 6y ago
  I dunno about Java, it's often cited as a design-by-committee failure of a language, and it took years to escape it. It did not have a singular owner but a number of very large, very bureaucratic and very rich companies with vested interests. In my outsider's perspective, this caused the language to effectively deadlock for the better part of a decade. Go in the meantime is chooching along gradually, trying hard not to do anything too big in one go. Modules was the big thing this year, and people are still adjusting and transitioning. Generics MIGHT be the next big thing (idk if the draft design is finished, approved, and work on implementing it is underway). But they spent years considering, humming and hawing, objecting, polling and reconsidering this particular one. They could have pushed for it much harder and much earlier on, but they wanted for the language to settle first, for use cases to be discovered, etc. They learned from the past, e.g. Java's implementation, and how it added so much complexity to the language spec, compiler, and all the build tooling - which they really wanted to avoid, because of the use cases of Go as a language and the problems it wanted to avoid (including complicated and slow compilation).
  - geodel 6y ago
    Java had /EE part which was much more designed by committee. Oracle last year dumped that on to Eclipse foundation. Now Java release is every 6 months like Go and it looks lot less designed by committee.
- yakubin 6y ago
  > Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. How is that true about Rust? Mozilla fired people working on Rust. Now there's a foundation and from the looks of it there are lots of contributions from individual contributors coming through GitHub.
tacitusarc 6y ago
I remember reading the proposal from a couple years back and disliking it immensely. I and many others left feedback to that effect, and this updated draft document reflects that feedback. I think the go team has messed up packaging because they didn't correctly understand the problem space, but the multi-year effort to deeply understand parametric polymorphism means this draft is actually quite reasonable. I, for one, am excited for this addition to the language.
yencabulator 6y ago
godep deserved to be scrapped for purely technical reasons (no matter how much the people who wrote it whine about it). Do you have a second example?

cientifico 6y ago

I miss on this kind of design draft a literal diff to the language spec. The go language spec is one of my favorite things about go. Is a learnxiny on steroids. In less than an hour, you fully understand the language. I am curious to see how this functionality will change the spec. Will it double it in size?

EE84M3i 6y ago
Huh, what about the go spec do you like? To me it always struck me as overly casual and loose compared to other languages, and reads more like a guide.
- yiyus 6y ago
  Any specific example of where the spec is loose?
- dilap 6y ago
  Personally, I've never found the Go spec to be too ambiguous, and it's always answered my questions and in an easy and clear way. I'm a fan! For example, what does the following C# code print? UInt32 x = 1; UInt32 s = x >> 32; Console.WriteLine("" + s); How about the following Go code? var x uint32 = 1 var s uint32 = x >> 32 fmt.Println(s) I can easily answer the question for Go looking at the Go spec, but I cannot seem to find anywhere documented in the C# spec its (more surprising) behavior.
  - Someone 6y ago
    What’s missing in https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#shift-operators https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...? “For the predefined operators, the number of bits to shift is computed as follows: - When the type of x is int or uint, the shift count is given by the low-order five bits of count. In other words, the shift count is computed from count & 0x1F. - When the type of x is long or ulong, the shift count is given by the low-order six bits of count. In other words, the shift count is computed from count & 0x3F.”

gwd 6y ago

What's interesting about this design is that with one minor relaxation, the "type list in an interface" could become one of the other big things that Go is missing; namely, sum types: > Interface types with type lists may only be used as constraints on type parameters. They may not be used as ordinary interface types. ...This restriction may be lifted in future language versions. An interface type with a type list may be useful as a form of sum type, albeit one that can have the value nil.

yiyus 6y ago
There is an active discussion about this on in the issue tracker: https://github.com/golang/go/issues/41716 https://github.com/golang/go/issues/41716 It looks like there is a willingness to do this, but not a clear solution yet.
- wwarner 6y ago
  Oh that's awesome.

gfaure 6y ago

This reminded me of a certain creative "solution" to the lack of generics in Go: https://old.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://old.reddit.com/r/rust/comments/5penft/parallelizing_...

coldtea 6y ago

A Golang with generic and algebraic types, and Optionals would be close to a great pragmatic language with not much fluff... One can dream...

lf-non 6y ago
The V language seems to be exactly this combination: https://vlang.io https://vlang.io. It is not as stable/mature - but well, its open source.
- pansa2 6y ago
  V is for Vaporware. https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
  - hu3 6y ago
    That post is from 2019-6. I don't know how the v repo looked at that time but just in the last 7 days it had 19 Pull Requests authored by 11 different people merged. Along other strong activity indicators. https://github.com/vlang/v/pulse https://github.com/vlang/v/pulse That's gotta be the most active vapoware project I've seen to date.
  - capableweb 6y ago
    That article seems OK on it's own, but what a weird title, it's not at all supported by the article. Nothing in the article says vaporware or describes anything that could be said to be vaporware. V could maybe use "misleading marketing" at best, but it's in no way vaporware, as if it was, the author would not be able to perform all the things they did in the blogpost. It's also over a year old, would love to see the author to revisit the claims of V like they did in the post, but with the latest versions.
  - gnufied 6y ago
    I can't speak for other stuff in the blog but it does not depend on libcurl anymore at least and has its own http implementation.

erik_seaberg 6y ago

This is well thought out, especially the “Omissions” section that explains what’s not in scope. I wish they had defined a constraint for types that have a usable zero value that doesn’t immediately blow up (like maps and struct pointers). > That may in turn lead to pressure to modify the language to add some mechanism for using an Iterator with the range clause. Yes please, there’s so much grammar that just refuses to support any user-defined type.

ignoramous 6y ago
> Yes please, there’s so much grammar that just refuses to support any user-defined type. Nothing embodies "the tale of two cities" esque paradox like Go does. If you're a programmer, Go is so simple that it isn't easy to do anything but the simplest thing.
- tptacek 6y ago
  Go is so simple that it usually doesn't make sense to express things in anything but simple terms. What surprised me about working in that kind of environment was how much it freed me to be creative about my algorithms and problem domain, rather than how concisely I was describing boring algorithms. I work mostly in Rust now, and that's a property I miss about Go.
  - ignoramous 6y ago
    > ...freed me to be creative about my algorithms and problem domain, rather than how concisely I was describing boring algorithms. Agree. I dabble in Kotlin and Golang at work. Those languages can't be further apart. I occasionally need to read Rust code, but it has been a struggle compared to how easy it is to read Go.
  - kibwen 6y ago
    Fascinated to hear that you're using Rust in any capacity, from your comment history I assumed you were mostly Go. What domain, can I ask? Security research, cryptography?

jhoechtl 6y ago

I like that they are exploring ways which are not comparable to the way it's done in other languages: > Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same. Many critics complained in the past that Go ignores language resaerch results of decades. Thats true for a certain extend but in the same time they are exploring new ways to approach language design problems.

yxhuvud 6y ago
Sure, that part is good and in some cases their approach has improved the state of the art (adding an automatic formatter to the language is perhaps the most obvious?), but at the same time I'm happy to use another language and not be a labrat, because not all the choices have been great.
- clktmr 6y ago
  Go is one of the most stable languages maintaining backwards compatibility since it's creation. Calling it's users labrats because you disagree with some decisions is totally misleading.
  - solidasparagus 6y ago
    I think it’s fair to call the users labrats - it’s not really impugning on Go’s good history of backwards compatibility. Golang has done some real experimenting with what a programming language should be, and while some of the ideas have turned out great (a language designed for large teams of junior software engineers), others have been so-so (IMO error handling) while others have been massive mistakes (dependency management).
    - AnimalMuppet 6y ago
      OK, that may have been true a decade ago. But at this point you're not being a labrat. You're not being experimented on. Go has made design choices, you know what they are, and you know most of the upsides and downsides of those choices. You know what you're getting into. If it has value for you, use it. If not, use something else.

sagitariusrex 6y ago

Revolutionary technology right here lads. This is what happens when you ignore the entire history of programming languages and all the lessons learned along the way. You end up with a proposal to add type parameters, 8 or so years after its release.

ghthor 6y ago
Thanks for you contribution.
valenterry 6y ago
True
Cthulhu_ 6y ago
Java took 8 or so years to add generics to its language, what's your point? They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics There's a trend going on in the past decade or so where every language goes to adopt features from other languages, adding complexity without actually solving a problem other than "I use this feature in language X, why doesn't YOUR language have it?" Which lead to pretty shitty decisions, like half implementations of OOP in PHP and Javascript (have some classes, but not access modifiers), functional programming in Java, or every paradigm ever invented all at the same time in Scala.
- hajile 6y ago
  > They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics That's simply not true. Languages like StandardML, Ocaml, or Haskell have already solved the major issues 40 years ago with types vastly superior to what go offers. Since then, nothing has come even close to that level of utility and usability. Like so many other things in go, it seems a combination of Hubris and NIH syndrome.

znpy 6y ago

Since we're talking Go, is "The Go Programming Language" still worth reading as an introduction to the language? I've seen some language changes be announced in the past, can't asses on my own how breaking they are, does the book still reflect the language to a reasonable degree ?

benhoyt 6y ago
Yes, most definitely. It's an excellent book, and the language has changed almost zero (the libraries a little, but not enough to worry about). The only addition that might be nice would be "modules". Link for the lazy: https://www.gopl.io/ https://www.gopl.io/
- znpy 6y ago
  Thanks!
- ghthor 6y ago
  Is Context discussed in that book? It's a pretty big game changer when writing concurrent algorithms.
  - Cthulhu_ 6y ago
    It's an important concept to learn nowadays, but it's not a language change; it's more of a design pattern adopted across Go's API.

_old_dude_ 6y ago

It's far better than the previous drafts, another couple of drafts and it will be very good. I think that listing the possible types with "type" inside an interface is a mistake. It means that instead of providing builtin interfaces for existing primitive types, Go asks its users to list the primitive types in user defined interfaces. This will not go well if at some point in a future, the Go team want to add a new primitive type because the user codes will need to be upgraded. And not providing inference when directly referencing a function is a weird choice (see section Type inference for generic function arguments).

marcus_holmes 6y ago
Agree. I think it'd be preferable to provide instances for existing primitives, even if those would need to be "special" to work (there's already "special" cases in the language for primitives, it's no biggy).
yencabulator 6y ago
The problem with defining `numeric` somewhere, and programmer saying `interface I { numeric }` instead of `interface I { type uint8, uint16, blahblah }` is that the idea is to have exhaustive type switches for those: > This kind of type switch would only be permitted if the constraint lists explicit types, and only types listed in the constraint would be permitted as cases. So adding a new primitive type `uint128` to `numeric` would break all that code anyway: they would no longer be exhaustive type switches. Putting the programmer in charge means they can add support for `uint128` in the library at any time after the language change. I think type inference for generic function arguments is intentionally postponed to have a more reasonably-sized change going in first. It can be added later, making the explicit type parameter optional.

physicles 6y ago

I’m so glad they dispensed with the “constraint” language construct from earlier drafts, and just folded it into “interface”. The solution for supporting < and > — or rather, continuing to support them only for built-in types — feels powerful enough without introducing full-on operator overloading. If I read correctly, this does mean we’ll still need multiple versions of some common functions like min/max depending on whether the type is a built-in or something else that’s comparable (like bigint.Num or time.Time), but that feels ok to me. I wonder how the standard library will accommodate this — perhaps you just redefine math.Max to be generic, since such a change would be backwards-compatible for the vast majority of uses. Like other posters, I’d also appreciate support for user-defined types in language constructs like for..range and [ ], but that’s orthogonal to generics and can be added in a later 2.x revision (just need to define a built-in constraint-interface for these).