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?

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

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.

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.

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.

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

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?

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?

The complexity in that rust example comes from the indirection of requiring you to declare what operations you require via traits. C++ is much simpler: whatever operation you use is required.

It would be easy with the proposed Go 2 contracts.

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.

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.

"Generics" (which should allow higher kinded types) work well with monads, who containers are among many others.

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.

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.

So what is the use case for Go exactly ? Programs that don't need to put numbers in containers ?

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.

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.

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.