5 ms·

Huge news! I hope the new leadership remembers that keeping golang small and simple was its greatest strength. Adding generics was too much, and while I think t

Huge news! I hope the new leadership remembers that keeping golang small and simple was its greatest strength. Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't. I'd also like to see less google control of the project. I'm certainly thankful for golang as it made my https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ project possible! Thanks Russ!

simonz05 2y ago
> I'd also like to see less google control of the project. That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.
- rsc 2y ago
  > Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google. I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
  - simonz05 2y ago
    I understand and respect your perspective on Austin and Cherry’s involvement in the Go community. Their contributions may indeed be less visible but still impactful. However, the community’s perception of leadership is crucial, and visibility plays a big part in that. For instance your long form blog adds context to decisions you’ve taken in the past. I hope their active roles will become more apparent, fostering a stronger connection with the broader Go community.
arp242 2y ago
> I'd also like to see less google control of the project. What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.
- purpleidea 2y ago
  They could be a non-google employee. They could let the community vote on who new leaders are, etc...
  - arp242 2y ago
    > They could let the community vote on who new leaders are, etc... Who is "they"? Who is "the community"? Who qualifies for a vote and who doesn't? I never contributed any code to the Go compiler or stdlib, but have contributed to some aspects of the "wider ecosystem", including some things that see fairly broad usage, and am (coincidentally) wearing a 2018 GopherCon t-shirt as I write this. Do I qualify? Does someone who has been writing Go for a year qualify? A week? Someone who never even wrote Go code? Someone who sent in a single patch to stdlib? And how do you verify all this? Saying "let the community vote" is easy, but if you think about it for more than a second you will realize there's tons of difficulties and that it doesn't really work. I also don't really know of any project that works like this: it's pretty always a fairly small group of "core contributors" that get to decide.
    - tempest_ 2y ago
      What do you mean it doesnt really work? There are a large number of programming languages and open source projects and a large number of approaches to this problem. Python, Postgres, Rust.. A small amount of core contributors doesn't mean they all have to come from a single corporate entity either. The notion that only Google could shepherd a programming language is hilarious.
      - arp242 2y ago
        > The notion that only Google could shepherd a programming language is hilarious. I never said anything of the sort. I said that "let the community vote on who new leaders are" doesn't work. Python, PostgreSQL, and Rust don't work like that either; it's just members of a fairly small "core team" that can vote, or some variant thereof. I have no inside knowledge here, but I'll stake a good amount of money that the Go core team had a lot of discussions about this, and de-facto, it's more or less the same as having a vote – except maybe a bit less formal. And Go would obviously be fine without Google, just as Rust was fine without Mozilla. But why bother? It's working fine as it is and Google wants to spend the money on developer salaries, so why not let them? People get far too hung up on "Google bad". I say this as someone who doesn't even have a Google account or Chrome installed.
dblohm7 2y ago
> Adding generics was too much I strongly disagree. Sure, like anything in programming, generics can be misused. But even comments can be misused! OTOH I am able to build things in Go with generics that I would not be very happy building without them.
- nasretdinov 2y ago
  Yeah I agree. Due to Go's slow moving approach we'll see the biggest impact of generics much later, when they become more prominent in the standard library. A lot of those APIs are necessarily not type safe now and generics would close that gap quite nicely
- gary_0 2y ago
  The thing people dislike, I think, is that actually implementing generics and handling all the syntactical and compilation edge cases is complicated and ugly. But generics as a high-level concept are wonderfully simple and useful ("let me use different types with certain code constructs without having to manually duplicate them, and stop me from doing anything that doesn't make sense"). It would be a far easier call for languages to add them if they were just a bit of syntactic sugar instead of a whole new section in the manual. (I do think adding generics was a good call; practicality trumps a fussily clean design, in my book.)
- jen20 2y ago
  > But even comments can be misused! And arguably are in Go, where they are used for all kinds of things that are not inline documentation!
  - fuzztester 2y ago
    examples of that? code generation? been away from go for a while, after using it some earlier, so not up to date
p1necone 2y ago
> Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't. Strongly disagree. Beyond very simple codebases lack of generics means either duplicating a bunch of code or eschewing type safety - neither of those things are particularly attractive to me. I can't imagine writing code in a strongly typed language that doesn't have support for generics. Even if you don't use them directly it's almost certain you're using libraries that would be forced to be less ergonomic or type safe because of a lack of generics.
- akira2501 2y ago
  > or eschewing type safety Type casts are checked. > that doesn't have support for generics. We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable. > or type safe because of a lack of generics. Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable. That being said, the generic version is faster and easier to use, so they are not without purpose, but they're not fundamental to large scale design either. Used without caution they can become a burden in and of themselves. I like them just fine, but I could completely live without them.
  - zarzavat 2y ago
    BTW this kind of thing is why I don’t use Go. Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.
    - illusive4080 2y ago
      This is why I prefer Rust over Go. Go is far too simple.
    - akira2501 2y ago
      > needs a lot more features to be usable I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers. > and makes developing in it a miserable experience. Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on. I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.

