interface{} is heavily used in many of the Go std libraries. Particularly for what I call "convenience methods" where you want to be able to pass in various types and it will do a type switch for you and then determine what to do.
Part of what I was discovering in this blog post is that if you look under the hood at these convenience methods, and you know in advance what type are passing (i.e., you are not using interface{}), you can often find the "direct" call to use that uses a concrete type and likely get better performance out of it.
I'm the blog post author. I haven't disabled comments (I welcome them) and I don't see any pending ones that I need to approve. I'm not super happy with Blogger, so I'm going to blame it on that. There is one other comment on this post, so the problem probably has to do with the "Comment As" choice and whether you are logged in to that service.
This presentation is right in line with something I've been thinking about lately. Is programming with Clojure agents (and atoms/STM) functionally equivalent to programming with Actors or Go routines with Go channels? In other words, can you solve all the same problems?
One difference, I imagine, is that the Actor model is distributable (a la Erlang and recent Akka editions), whereas the Clojure model is fundamentally about safely sharing memory in the same process space.
Beyond that though, is there an example of a problem that is hard to do with STM or the Clojure model but relatively straightforward with Actors or Go channels? And then the same question in the other direction.
I'd be very interested in studying such an example!
Part of what I was discovering in this blog post is that if you look under the hood at these convenience methods, and you know in advance what type are passing (i.e., you are not using interface{}), you can often find the "direct" call to use that uses a concrete type and likely get better performance out of it.