On: Go generics are not bad

[e12e]

>> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays

> More likely they install a 3rd party generic sum function and don't have to write their own at all. Well, in the case of a sum function it's probably only 15 minutes to write to generic version

I'm not sure "sum over an array of int" is a great "simple" example - how do you guarantee that the result can fit in an int?

This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

Sure there are some examples where you can sum N Mbit numbers into an Mbit number, and either want overflow, or is somehow "confident" things will fit. But in general it's just lazy "no one will ever have such a large shopping cart"-design...

[anonymoushn → e12e]

> This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

What's the result of adding two i32 then? Is it an i64? Doesn't the accumulator need to get wider on some additions, since adding an i64 to an i32 might also overflow an i64?

[e12e → anonymoushn]

Actually, the default is overflow I now realize. But there is also automatic promotion, so:

    0 + typemax(UInt8)+ typemax(UInt8)
    510

While adding UInt8 first, then an implicit Int64 causes overflow:

    typemax(UInt8)+ typemax(UInt8)
    254

(ie: 255 overflows to 254 - or is promoted and sums to 510)

See: https://docs.julialang.org/en/v1/manual/integers-and-floatin...

Try: https://julialang.org/learning/tryjulia/