Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--th

Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--then hopefully folks would be more inclined to write libs for B-trees or whatever on top of it. Mostly irrelevant, but to put a finer point on the wish for something to show up in the core: I totally sympathize with the Gophers' decision to ship 1.0 without generics (or polymorphic functions or whatever); there are workarounds for not having 'em, and there's plenty else to keep the core team busy, like writing an awesome stdlib. Other languages that now have generics also lacked them at first. But it sort of grates to hear it waved off as simply unimportant that you can't deploy a set or B-tree or whatever of a new type without either cut-and-pasting (by hand or w/a third-party tool) or taking the runtime hit of dynamic typing. That's a solvable, useful-to-solve, and repeatedly solved problem, and seems eventually worth solving in the Go core, even if it's not the highest priority. Most of Go's omissions/quirks I either actively like or just shrug at, but that's one on my wishlist. End rant. :)