I don't think there's anything you "can't" implement that the language reserves for itself anymore. There may be some edge case or something but in general it's no longer an issue.

The language reserves syntax for itself; you can't overload a[b] to mean anything other than either array/slice indexing or indexing into a map. You have to write methods like ".Get" or something, there's no __getattr__ or anything.

Go has good (enough) built-in arrays and maps. But if you want a tree, without generics, you're really limited. With generics, you can get a nice containerized type, but you don't get the nicer syntax that the builtins have.

It's not just types, either. Look at the signature for the built-in sort, which is amazingly cumbersome to use. A generic wrapper around it hides all the ugly.

I think anything could be implemented, since you’ve got byte arrays in the language, which I imagine is your point.

It’s more what you must implement along with your new data structure to make it usable in the language that was the cry of the generics advocates.

i guess maps and array ? ( if you wanted to reimplement your own in a typesafe way, that is)

That’s been possible for a couple of releases now

In fact I created a struct that you can range over just a couple of days ago.

I can’t say I love the way Go implemented it though. But it does work.

Go added support for custom iterators a few versions ago.

I have written my own types that can do this?

EDIT: Had to check, yeah I had to implement the iter.Seq type to do it