The one used by sort is a hack that only works for some of the things that you would want to do.
The one where you use introspection performs badly and isn't typesafe.
The tree implementation in the article cannot be done in a safe and performant way in Go today.
It's not a hack: it's a runtime equivalent that requires that your type implements some interface.
Find smallest/largest element in slice
Find average/standard deviation of slice
Compute union/intersection of maps
Find shortest path in node/edge graph
Apply transformation function to slice/map, returning new slice/map
Sets
Self-balancing trees, with efficient insertion and traversal in sorted order
Multimaps, with multiple instances of a key
Concurrent hash maps, supporting parallel insertions and lookups with no single lock
Isn't this just map[Key][]Value? The standard library uses these in several places, e.g. url.Values and http.Header, with assorted utility functions.
Many smaller projects would benefit too. I would like to build a typesafe tree for an efficient sorted map, and to be able mergsort over multiple trees of different types. It would allow some extremely useful channel combinators for doing rather common things like safely shutting down a service with some background processing. Often these things leak and a often I find myself spawning more go routines just to map between types or to stop generic interface types infecting the rest of the API.
Plus, there are some generic data structures that will really work well in Go, like, for instance, an immutable tree. Granted, it'll still take some care to use properly in Go as it does not have "const" or anything like it, but it can still be done. The problem I have is not with accidental mutation, but that I just don't want to sit there and implement the immutable tree code. (Trees are great, but they're really tedious to write in the best of times, and nightmares to debug in the worst.)
I'm not terribly interested in trying to jam functional programming into Go; I may make light use of map/filter/reduce but even if this was fully implemented it would still be a fairly unpleasant experience (function that return "a value and an error" aren't much fun to map and can't hardly "chain" at all). But I've missed being able to just grab a particular data structure a few times.
How would you re-orthoganize the problem statement? (Statements, actually)
https://news.ycombinator.com/newsguidelines.html
You obviously have a good point to make, but it needs to be done without firebombs.
Well that seems uncalled for.
Once we broke LSP, a cascade of similar ideas started showing up with regularity, especially in J2EE. I used to be able to go on at some length but now it’s more “I hope I never meet this guy because it’ll be awkward as hell.”
The implementation perfectly follows it because the LSP simply requires identical behavior, and the contract clearly states it may[1] throw an exception. All the implementations "may" throw an exception. Sorry, but they correctly lawyered the LSP.
> I came up with around 20% more than the selected design.
But `add` can throw 5 different exceptions depending on restrictions your implementation wants to place on a given collection, does it allow for all that? In terms of making an interface that was small and reusable by many projects, runtime exceptions are a pretty good compromise for a standard library.
[1]: https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...
It is correct to the letter of LSP, but not the spirit of it, and this was a conscious decision; contrary to your original claim, they understood the principle perfectly well.
I think idiomatic golang works pretty well without generics in most cases, the big problem for me is that functional programming is essentially impossible without them.
That's definitely not the case from what I know/understand...
However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.