4 ms·

> 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.

> 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.
    - lenkite 2y ago
      Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad. You have been using a generic data-structure since Go 1.0 but did not realize this.
      - akira2501 2y ago
        > in order to be honest and consistent with your opinion Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at. For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean? > explain to all your stakeholders that you have done so because generics is bad. I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software. > generic data-structure What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest. So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.
  - trustno2 2y ago
    error handling is what I like about go. ok errors.As is a little stupid, I'll give you that. But that's all.

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.
  - lenkite 2y ago
    Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad. You have been using a generic data-structure since Go 1.0 but did not realize this.
    - akira2501 2y ago
      > in order to be honest and consistent with your opinion Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at. For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean? > explain to all your stakeholders that you have done so because generics is bad. I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software. > generic data-structure What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest. So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.
- trustno2 2y ago
  error handling is what I like about go. ok errors.As is a little stupid, I'll give you that. But that's all.