tag:blogger.com,1999:blog-2316765421340036602.post7456481322431843531..comments2024-01-10T11:38:15.547-08:00Comments on Random Observations: My thoughts on Go (Google's new language)Ben Tillyhttp://www.blogger.com/profile/04335648152419715383noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2316765421340036602.post-81991516153436276682009-11-16T17:13:11.814-08:002009-11-16T17:13:11.814-08:00Ben,
Thanks for this review. Very interesting la...Ben,<br /><br />Thanks for this review. Very interesting language. I for one wish it success.<br /><br />Go seems very small, and very simple. There's no cruft or redundancy. If you want a C-like language with some basic object-oriented features and garbage collection, Go is about as simple as it gets.<br /><br />I agree with you on the decision to not include generics (being a bad decision that is). Everything in Go is passed by value - except for the built-in slice and map types, which are passed by reference. Everything is allocated by "new" - except for the built-in slice and map types, which are allocated by "make". Strange decision...<br /><br />Very promising language.Unknownhttps://www.blogger.com/profile/12712188752586062723noreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-80802098421287561462009-11-12T13:52:57.985-08:002009-11-12T13:52:57.985-08:00@jkp: The challenge is that the function definitio...@jkp: The challenge is that the function definitions that define an interface are all typed. Which means you can't specialize them for your specific type. So, for instance, I can't create a function that takes a function that turns foos into bools, and a channel that passes foos, and then return a channel that passes back the foos that are true.<br /><br />They get around this by putting methods on the collection. For instance look at <a href="http://golang.org/doc/effective_go.html#interfaces_and_types" rel="nofollow">the documentation</a>. For a collection to be sortable you have to define Len(), Less(i, j int) bool, and Swap(i, j int). Because those function signatures are in terms of the index of the collection, they are able to handle collections with arbitrary types of data. However if you wanted, for instance, Less(T, T) to be a binary operation on the underlying data type T then you'd need to write a completely boilerplate function to implement Less on the collection.<br /><br />But it has a bigger limitation. It works for arrays. But when I look at a channel I think, "infinite streams of data". But you don't access a channel by index, so you can't hide the details of the type you're working with behind an integer. So if the collection I'm working with is a stream, the strategy breaks down.<br /><br />Moving on and restricting to arrays, if you wanted to follow this strategy for implementing grep, you would need (among other things) to insist on being passed a function that turns an int into a bool. Note that there is no way to specify that the function takes an int <i>and the collection</i>, because the arbitrary collection type can't appear in the interface definition. To produce that function you'd need to write a boilerplate function like this (untested):<br /><br />func bindCollection (f func (myType) bool, c myCollectionType) (curriedF func (i) bool) {<br /> curriedF = func (i) bool {<br /> f(c[i]);<br /> };<br /> return;<br />}<br /><br />Once you've added in this boilerplate per type, and then add in the currying call to every attempt to use grep, the pain of using these techniques is to the point of being unwieldy.<br /><br />That said, it looks to me like the addition of parametrized interfaces would be enough to meet the majority of the desire for generic programming. With that you could do things like write a generic filtering function that lets you take a function that converts type T into bool, and an input channel that provides elements of type T, and create an output channel that provides elements of type T. And then you could insert a grep on any channel you wanted without writing the obvious boilerplate code.Ben Tillyhttps://www.blogger.com/profile/04335648152419715383noreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-82856590415367621982009-11-12T12:34:28.850-08:002009-11-12T12:34:28.850-08:00Re generics:
I've been wondering why interfac...Re generics:<br /><br />I've been wondering why interfaces can't service to fill this gap in some way? <br /><br />From my understanding when I watched the intro, you can assign anything that implements an interface to a variable typed to that interface. If I wanted to emulate a c++ template (my reading of generics) that could operate on any type I would have to make sure my types satisfied the template requirements. <br /><br />Likewise, can I not make my types conform to an interface and then have a function which is declared to accept that interface as a paramter (bad phaasing, accept an interface? accept an implementaation of the interface? You get the idea...) and work with it in the same "generic" way?<br /><br />Just a thought...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-82109967481435605272009-11-12T11:17:13.604-08:002009-11-12T11:17:13.604-08:00@Jason: From my viewing of the tech talk it was cl...@Jason: From my viewing of the tech talk it was clear to me that they know that people want generics, but I didn't get the sense that they were sold on providing them yet.<br /><br />The existence of deadlock detection is good. I'll be interested to see what happens with that.<br /><br />@ephelon: A mixin isn't <i>just</i> the implementation of some methods. A mixin is a contract that it will implement some methods for you if you implement the API it expects. By contrast a Java interface is a contract enforced at compile time that you implement a given API, but it can't implement any standard behavior based on that API.<br /><br />Go's interfaces are a mix of those two behaviors. To be precise it is a compile time enforced contract that you implement a specified API that can also implement standard behavior on top of that. But when people start using them, I suspect the design patterns that emerge will be very reminiscent of what people do with mixins.Ben Tillyhttps://www.blogger.com/profile/04335648152419715383noreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-41853577922554648602009-11-12T10:22:59.917-08:002009-11-12T10:22:59.917-08:00Mixins are an implementation of some methods, wher...Mixins are an implementation of some methods, whereas interfaces are a contract to implement a particular set of methods.<br /><br />The novel feature of interfaces in Go is that you are not required to specify them explicitly on your types. It's this idea that erases the type heirarchy that becomes so much of a burden in OO centric designs.Unknownhttps://www.blogger.com/profile/14744811431514011788noreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-1882008167794885562009-11-12T10:04:23.149-08:002009-11-12T10:04:23.149-08:00I suspect Go designers wanted to keep the language...I suspect Go designers wanted to keep the language as similar to Kernighan as poss. so that they could facilitate the upgrade of a heap of prior-art that is already out there (most importantly the Linux kernel). <br /><br />Ideally such an upgrade would mainly involve stripping out artefacts, such as garbage collection and then bingo you have a burgeoning Go asset-base which is basically refined by the process.jorjunhttps://www.blogger.com/profile/07805277853137959854noreply@blogger.comtag:blogger.com,1999:blog-2316765421340036602.post-87105039459744613122009-11-12T09:54:58.264-08:002009-11-12T09:54:58.264-08:001) If you watch the Tech Talk, it is clear that th...1) If you watch the Tech Talk, it is clear that they want to add generics, they just haven't figured out a good way to do it yet<br /><br />2) They do have deadlock detection. I don't know the details, but I've gotten a "deadlock detected" message from the runtime when messing around with channels.Jason Mhttps://www.blogger.com/profile/13589756068468313032noreply@blogger.com