8 ms·

Go and Rust – objects without class

142 points by usea 13y ago

metajack 13y ago
This is a good article, although I'm not sure its appropriate to post a subscriber link.
- strmpnk 13y ago
  It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"
  - drothlis 13y ago
    "Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared." -- https://lwn.net/op/FAQ.lwn#slinks https://lwn.net/op/FAQ.lwn#slinks
    - justincormack 13y ago
      It is probably preferable to the free link being posted a week later as it makes people aware of the subscription.
  - drivebyacct2 13y ago
    Wow, that's a damn good/smart policy of them, makes me want to get a subscription.
    - drothlis 13y ago
      All articles are also available free of cost one week after the initial publication.
  - metajack 13y ago
    I stand corrected. What a great policy! If I wasn't already a subscriber, I would immediately subscribe :)
- gillianseed 13y ago
  the lwn editor(s?) periodically post subscriber only articles here on HN, I would be surprised if this article wasn't posted with lwn's blessing.
evincarofautumn 13y ago
The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially the definition of superset. That is what the Liskov Substitution Principle is about. In C++ and other languages with support for object-oriented programming, a subclass is not necessarily a supertype: virtual functions can throw “I don’t make sense in this derived class”. And a supertype is not necessarily a subclass: templates offer the benefit of the doubt when it comes to static interfaces. This mismatch leads, in my experience, to interfaces that are ill-specified at best and buggy at worst—so it’s nice to see those issues addressed.
- pjmlp 13y ago
  The problem I see, is that the average programmers are only aware of the OO models popularized by C++, Java and friends, while there are quite many to choose from. This is one reason why so many have problems with prototype inheritance in JavaScript, which is also not the only language having it. I find positive that so many OO models exist to choose from.
  - PommeDeTerre 13y ago
    Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains. The same can't be said of JavaScript's prototype-based OO. It's not that people have trouble understanding it; they know it perfectly well. It's just that, when being used to write real-world software, it is nowhere near as convenient and practical as class-based OO. This is largely why we see so much effort go toward faking class-based OO within so many different JavaScript libraries and applications. JavaScript doesn't natively (yet) provide the tooling that developers need (class-based OO), so they're forced to try to implement it themselves using what JavaScript does offer. And the results usually are quite horrid. The fact that Self, Io and other prototype-based languages never really took off is similarly related, I suspect. Choice between different OO models isn't a bad thing. But when it comes to real-world software development, where there are clients, deadlines, and money to be made, developers need tools that work. Class-based OO has proven itself as a useful tool. Prototype-based OO has been more of a hindrance than a benefit, on the other hand.
mixedbit 13y ago
I've been recently watching Structure and Interpretation of Computer programs, where it is demonstrated that first class functions and assignment operator with nested scope are enough to implement object oriented system. The simplest example given is a Counter object. Translated from Lisp to Javascript it goes like this: function make_counter() { var val = 0; function get() { return val; } function inc() { val += 1; } return [get, inc] } function get_count(counter) { return counter[0](); } function inc_count(counter) { counter[1](); } var counter = make_counter(); console.log(get_count(counter).toString()); inc_count(counter); inc_count(counter); console.log(get_count(counter).toString()); This gives polymorphism (you can define make_fast_counter() that increases by 2 and still use get_count() and inc_count() with it) and encapsulation (you can not decrease the count).
- kzrdude 13y ago
  There is a similar model in Lua by using closures for methods and upvalues for encapsulated state.
- Jach 13y ago
  From http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
discreteevent 13y ago
From a high level programming in Go looks to me to be very like programming with Microsoft's COM. It's interface oriented, no inheritance. You could say that this is the purest form of OO if you take Alan Kay's viewpoint that the emphasis should be on the messages and not the object. In COM you have QueryInterface and in Go you have interface matching and casting. QueryInterface or an interface cast is like a hinge between dynamic and static typing. You get great flexibility but still preserve your abstractions in that you never depend on an implementation. Of course you can do this in, say, java by using instanceof to match against an interface but the difference with COM and Go is that it is a primary mechanism and so the code written in the language tends to use this pattern a lot. i.e. It's encouraged. See this example from Russ Cox: https://groups.google.com/forum/#!msg/golang- https://groups.google.com/forum/#!msg/golang- nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ
usea 13y ago
I've been developing medium-to-large projects in mostly C# over the past two years. One thing about my style that has changed over that course of time is that I almost never use inheritance anymore. When I was in school, it was my primary tool for code reuse, but now I find it conflates solutions to different problems, as well as hampering readability. My style now is small classes with a few, small methods each and lots of composition. I find it easier to reason about code, separate functionality, and reuse pieces. Also, placing unrelated state in separate classes really discourages a lot of the common mistakes with OOP. Admittedly I don't do as much reading on the subject as I should. I am probably discovering things that were common knowledge 25 years ago. Maybe this is a common road that developers take. That's fine with me. Rust's and Go's OOP style appeals to me quite a bit. I have only written small things in those languages, so I'm not exactly well-versed in what larger projects look like. Before reading this article, I wasn't able to put into words what bothered me about the style of inheritance in languages I've used up until now.
- noblethrasher 13y ago
  Same here. I used to look for places to use inheritance but now only inherit from abstract classes, seal everything else by default, and mark all of my fields readonly.
pocketstar 13y ago
I interpreted the title 'Go and Rust' as in 'go and make some iron-oxide' evidence that I am a mechanical engineer and programming is just a hobby.