simonz05 2y ago

> I'd also like to see less google control of the project. That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.

rsc 2y ago
> Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google. I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
- simonz05 2y ago
  I understand and respect your perspective on Austin and Cherry’s involvement in the Go community. Their contributions may indeed be less visible but still impactful. However, the community’s perception of leadership is crucial, and visibility plays a big part in that. For instance your long form blog adds context to decisions you’ve taken in the past. I hope their active roles will become more apparent, fostering a stronger connection with the broader Go community.

arp242 2y ago

> I'd also like to see less google control of the project. What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.

purpleidea 2y ago
They could be a non-google employee. They could let the community vote on who new leaders are, etc...
- arp242 2y ago
  > They could let the community vote on who new leaders are, etc... Who is "they"? Who is "the community"? Who qualifies for a vote and who doesn't? I never contributed any code to the Go compiler or stdlib, but have contributed to some aspects of the "wider ecosystem", including some things that see fairly broad usage, and am (coincidentally) wearing a 2018 GopherCon t-shirt as I write this. Do I qualify? Does someone who has been writing Go for a year qualify? A week? Someone who never even wrote Go code? Someone who sent in a single patch to stdlib? And how do you verify all this? Saying "let the community vote" is easy, but if you think about it for more than a second you will realize there's tons of difficulties and that it doesn't really work. I also don't really know of any project that works like this: it's pretty always a fairly small group of "core contributors" that get to decide.
  - tempest_ 2y ago
    What do you mean it doesnt really work? There are a large number of programming languages and open source projects and a large number of approaches to this problem. Python, Postgres, Rust.. A small amount of core contributors doesn't mean they all have to come from a single corporate entity either. The notion that only Google could shepherd a programming language is hilarious.
    - arp242 2y ago
      > The notion that only Google could shepherd a programming language is hilarious. I never said anything of the sort. I said that "let the community vote on who new leaders are" doesn't work. Python, PostgreSQL, and Rust don't work like that either; it's just members of a fairly small "core team" that can vote, or some variant thereof. I have no inside knowledge here, but I'll stake a good amount of money that the Go core team had a lot of discussions about this, and de-facto, it's more or less the same as having a vote – except maybe a bit less formal. And Go would obviously be fine without Google, just as Rust was fine without Mozilla. But why bother? It's working fine as it is and Google wants to spend the money on developer salaries, so why not let them? People get far too hung up on "Google bad". I say this as someone who doesn't even have a Google account or Chrome installed.

dblohm7 2y ago

> Adding generics was too much I strongly disagree. Sure, like anything in programming, generics can be misused. But even comments can be misused! OTOH I am able to build things in Go with generics that I would not be very happy building without them.

nasretdinov 2y ago
Yeah I agree. Due to Go's slow moving approach we'll see the biggest impact of generics much later, when they become more prominent in the standard library. A lot of those APIs are necessarily not type safe now and generics would close that gap quite nicely
gary_0 2y ago
The thing people dislike, I think, is that actually implementing generics and handling all the syntactical and compilation edge cases is complicated and ugly. But generics as a high-level concept are wonderfully simple and useful ("let me use different types with certain code constructs without having to manually duplicate them, and stop me from doing anything that doesn't make sense"). It would be a far easier call for languages to add them if they were just a bit of syntactic sugar instead of a whole new section in the manual. (I do think adding generics was a good call; practicality trumps a fussily clean design, in my book.)
jen20 2y ago
> But even comments can be misused! And arguably are in Go, where they are used for all kinds of things that are not inline documentation!
- fuzztester 2y ago
  examples of that? code generation? been away from go for a while, after using it some earlier, so not up to date

p1necone 2y ago

> Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't. Strongly disagree. Beyond very simple codebases lack of generics means either duplicating a bunch of code or eschewing type safety - neither of those things are particularly attractive to me. I can't imagine writing code in a strongly typed language that doesn't have support for generics. Even if you don't use them directly it's almost certain you're using libraries that would be forced to be less ergonomic or type safe because of a lack of generics.

akira2501 2y ago
> or eschewing type safety Type casts are checked. > that doesn't have support for generics. We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable. > or type safe because of a lack of generics. Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable. That being said, the generic version is faster and easier to use, so they are not without purpose, but they're not fundamental to large scale design either. Used without caution they can become a burden in and of themselves. I like them just fine, but I could completely live without them.
- zarzavat 2y ago
  BTW this kind of thing is why I don’t use Go. Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.
  - illusive4080 2y ago
    This is why I prefer Rust over Go. Go is far too simple.
  - akira2501 2y ago
    > needs a lot more features to be usable I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers. > and makes developing in it a miserable experience. Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on. I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.