7 ms·

I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrar

by jshen 5y ago

I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrary code base and making sense of it. Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?

pie_flavor 5y ago
Which part of this is not generalizable to literally every conceivable complaint about a language whether it makes sense or not? Why would I want diversity between languages where you do have to copy-paste lots of boilerplate, and languages where you don't? If there was a good, simple-in-the-Go-way solution to this problem other than generics, feel free to suggest it, but repeating 'why care about anything ever' is just pure noise.
- jshen 5y ago
  As I've said, this isn't about generics specifically. There are a whole lot of us who find Go code bases far easier to read and understand that most other languages. We believe there is a value to the language's simplicity, and we want to keep it that way. We've written Go for years, and haven't missed many of these features you want. In fact, we think there is a decent chance that Go code bases are easier to jump into and understand BECAUSE of it's simplicity. You have many many choices that work the way you want. Go use them, why try to dictate to us that we can't have the choice we want? We disagree about the value of these things, and their trade-offs. That's what diversity is for, you have languages that work your way. Why insist that one of the few that doesn't has become like all the others?
  - pie_flavor 5y ago
    You are posting a criticism of the feature, in response to a comment that is an answer to that criticism. If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere. But just because you don't interact with a problem doesn't mean it doesn't exist, and the problem has historically been solved with dynamic downcasting, code generation, or copy-pasting, all of which result in codebases far harder to read and understand than most other languages. For these problems, you are not trading off generic code vs simple code, you are trading off generic code vs incomprehensible code. It is great that you have never needed a tree-map instead of a hash-map, but many have. Go's simplicity is in many ways it being the spiritual successor to C, and even C has generics nowadays because they are an enormous value add.
    - jshen 5y ago
      You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question. “ If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.” This shows a profound lack of understanding of software development at scale.
      - jppittma 5y ago
        Can't you and yours just freeze at go 1.7? That way, you get your diversity. Pretend every code base that's using go 1.8 is using java or something. A lot of us who write go everyday think generics aren't complicated and are tired or repeating ourselves.
        jshen 5y ago
        This shows a profound lack of understanding of software development at scale. Also, as I've said many times in the thread above, I'm not talking about this specific implementation of generics.
      - pie_flavor 5y ago
        Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.
        jshen 5y ago
        Unlike you, I’ve answered your question many times. You are only looking at the benefit for a narrow use case without accounting for its holistic costs. We have a difference of opinion about those costs, and there is no hard science that can prove either of us right. I have acknowledged your point of view, and the possibility that it could be right. You have not reciprocated in any way, or even acknowledge that you understand the point I’m making.
munificent 5y ago
> why insist that go become the same as all the other languages You're arguing a strawman. No one insists that Go become the same as all the other languages (which are themselves nowhere near the same as each other). People are just asking for generics. C++, Java, C#, and Haskell all have generics and are still wildly different languages even with respect to their approach to generics.

by jshen 5y ago

pie_flavor 5y ago

Which part of this is not generalizable to literally every conceivable complaint about a language whether it makes sense or not? Why would I want diversity between languages where you do have to copy-paste lots of boilerplate, and languages where you don't? If there was a good, simple-in-the-Go-way solution to this problem other than generics, feel free to suggest it, but repeating 'why care about anything ever' is just pure noise.

jshen 5y ago
As I've said, this isn't about generics specifically. There are a whole lot of us who find Go code bases far easier to read and understand that most other languages. We believe there is a value to the language's simplicity, and we want to keep it that way. We've written Go for years, and haven't missed many of these features you want. In fact, we think there is a decent chance that Go code bases are easier to jump into and understand BECAUSE of it's simplicity. You have many many choices that work the way you want. Go use them, why try to dictate to us that we can't have the choice we want? We disagree about the value of these things, and their trade-offs. That's what diversity is for, you have languages that work your way. Why insist that one of the few that doesn't has become like all the others?
- pie_flavor 5y ago
  You are posting a criticism of the feature, in response to a comment that is an answer to that criticism. If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere. But just because you don't interact with a problem doesn't mean it doesn't exist, and the problem has historically been solved with dynamic downcasting, code generation, or copy-pasting, all of which result in codebases far harder to read and understand than most other languages. For these problems, you are not trading off generic code vs simple code, you are trading off generic code vs incomprehensible code. It is great that you have never needed a tree-map instead of a hash-map, but many have. Go's simplicity is in many ways it being the spiritual successor to C, and even C has generics nowadays because they are an enormous value add.
  - jshen 5y ago
    You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question. “ If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.” This shows a profound lack of understanding of software development at scale.
    - jppittma 5y ago
      Can't you and yours just freeze at go 1.7? That way, you get your diversity. Pretend every code base that's using go 1.8 is using java or something. A lot of us who write go everyday think generics aren't complicated and are tired or repeating ourselves.
      - jshen 5y ago
        This shows a profound lack of understanding of software development at scale. Also, as I've said many times in the thread above, I'm not talking about this specific implementation of generics.
    - pie_flavor 5y ago
      Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.
      - jshen 5y ago
        Unlike you, I’ve answered your question many times. You are only looking at the benefit for a narrow use case without accounting for its holistic costs. We have a difference of opinion about those costs, and there is no hard science that can prove either of us right. I have acknowledged your point of view, and the possibility that it could be right. You have not reciprocated in any way, or even acknowledge that you understand the point I’m making.

munificent 5y ago

> why insist that go become the same as all the other languages You're arguing a strawman. No one insists that Go become the same as all the other languages (which are themselves nowhere near the same as each other). People are just asking for generics. C++, Java, C#, and Haskell all have generics and are still wildly different languages even with respect to their approach to generics.