5 ms·

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky p

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

zimbatm 8y ago
Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again. So in these discussion you have devops-type people mainly dealing with APIs that are perfectly content. And the ones that work with algorithms are talking past them because they don't experience the same pain. Instead of changing the language to enable generics everywhere, maybe there is a lighter version that exists that only applies to numerical problems. Is it possible that a boxed "Number" type would solve most of the problems?
- phamilton 8y ago
  > mapping JSON I find that an ideal set of tools allow us to describe our task and write our code using the same idioms. The fact that "mapping JSON" doesn't actually involve calling "map" on JSON data is a great example of why not having generics in golang is frustrating for me.
  - zimbatm 8y ago
    I forgot the 3rd category, those who see the world exclusively through the functional programmer lens :-D Mapping functionally it worth it if the transformation between A and B is regular enough. But things are dirty. Some irregularities appear and now the perfect higher-order function doesn't work nicely anymore. With the imperative approach it just means adding 1 -3 more lines.
- civility 8y ago
  I think you're exactly right: People who live and breathe JSON and strings don't (and probably shouldn't) care about use cases where the choice between float or double matters... I also see this with graphics people who live and breathe small (2x2, 3x3, and 4x4) matrices don't care about "type level integers" (as Rust calls them) to make 6x9 matrices efficiently live on the stack or in an array. > Is it possible that a boxed "Number" type would solve most of the problems? If you mean it the way I think you do, not for me. I can easily afford to fit a billion 4 byte floats in memory, but I can't afford a billion 8 byte box pointers to a 4 byte box with an n-byte tag, and the cache locality could be horrible. However, if Go had an elegant macro system (Rust's doesn't seem too bad), I could get by though.
  - steveklabnik 8y ago
    Graphics people are one of the groups most often requesting type level integers. I’m sure many are fine without them, but many want them too.
cdoxsey 8y ago
Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy. It also doesn't really work in Java either because you have to use the Object types. Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers https://travisf.net/rust-generic-numbers Maybe it's easy in c++? I've seem a similar comment made on almost every discussion of this issue... are folks just not aware of the limitations with generic implementations?
- annywhey 8y ago
  In agreement. IMHO generics basically have one place where they work well: abstract containers. Your queues, linked lists, what-have-you can benefit. But most other data structures? Nope. Too much of the algorithm depends on the primitive type. And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-paste-modify your way to the types you want, or automate the same in a macro or code generator. It's not beautiful but it doesn't have to be.
  - kungito 8y ago
    "Generics" (which should allow higher kinded types) work well with monads, who containers are among many others.
  - int_19h 8y ago
    Having coded C# for many years now, generics are used for a lot more than just containers. There's a great many things that can be generalized. Just look at any large C# project on GitHub.
- mseepgood 8y ago
  It would be easy with the proposed Go 2 contracts.
- civility 8y ago
  Yes, it works well enough in C++. It would be nice if another language, without C++'s other pitfalls, got some of this right. Btw, it's "ironic" that you think pointing at two broken implementations says anything about where it works. "Are folks just not aware" it's ridiculous to be snarky when arguing from a position of ignorance?
jy3 8y ago
That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.
- nicoulaj 8y ago
  So what is the use case for Go exactly ? Programs that don't need to put numbers in containers ?
  - stochastic_monk 8y ago
    You didn't ask me, but the people I know using it are primarily writing networking or cryptographic code. My biggest complaint about Go is the lack of generics; I bet they're just trying to get more adoption. That being said, adding generics won't eliminate all the other things I dislike about the language.
- civility 8y ago
  No, Go is not currently the right tool for me, but it's close, and it would be much closer with (usable) generics. What's "so sad" is you think this Reddit style "Don't use it" imperative is an acceptable way to talk to people. You're rightfully afraid of complexity creeping into an otherwise clean language, but it would suck less if you said it better.
  - jy3 8y ago
    I'm taken aback. I didn't mean to sound condescending. I won't argue with you my use of the imperative mood as I'm not a native speaker. I'll take note of it.
lowmagnet 8y ago
You can just write the types, annotate them with github.com/clipperhouse/gen, and get pre-tested, reliable implementations around your type. Generators are a legitimate solution and I wish they'd get more love.

zimbatm 8y ago

Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again. So in these discussion you have devops-type people mainly dealing with APIs that are perfectly content. And the ones that work with algorithms are talking past them because they don't experience the same pain. Instead of changing the language to enable generics everywhere, maybe there is a lighter version that exists that only applies to numerical problems. Is it possible that a boxed "Number" type would solve most of the problems?

phamilton 8y ago
> mapping JSON I find that an ideal set of tools allow us to describe our task and write our code using the same idioms. The fact that "mapping JSON" doesn't actually involve calling "map" on JSON data is a great example of why not having generics in golang is frustrating for me.
- zimbatm 8y ago
  I forgot the 3rd category, those who see the world exclusively through the functional programmer lens :-D Mapping functionally it worth it if the transformation between A and B is regular enough. But things are dirty. Some irregularities appear and now the perfect higher-order function doesn't work nicely anymore. With the imperative approach it just means adding 1 -3 more lines.
civility 8y ago
I think you're exactly right: People who live and breathe JSON and strings don't (and probably shouldn't) care about use cases where the choice between float or double matters... I also see this with graphics people who live and breathe small (2x2, 3x3, and 4x4) matrices don't care about "type level integers" (as Rust calls them) to make 6x9 matrices efficiently live on the stack or in an array. > Is it possible that a boxed "Number" type would solve most of the problems? If you mean it the way I think you do, not for me. I can easily afford to fit a billion 4 byte floats in memory, but I can't afford a billion 8 byte box pointers to a 4 byte box with an n-byte tag, and the cache locality could be horrible. However, if Go had an elegant macro system (Rust's doesn't seem too bad), I could get by though.
- steveklabnik 8y ago
  Graphics people are one of the groups most often requesting type level integers. I’m sure many are fine without them, but many want them too.

cdoxsey 8y ago

Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy. It also doesn't really work in Java either because you have to use the Object types. Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers https://travisf.net/rust-generic-numbers Maybe it's easy in c++? I've seem a similar comment made on almost every discussion of this issue... are folks just not aware of the limitations with generic implementations?

annywhey 8y ago
In agreement. IMHO generics basically have one place where they work well: abstract containers. Your queues, linked lists, what-have-you can benefit. But most other data structures? Nope. Too much of the algorithm depends on the primitive type. And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-paste-modify your way to the types you want, or automate the same in a macro or code generator. It's not beautiful but it doesn't have to be.
- kungito 8y ago
  "Generics" (which should allow higher kinded types) work well with monads, who containers are among many others.
- int_19h 8y ago
  Having coded C# for many years now, generics are used for a lot more than just containers. There's a great many things that can be generalized. Just look at any large C# project on GitHub.
mseepgood 8y ago
It would be easy with the proposed Go 2 contracts.
civility 8y ago
Yes, it works well enough in C++. It would be nice if another language, without C++'s other pitfalls, got some of this right. Btw, it's "ironic" that you think pointing at two broken implementations says anything about where it works. "Are folks just not aware" it's ridiculous to be snarky when arguing from a position of ignorance?

jy3 8y ago

That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

nicoulaj 8y ago
So what is the use case for Go exactly ? Programs that don't need to put numbers in containers ?
- stochastic_monk 8y ago
  You didn't ask me, but the people I know using it are primarily writing networking or cryptographic code. My biggest complaint about Go is the lack of generics; I bet they're just trying to get more adoption. That being said, adding generics won't eliminate all the other things I dislike about the language.
civility 8y ago
No, Go is not currently the right tool for me, but it's close, and it would be much closer with (usable) generics. What's "so sad" is you think this Reddit style "Don't use it" imperative is an acceptable way to talk to people. You're rightfully afraid of complexity creeping into an otherwise clean language, but it would suck less if you said it better.
- jy3 8y ago
  I'm taken aback. I didn't mean to sound condescending. I won't argue with you my use of the imperative mood as I'm not a native speaker. I'll take note of it.

lowmagnet 8y ago

You can just write the types, annotate them with github.com/clipperhouse/gen, and get pre-tested, reliable implementations around your type. Generators are a legitimate solution and I wish they'd get more love.