That’s true, a binary tree isn’t a problem, it’s a tool for solving a certain class of problems. Since you can’t build reusable tools in pre-generic Go, (and, to be honest, only a limited set of tools with Go’s new generic system), programmers are forced to reinvent half-baked ad-hoc solutions all over their code base. I once read an article about a C codebase that contained dozens (!) of specialized linked-list implementations. Large Go codebases, from everything I’ve seen, aren’t all that different.

Specialized collections are not necessarily bad. ClickHouse has dozens of hash table implementations, each tuned to a specific use case. It's what you do when you need something to go very fast.

Several specialised implementations of a concept with different algorithms is quite different to several implementations of the same algorithm because the language does not support their reasonable reuse. Rust gives you “specialised collections” via monomorphisation.

And that is the exact joy of using a language like C or Go; you need to sort your things, just add in two pointers and make it a list you sort on. Eight or now sixteen extra bytes and you have a good tuned data structure. I don’t want to use a bunch of generic structures, I want to use the ones that solve my particular use case best.

I always say "Just right is all wrong". The time and standardization cost is often just too much for the small gains. I'd much rather have everything be reusable, abstracted, and one size fits all, aside from the tiny fraction that matters enough to optimize.

Good points. But for myself, I like it when the structure of the code and data structures exactly fit the need. Like the old quite, “show me your header files and hide the C files, and I will understand your program.”

Some problems are technical problems, posited and solved by engineers.

Solving them helps better solve the product and business "real-world" problems.

I mean Go has map right?

"I need a priority queue for X" isn't generic, and "I need a priority queue for Y" isn't generic either. But well if you're doing it a lot, would be nice to not just reproduce the same bugs over and over again, yeah?

Everyone's worried about Go turning into Java and I can't speak too much to the utility (I have written maybe 50 pages of go in my life) but anyone who uses Python's standard lib can point you to 10 different things that are nice to have bug-free versions of and that "just work" thanks to Python's "generics".

I guess you used map[interface{}]interface{} everywhere you needed to use a Go map ? If not, then your statement is a logical contradiction.

Of course not. I use map[myKeyType]myValueType, depending on the problem I'm solving.

It depends on the level of abstraction you're addressing. One level may be "i need to store things with a quick search function", another may be "i need a storage of ordered names and expiry date for things", etc until you get to "I need a binary tree which orders by comparable types".

Where you split that process as a separate library you either decide to write or reuse - that becomes the problem to solve. A set implementation may be a problem to solve: https://github.com/deckarep/golang-set A btree may be a problem to solve: https://gitlab.com/cznic/b/-/tree/master/v2

Go is used a lot for systems programming where you do see those problems.

No you don't.

If you do, you haven't understood the problem that you need to solve and you are reaching for things you don't need to use.

Seems like you are not aware of the kind of problems they solve. Systems engineers have been writing generic programming code for years to build databases, message queues, file systems, etc where you do need data structures that support arbitrary types/functions.