8 ms·

This is too similar to interfaces for me and seems like it would only add to the complexity of the language, documentation, and compile time for a small increas

This is too similar to interfaces for me and seems like it would only add to the complexity of the language, documentation, and compile time for a small increase in generic code. One of Go's core strengths is simplicity. I've personally witnessed both C and Python programmers jump right into Go projects with minimal assistance. Learning new packages is absurdly easy because the code is so simple and documentation practically generates itself. I worry that widespread use of this feature would negatively impact the language in that regard. Lacking a true "generics" feature has had an influence that people tend to overlook, which is that the Go community is less reliant on dependencies. One of Go's proverbs is "A little copying is better than a little dependency" [0]. The ecosystem is better documented and healthier because of it, avoiding the require("left-pad") world of the dependency abyss. The language lends itself to being used for smaller, more concise code bases where things are written with specific and narrowly-defined purpose. It implicitly discourages "Architecture Astronauts" [1] and that strength shouldn't be overlooked or sacrificed for a few new container options. [0] https://go-proverbs.github.io/ https://go-proverbs.github.io/ [1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

woah 7y ago
Is it lack of generics that has resulted in fewer dependencies, or the incredibly full featured stdlib?
- abhchand 7y ago
  a bit of both?
quacker 7y ago
Missing generics certainly had some influence on golang, but not sure I understand your point. How does adding generics lead to a reliance on dependencies, or the absence of generics reduce reliance on dependencies? The relative lack of "dependency hell" in golang compared to other languages is because of the great standard library. Golang also never had an official/proper (imo) solution for package management until just this past year or so (although people worked around that a bit)
- skybrian 7y ago
  I think the argument is that generic code, being, well, generic, promotes reuse at an abstract level, rather than a concrete level. Abstract code can be more difficult to understand than specialized code that does only what is needed in a particular use case. I like the generics proposal, but it seems like a valid concern.
  - weberc2 7y ago
    To clarify further, I think the concern is that people will start adding dependencies for things that could be implemented concretely in a dozen lines or so, e.g., a generic slice.Map function or even a linked list. Note that this comment is not advocating for or against this proposal or generics in general; it just took me a few re-reads to understand the concern and I hope to save others some time. :)
    - throwaway34241 7y ago
      I hope that if this design is accepted they would also include some common generic types/algorithms in the standard library instead of leaving it to a 3rd party. For example an updated sync.Map (that doesn't use interface{}), some things from SliceTricks [1], or maybe the Set example (although I don't really have a problem with map[thing]struct{}, Set is arguably more clear). IMO I think having a standard library that judiciously used generics would be almost pure upside for most Go programs. Being able to do math.Sin(x) instead of float32(math.Sin(float32(x))) just seems like an improvement in every way. [1] https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
      - weberc2 7y ago
        Agreed. I think this would go a long way toward addressing the original concern.
    - erik_seaberg 7y ago
      That's exactly what needs to happen. We will never arrive at a more powerful platform by self-gratification and refusing to stand on each others' shoulders. One well-tested reusable implementation is dramatically better than a hundred incompatible bespoke ones that happen to work and a hundred more that are subtly broken.
haolez 7y ago
Agreed. What I don’t get is why people try to change Go all time instead of simply using different languages for different problems. If you absolutely need generics in a project, there are a ton of languages out there that will fit your bill.
- pjmlp 7y ago
  Sometimes we don't get to choose project requirements, nor the projects.
  - haolez 7y ago
    That’s not the language’s fault, nor is it a reason to downscale what makes it great.
    - pjmlp 7y ago
      It is, because its designers created a language in 21st century while ignoring what has been done since 1976. The generics proposal hints that the design is reminiscent from Ada generics. Well its first standard was released in 1983.
- wybiral 7y ago
  Yeah, for me Go is a specialized tool mostly for dealing with IO. The entire standard library and all of the builtin types are really designed for IO-centric applications which is why it's a natural fit for servers/microservices. Small, narrowly defined applications that mostly coordinate via sockets and serialization and it does those things really well. In those worlds you're more likely to move data between logical units in JSON or Protobufs (both of which Go is good for) than to need proper generics so I don't understand the push from this subset of the community. As far as container types and data structures, look at the number of well built storage solutions that don't seem encumbered by the lack of generics at all like: boltdb, bleve, BadgerDB, InfluxDB, etc.
  - 6ue7nNMEEbHcM 7y ago
