Go and Rust – objects without class • Hacker News Board

Go and Rust – objects without class

#1

Post by usea » Sat, May 04, 2013, 2:09 AM UTC

Go and Rust – objects without class
lwn.net

Re: Go and Rust – objects without class

#2

Post by metajack » Sat, May 04, 2013, 3:49 AM UTC

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

Re: Go and Rust – objects without class

#3

Post by strmpnk » Sat, May 04, 2013, 4:25 AM UTC

metajack wrote: post #2

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

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!"

Re: Go and Rust – objects without class

#4

Post by gillianseed » Sat, May 04, 2013, 4:29 AM UTC

metajack wrote: post #2

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

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.

Re: Go and Rust – objects without class

#5

Post by evincarofautumn » Sat, May 04, 2013, 5:22 AM UTC

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.

Re: Go and Rust – objects without class

#6

Post by pjmlp » Sat, May 04, 2013, 5:50 AM UTC

evincarofautumn wrote: post #5

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 th…

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.

Re: Go and Rust – objects without class

#7

Post by riffraff » Sat, May 04, 2013, 6:53 AM UTC

evincarofautumn wrote: post #5

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 th…

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.

Re: Go and Rust – objects without class

#8

Post by georgemcbay » Sat, May 04, 2013, 7:21 AM UTC

riffraff wrote: post #7

evincarofautumn wrote: post #5

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 th…

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…

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.

Re: Go and Rust – objects without class

#9

Post by pat_punnu » Sat, May 04, 2013, 7:31 AM UTC

evincarofautumn wrote: post #5

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 th…

"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!

Re: Go and Rust – objects without class

#10

Post by [deleted] » Sat, May 04, 2013, 7:52 AM UTC

riffraff wrote: post #7

evincarofautumn wrote: post #5

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 th…

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…

[deleted]