Daniel Lemire's blog

, 4 min read

Go generics are not bad

6 thoughts on “Go generics are not bad”

  1. Some of these basic interfaces are also available in https://pkg.go.dev/golang.org/x/exp/constraints

    1. Thanks.

  2. DBJ says:

    C++ On and off the bandwagon

    https://dbj.org/c-on-and-off-the-bandwagon/

  3. me says:

    This is the simplest case only, and could be done with C preprocessor macros. Simply by substituting Number by the four permitted values, compiling it four times. But what if you had a high precision number type instead?
    Any of the many “template engines” can be used to generate such code in Java (and most of the “primitive collections” libraries work this way.
    I believe the actual test case for expressability of generics is when you have polymorphism at the same time, and the type may not yet known at compilation time.

    What impressed me a bit more is the expressivity of Rust with it’s numeric traits – you could express that you want to fail on overflow, use a saturating add, etc. – but honestly that takes the fun out of it eventually. And how many “saturating add” types do you have? Pretty much only the primitive integers, not even floats…

    1. This is the simplest case only, and could be done with C preprocessor macros.

      Yes.

  4. Klaus says:

    The more I (try to) use them, the more I realize how incomplete they are, and how bad they sometimes are. To everyone: First google what’s all missing and virtually impossible, it will save you time.