Go and Rust – objects without class

https://lwn.net/SubscriberLink/548560/26d15e832d21a483/

by usea • 13 years ago

142 57 13 years ago

metajack2• 13 years ago

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

strmpnk• 13 years 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!"

drothlis2• 13 years 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

drivebyacct2• 13 years ago

Wow, that's a damn good/smart policy of them, makes me want to get a subscription.

metajack2• 13 years ago

I stand corrected. What a great policy! If I wasn't already a subscriber, I would immediately subscribe :)

gillianseed• 13 years 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.

evincarofautumn4• 13 years 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.

pjmlp2• 13 years 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.

PommeDeTerre8• 13 years 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.

riffraff3• 13 years ago

I am not sure the issue of “I don’t make sense in this derived class” is solved by decoupling types and inheritance.

For example, given the article's GO code:

    type file interface {
	Read(b Buffer) bool
	Write(b Buffer) bool
	Close()
    }

my first thought was: wait, not all files are writable, that interface is ill specified.

I do think subtyping and subclassing should be different things, but it's not a panacea against bad specifications.

georgemcbay• 13 years ago

That interface isn't great, but that interface isn't coming from Go. I realize you aren't claiming it is, and you're absolutely right that Go's interfaces don't automatically "solve" issues of bad design. Programmers are free to come up with bad interface designs in Go just as easily as they came up with bad class designs in Java or C++. This is just to avoid confusion for people who aren't generally familiar with Go but read this article.

The Go standard io library has a Reader interface:

  type Reader interface {
      Read(p []byte) (n int, err error)
  }

a Writer interface:

  type Writer interface {
      Write(p []byte) (n int, err error)
  }

and a ReadWriter interface which uses type embedding to combine both:

  type ReadWriter interface {
      Reader
      Writer
  }

Idiomatic Go will break interfaces up into pretty discrete bits of functionality and use type embedding to build up more complex interfaces. The article does show this a little bit with its seekable interface but fails in some other areas and I kind of wish it just used the real io package interfaces or else examples of something not covered better by the actual Go standard library.

fauigerzigerk2• 13 years ago

I think this points to a seperate issue as well: Often times we have a choice to express the same thing through types or through state. As the influence of functional languages grows, we tend to choose types more often.

It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it has been created. But conceptually, files can be written to, just not always.

Another example makes that clearer. Adults can do things that minors can't. So, for instance, a signContract() method would have to go on the Adult type not on the Person type. But people grow older, so at any point in time some objects conceputally change their type from Minor to Adult.

Technically this is not a difficult problem to solve. But it shows the disconnect between our natural language concepts and the ever more type centered way of modelling we use in modern software design.

pat_punnu• 13 years ago

"If you think of a type as a set of possible values"

You can't do that! You fall foul of Russell's paradox - sets as types simply don't work!

vanderZwan• 13 years ago

Elaborate please?

Tobu• 13 years ago

Nope, Russel's paradox requires set membership axioms + a non-constructive definition of sets. Types are constructive here.

tomp• 13 years ago

> then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype

I'm sure this makes sense and is well-though-out, but I just can't understand it. What difference does it make if `Dog < Animal` are classes or types? Still any dog is an animal and not any animal is a dog. Or am I missing something?

bitdiddle• 13 years ago

you're not missing something, I believe the comment just got it flipped, and was referring[1] to problems relating to covariance and contravariance, when one tries to view OOP in terms of type theory.

[1] http://en.wikipedia.org/wiki/Covariance_and_contravariance_(...

munificent4• 13 years ago

> 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.

You have this exactly backwards. A subclass is a subtype. A superclass is a supertype.

Let's say you have superclass A and derive subclass B from it. In the universe of all possible values, some will be A but not B (they will either be direct instances of A, or instances of some other subclass of A). But every B will also be an A by definition since B is-a A.

Therefore the set of values that are B is a subset of the set of values that are A.

evincarofautumn4• 13 years ago

I was a bit backward with my language. What I was trying to get at is that many OO languages encourage you to add fields in derived classes. This makes the derived class a supertype, being a larger set that fully includes the set of its parent class. You’re adding elements to a product type. But this often breaks substitutability, so to conflate class inheritance (a useful concept) with subtyping (another useful concept) is fraught with problems.

gngeal• 13 years ago

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.

Nope. A subclass is usually (not always!) a subtype, not the other way round. Or, more specifically (and accurately), most statically-typed class-based OO languages treat subclasses in their type systems as subtypes by default, i.e., they assume that a subclass instance can act as an instance of its superclass, LSP-wise. This, I believe, is as accurate statement as one can make (on this level of generality).

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.

It's a definition of a superset, if Y is the superset and X is the subset.

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”.

That's a part of why I believe that static typing doesn't make too much sense when it comes to OO languages (with (sub)classes). If static typing is supposed to take care of subtype assignability statically and the semantics of the behaviour of derived classes can break the LSP assumptions, static typing becomes sort of worthless.

mixedbit• 13 years 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• 13 years ago

There is a similar model in Lua by using closures for methods and upvalues for encapsulated state.

Jach• 13 years ago

From 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• 13 years 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- nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ

usea• 13 years 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• 13 years 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• 13 years 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.

Go and Rust – objects without class

Related Stories