Yes let's fracture the ecosystem with a bunch of libs doing generic map, slice etc. Cause there is no way to figure out how to do it right as this is a very novel feature that no other lang has
The questions aren't around the algorithms. They're about Go specific things like how to deal with legacy std library parts that are made obsolete by generics.
There's no need for generics in the short term. We've survived for 11 years without them, we can manage another couple while we work out how to best use them.
Libraries that do release security updates, but introduce new language features like generics in those point-releases also shouldn't be trusted, and have no place in production. Why should I upgrade my language version to get a security fix?
they'll implement them in some versioned package that everyone can adopt and play with, and then incorporate them.
fracturing could happen. but that could happen if they immediately included it in the standard library with warts, too. I can easily imagine people creating multiple packages to overcome shortcomings of a half baked stdlib package.
..so I don't want go to follow some fearful path because of some unquantifiable risk that may or may not come to pass, and could come to pass regardless of which path they take.
in the long run i think it'll consolidate the community, but there's definitely a long tail to that timeline.
having it be incorporated into the project is ultimately the real win, because it gives a target to consolidate round.