142 points by usea 13y ago

metajack 13y ago

This is a good article, although I'm not sure its appropriate to post a subscriber link.

strmpnk 13y ago
It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"
- drothlis 13y ago
  "Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared." -- https://lwn.net/op/FAQ.lwn#slinks https://lwn.net/op/FAQ.lwn#slinks
  - justincormack 13y ago
    It is probably preferable to the free link being posted a week later as it makes people aware of the subscription.
- drivebyacct2 13y ago
  Wow, that's a damn good/smart policy of them, makes me want to get a subscription.
  - drothlis 13y ago
    All articles are also available free of cost one week after the initial publication.
- metajack 13y ago
  I stand corrected. What a great policy! If I wasn't already a subscriber, I would immediately subscribe :)
gillianseed 13y ago
the lwn editor(s?) periodically post subscriber only articles here on HN, I would be surprised if this article wasn't posted with lwn's blessing.

evincarofautumn 13y ago

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially the definition of superset. That is what the Liskov Substitution Principle is about. In C++ and other languages with support for object-oriented programming, a subclass is not necessarily a supertype: virtual functions can throw “I don’t make sense in this derived class”. And a supertype is not necessarily a subclass: templates offer the benefit of the doubt when it comes to static interfaces. This mismatch leads, in my experience, to interfaces that are ill-specified at best and buggy at worst—so it’s nice to see those issues addressed.

pjmlp 13y ago
The problem I see, is that the average programmers are only aware of the OO models popularized by C++, Java and friends, while there are quite many to choose from. This is one reason why so many have problems with prototype inheritance in JavaScript, which is also not the only language having it. I find positive that so many OO models exist to choose from.
- PommeDeTerre 13y ago
  Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains. The same can't be said of JavaScript's prototype-based OO. It's not that people have trouble understanding it; they know it perfectly well. It's just that, when being used to write real-world software, it is nowhere near as convenient and practical as class-based OO. This is largely why we see so much effort go toward faking class-based OO within so many different JavaScript libraries and applications. JavaScript doesn't natively (yet) provide the tooling that developers need (class-based OO), so they're forced to try to implement it themselves using what JavaScript does offer. And the results usually are quite horrid. The fact that Self, Io and other prototype-based languages never really took off is similarly related, I suspect. Choice between different OO models isn't a bad thing. But when it comes to real-world software development, where there are clients, deadlines, and money to be made, developers need tools that work. Class-based OO has proven itself as a useful tool. Prototype-based OO has been more of a hindrance than a benefit, on the other hand.

mixedbit 13y ago

I've been recently watching Structure and Interpretation of Computer programs, where it is demonstrated that first class functions and assignment operator with nested scope are enough to implement object oriented system. The simplest example given is a Counter object. Translated from Lisp to Javascript it goes like this: function make_counter() { var val = 0; function get() { return val; } function inc() { val += 1; } return [get, inc] } function get_count(counter) { return counter[0](); } function inc_count(counter) { counter[1](); } var counter = make_counter(); console.log(get_count(counter).toString()); inc_count(counter); inc_count(counter); console.log(get_count(counter).toString()); This gives polymorphism (you can define make_fast_counter() that increases by 2 and still use get_count() and inc_count() with it) and encapsulation (you can not decrease the count).

kzrdude 13y ago
There is a similar model in Lua by using closures for methods and upvalues for encapsulated state.
Jach 13y ago
From http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

discreteevent 13y ago

From a high level programming in Go looks to me to be very like programming with Microsoft's COM. It's interface oriented, no inheritance. You could say that this is the purest form of OO if you take Alan Kay's viewpoint that the emphasis should be on the messages and not the object. In COM you have QueryInterface and in Go you have interface matching and casting. QueryInterface or an interface cast is like a hinge between dynamic and static typing. You get great flexibility but still preserve your abstractions in that you never depend on an implementation. Of course you can do this in, say, java by using instanceof to match against an interface but the difference with COM and Go is that it is a primary mechanism and so the code written in the language tends to use this pattern a lot. i.e. It's encouraged. See this example from Russ Cox: https://groups.google.com/forum/#!msg/golang- https://groups.google.com/forum/#!msg/golang- nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ

usea 13y ago

I've been developing medium-to-large projects in mostly C# over the past two years. One thing about my style that has changed over that course of time is that I almost never use inheritance anymore. When I was in school, it was my primary tool for code reuse, but now I find it conflates solutions to different problems, as well as hampering readability. My style now is small classes with a few, small methods each and lots of composition. I find it easier to reason about code, separate functionality, and reuse pieces. Also, placing unrelated state in separate classes really discourages a lot of the common mistakes with OOP. Admittedly I don't do as much reading on the subject as I should. I am probably discovering things that were common knowledge 25 years ago. Maybe this is a common road that developers take. That's fine with me. Rust's and Go's OOP style appeals to me quite a bit. I have only written small things in those languages, so I'm not exactly well-versed in what larger projects look like. Before reading this article, I wasn't able to put into words what bothered me about the style of inheritance in languages I've used up until now.

noblethrasher 13y ago
Same here. I used to look for places to use inheritance but now only inherit from abstract classes, seal everything else by default, and mark all of my fields readonly.

pocketstar 13y ago

I interpreted the title 'Go and Rust' as in 'go and make some iron-oxide' evidence that I am a mechanical engineer and programming is just a hobby.