pcwalton 7y ago
Left-pad had nothing to do with dependencies being bad and everything to do with the fact that you could delete dependencies from NPM. I predicted at the time that people would take away the wrong conclusion—"dependencies are bad"—from the left-pad incident. Sadly that prediction seems to have come true.
- tombert 7y ago
  I don't really see how that's an unfair conclusion to draw. The more dependencies you have, the more likely you are to get one that's going to cause a problem down the line, be it due to conflicts with other libraries, subtle bugs that take years to manifest, or someone deleting something from upstream package manager (as was the case with left-pad).
  - pcwalton 7y ago
    "Subtle bugs that takes years to manifest" are way more likely to occur with code you write yourself because you didn't want to import someone's production-hardened code than with popular dependencies. Take crypto code. Which do you trust: a homebrew implementation of AES-GCM because nobody wanted to add a dependency, or libsodium?
    - tombert 7y ago
      I feel like crypto is an outlier; you should definitely use well-vetted libraries for that for a whole plethora of reasons. However, I think the reason that people got upset over the left-pad thing was because it was a library that most engineers could write fairly easily, without adding in another failure point. If you rely on the the language/platform's built-in libraries, typically the amount of wheel-reinventing you are doing boils down to writing simple wrappers, without adding in another external point of failure. These libraries are typically more production-hardened than something you'd find on NPM or Maven or Nuget.
    - weberc2 7y ago
      Or take leftpad. The point is there is a spectrum along which the cost/reward calculation varies. Absolutely don't roll your own crypto and absolutely roll your own leftpad. Maybe this is a bad conclusion, but I think it's important to address that not all dependencies are crypto, at any rate.
weberc2 7y ago
In general, I have a lot of sympathy for your concern--I've used Go and other languages with generics, and the difference is noteworthy. I personally think generics is worthwhile on balance, but I respect that others don't share this opinion. I'm glad you brought it up because most conversations about generics outside of the Go community pretend as though there is no tradeoff at all. That said, what sort of generics proposal would be sufficiently powerful (or perhaps that's not what you meant by "different from interfaces"?) to alleviate your concern? And note that this proposal is quite a lot more powerful than interfaces because interfaces aren't generic over multiple types, while contracts are.
ksec 7y ago
>One of Go's core strengths is simplicity. I also remember reading some one said their Software has increased complexity due to Go's Simplicity. ( Or something similar along the line ) It really is a balancing act. And it seems there is no one size fit all solution.
- mbrumlow 7y ago
  > Software has increased complexity due to Go's Simplicity. Which way are you meaning this. The way I read it was that because GO was simple, we were able to build more complex systems. But you seemed to indicate that was a bad thing? Yes making complex that can be made simple is the way you want to do things, but some things simply are not simple, and thus require complex software.
  - pjmlp 7y ago
    For example check Kubernetes talk from FOSDEM.
  - ikiris 7y ago
    No, that the simplicity of the language forces complexity in the code written in it.
    - mbrumlow 7y ago
      I have thought about this for about a day, and I can't agree with you. Every time I have seen complex GO code and investigated how it got that way it was simply the result of one of the following. 1) Writing GO code before fully understanding the language. 2) Trying to write GO code like it was some other language. I have seen some crazy complex GO in my days, and after spending hours and hours of trying to figure out what the code was doing -- I have always been able to simplify the program to a nice concise bit of code -- and I can assure you there are much better programmers out there than me. Often the complexity is people trying to implement generics in some crazy round about way, or have prioritized dependency injection, or code coverage test to a extreme. My favorite example of this is https://github.com/rdadbhawala/dutdip https://github.com/rdadbhawala/dutdip -- and here is a good talk on it https://www.youtube.com/watch?v=HBLJV0cPRBM https://www.youtube.com/watch?v=HBLJV0cPRBM The code base that implemented this in production is an amazing mess, I can assure you of that.
ErotemeObelus 7y ago
Generics are generally speaking a bad idea. I would rather have a language with a coherent type system (polymorphism, dependent types, type constructors). I don't know what's the difference between subtyping and having a subset feature like in Pascal.
jayd16 7y ago
It will take a language deciding to remove generics before I believe this is anything but stubbornness.
- ploxiln 7y ago
  ... but you can't remove major features while retaining compatibility. So for the most part you can only add stuff. So, people switch to new simpler languages. The way you remove things from a language is to create a new one. Then these new simpler languages become popular, and then people want their critical favorite bit added. And eventually the language is no longer simpler. And people switch to another new language, and the cycle repeats. Because we couldn't convince people to just use the existing complex language if they want that. Because, really, this is all a struggle to influence other developers. These days it's not enough to work the way that is best for you, you need to find ways to harness a critical mass of other developers, and at the same time contain the mess and damage that a huge number of miscellaneous developers out in the world can do to your ecosystem. It kinda sucks. Where possible, I like to use older, less popular, more minimal: libraries, frameworks, tools.
  - jayd16 7y ago
    Lots of languages have breaking changes between major versions.
