Readit NewsAnd the average company needs to be dragged kicking and screaming to care about security at all.
The money could probably be more wisely spent if not following FIPS but without FIPS the average company wouldn't direct that money towards security at all.
I was unclear, I'm afraid. You can reorder the type parameters, it just changes which of them you need to specify: https://go.dev/play/p/oDIFl3fZiPl
The point is that you can only leave off elements from the end of the list, to have them automatically inferred.
> Are there any real packages out there using these techniques?
I think so far, the usage of generics for containers in Go is still relatively sparse, in public code. I think in part that is because the documentation of how to do that is relatively sparse. That is part of the motivation for the post, to have a bit of somewhat official documentation for these things, so they become more widely known.
The standard library is just starting to add generic containers: https://github.com/golang/go/issues/69559 And part of that is discussing how we want to do things like this: https://github.com/golang/go/issues/70471
That being said, I have used the pointer receiver thing in my dayjob. One example is protobuf. We have a generic helper to set a protobuf enum from the environment. Because of how the API was designed, that required a pointer receiver constraint.
The article mentions using the function version to implement all others, but also that the method version would be optimized better.
Would the compiler be able to inline MethodTree's compare even though it's passed in as a function variable to node.insert?
Are there any real packages out there using these techniques?
Did the author take their own medicine and measure their own productivity?
[1] https://github.com/piyushgupta53/go-torrent-client/blob/6130...
So the README is correct.
But in any case, why so much fear of being wrong?
> we have fine-grained control over the language version via go.mod files and file-specific directives
And that may be the real truth of it: Error handling in Go just isn't ... that much of a problem to force action?
It seems that now that Ian's left the rest of the Go team is just being honest about what they are willing to spend their time on.
And I'm more than fine with that, because look at this comment section. You can't please everybody.