nvarsj 7y ago
That’s a very slippery slope argument that could apply to almost anything. Fortunately, most people realise the benefits of generics - and it has nothing to do with dependency management (which is already a mess by the way). I’m more worried about eccentricities in the implementation that we’ll get out of the golang team. Then again, maybe we’ll be pleasantly surprised.
- weberc2 7y ago
  I agree with your position, but you’ve missed the point. Everyone recognizes the benefits of genetics; the debate is about whether they’re worth the cost. Not everyone can even bring themselves to admit there are costs.

woah 7y ago

Is it lack of generics that has resulted in fewer dependencies, or the incredibly full featured stdlib?

abhchand 7y ago
a bit of both?

quacker 7y ago

Missing generics certainly had some influence on golang, but not sure I understand your point. How does adding generics lead to a reliance on dependencies, or the absence of generics reduce reliance on dependencies? The relative lack of "dependency hell" in golang compared to other languages is because of the great standard library. Golang also never had an official/proper (imo) solution for package management until just this past year or so (although people worked around that a bit)

skybrian 7y ago
I think the argument is that generic code, being, well, generic, promotes reuse at an abstract level, rather than a concrete level. Abstract code can be more difficult to understand than specialized code that does only what is needed in a particular use case. I like the generics proposal, but it seems like a valid concern.
- weberc2 7y ago
  To clarify further, I think the concern is that people will start adding dependencies for things that could be implemented concretely in a dozen lines or so, e.g., a generic slice.Map function or even a linked list. Note that this comment is not advocating for or against this proposal or generics in general; it just took me a few re-reads to understand the concern and I hope to save others some time. :)
  - throwaway34241 7y ago
    I hope that if this design is accepted they would also include some common generic types/algorithms in the standard library instead of leaving it to a 3rd party. For example an updated sync.Map (that doesn't use interface{}), some things from SliceTricks [1], or maybe the Set example (although I don't really have a problem with map[thing]struct{}, Set is arguably more clear). IMO I think having a standard library that judiciously used generics would be almost pure upside for most Go programs. Being able to do math.Sin(x) instead of float32(math.Sin(float32(x))) just seems like an improvement in every way. [1] https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
    - weberc2 7y ago
      Agreed. I think this would go a long way toward addressing the original concern.
  - erik_seaberg 7y ago
    That's exactly what needs to happen. We will never arrive at a more powerful platform by self-gratification and refusing to stand on each others' shoulders. One well-tested reusable implementation is dramatically better than a hundred incompatible bespoke ones that happen to work and a hundred more that are subtly broken.

haolez 7y ago

Agreed. What I don’t get is why people try to change Go all time instead of simply using different languages for different problems. If you absolutely need generics in a project, there are a ton of languages out there that will fit your bill.

pjmlp 7y ago
Sometimes we don't get to choose project requirements, nor the projects.
- haolez 7y ago
  That’s not the language’s fault, nor is it a reason to downscale what makes it great.
  - pjmlp 7y ago
    It is, because its designers created a language in 21st century while ignoring what has been done since 1976. The generics proposal hints that the design is reminiscent from Ada generics. Well its first standard was released in 1983.
wybiral 7y ago
Yeah, for me Go is a specialized tool mostly for dealing with IO. The entire standard library and all of the builtin types are really designed for IO-centric applications which is why it's a natural fit for servers/microservices. Small, narrowly defined applications that mostly coordinate via sockets and serialization and it does those things really well. In those worlds you're more likely to move data between logical units in JSON or Protobufs (both of which Go is good for) than to need proper generics so I don't understand the push from this subset of the community. As far as container types and data structures, look at the number of well built storage solutions that don't seem encumbered by the lack of generics at all like: boltdb, bleve, BadgerDB, InfluxDB, etc.
- 6ue7nNMEEbHcM 7y ago

pcwalton 7y ago

Left-pad had nothing to do with dependencies being bad and everything to do with the fact that you could delete dependencies from NPM. I predicted at the time that people would take away the wrong conclusion—"dependencies are bad"—from the left-pad incident. Sadly that prediction seems to have come true.

tombert 7y ago
I don't really see how that's an unfair conclusion to draw. The more dependencies you have, the more likely you are to get one that's going to cause a problem down the line, be it due to conflicts with other libraries, subtle bugs that take years to manifest, or someone deleting something from upstream package manager (as was the case with left-pad).
- pcwalton 7y ago
  "Subtle bugs that takes years to manifest" are way more likely to occur with code you write yourself because you didn't want to import someone's production-hardened code than with popular dependencies. Take crypto code. Which do you trust: a homebrew implementation of AES-GCM because nobody wanted to add a dependency, or libsodium?
  - tombert 7y ago
    I feel like crypto is an outlier; you should definitely use well-vetted libraries for that for a whole plethora of reasons. However, I think the reason that people got upset over the left-pad thing was because it was a library that most engineers could write fairly easily, without adding in another failure point. If you rely on the the language/platform's built-in libraries, typically the amount of wheel-reinventing you are doing boils down to writing simple wrappers, without adding in another external point of failure. These libraries are typically more production-hardened than something you'd find on NPM or Maven or Nuget.
  - weberc2 7y ago
    Or take leftpad. The point is there is a spectrum along which the cost/reward calculation varies. Absolutely don't roll your own crypto and absolutely roll your own leftpad. Maybe this is a bad conclusion, but I think it's important to address that not all dependencies are crypto, at any rate.

weberc2 7y ago

In general, I have a lot of sympathy for your concern--I've used Go and other languages with generics, and the difference is noteworthy. I personally think generics is worthwhile on balance, but I respect that others don't share this opinion. I'm glad you brought it up because most conversations about generics outside of the Go community pretend as though there is no tradeoff at all. That said, what sort of generics proposal would be sufficiently powerful (or perhaps that's not what you meant by "different from interfaces"?) to alleviate your concern? And note that this proposal is quite a lot more powerful than interfaces because interfaces aren't generic over multiple types, while contracts are.

ksec 7y ago

>One of Go's core strengths is simplicity. I also remember reading some one said their Software has increased complexity due to Go's Simplicity. ( Or something similar along the line ) It really is a balancing act. And it seems there is no one size fit all solution.

mbrumlow 7y ago
> Software has increased complexity due to Go's Simplicity. Which way are you meaning this. The way I read it was that because GO was simple, we were able to build more complex systems. But you seemed to indicate that was a bad thing? Yes making complex that can be made simple is the way you want to do things, but some things simply are not simple, and thus require complex software.
- pjmlp 7y ago
  For example check Kubernetes talk from FOSDEM.
- ikiris 7y ago
  No, that the simplicity of the language forces complexity in the code written in it.
  - mbrumlow 7y ago
    I have thought about this for about a day, and I can't agree with you. Every time I have seen complex GO code and investigated how it got that way it was simply the result of one of the following. 1) Writing GO code before fully understanding the language. 2) Trying to write GO code like it was some other language. I have seen some crazy complex GO in my days, and after spending hours and hours of trying to figure out what the code was doing -- I have always been able to simplify the program to a nice concise bit of code -- and I can assure you there are much better programmers out there than me. Often the complexity is people trying to implement generics in some crazy round about way, or have prioritized dependency injection, or code coverage test to a extreme. My favorite example of this is https://github.com/rdadbhawala/dutdip https://github.com/rdadbhawala/dutdip -- and here is a good talk on it https://www.youtube.com/watch?v=HBLJV0cPRBM https://www.youtube.com/watch?v=HBLJV0cPRBM The code base that implemented this in production is an amazing mess, I can assure you of that.

ErotemeObelus 7y ago

Generics are generally speaking a bad idea. I would rather have a language with a coherent type system (polymorphism, dependent types, type constructors). I don't know what's the difference between subtyping and having a subset feature like in Pascal.

jayd16 7y ago

It will take a language deciding to remove generics before I believe this is anything but stubbornness.

ploxiln 7y ago
... but you can't remove major features while retaining compatibility. So for the most part you can only add stuff. So, people switch to new simpler languages. The way you remove things from a language is to create a new one. Then these new simpler languages become popular, and then people want their critical favorite bit added. And eventually the language is no longer simpler. And people switch to another new language, and the cycle repeats. Because we couldn't convince people to just use the existing complex language if they want that. Because, really, this is all a struggle to influence other developers. These days it's not enough to work the way that is best for you, you need to find ways to harness a critical mass of other developers, and at the same time contain the mess and damage that a huge number of miscellaneous developers out in the world can do to your ecosystem. It kinda sucks. Where possible, I like to use older, less popular, more minimal: libraries, frameworks, tools.
- jayd16 7y ago
  Lots of languages have breaking changes between major versions.

nvarsj 7y ago

That’s a very slippery slope argument that could apply to almost anything. Fortunately, most people realise the benefits of generics - and it has nothing to do with dependency management (which is already a mess by the way). I’m more worried about eccentricities in the implementation that we’ll get out of the golang team. Then again, maybe we’ll be pleasantly surprised.

weberc2 7y ago
I agree with your position, but you’ve missed the point. Everyone recognizes the benefits of genetics; the debate is about whether they’re worth the cost. Not everyone can even bring themselves to admit there are costs.