Go and Rust – objects without class • Hacker News Board

Re: Go and Rust – objects without class

#41

Post by pcwalton » Sat, May 04, 2013, 6:42 PM UTC

PommeDeTerre wrote: post #21

pjmlp wrote: post #6

Earlier quoted context omitted.

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.

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

You keep showing up in unrelated threads talking about how JavaScript is terrible, even when it isn't remotely relevant to the topic at hand.

Case in point: the models of Rust and Go have nothing to do with prototype-based OO. Typeclasses as Rust uses are in fact about as far as you can get from prototype-based OO: they are less dynamic, not more dynamic. There is no virtual dispatch involved at all. Neither Rust nor Go have any support for prototype-based OO.

I understand you dislike JavaScript, but would you please stop derailing comment threads that have nothing to do with it?

Re: Go and Rust – objects without class

#42

Post by cpeterso » Sat, May 04, 2013, 7:36 PM UTC

evincarofautumn wrote: post #40

munificent wrote: post #35

Earlier quoted context omitted.

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

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

When a derived type add new fields, it is restricting the type's range, not expanding the base type's capabilities.

Re: Go and Rust – objects without class

#43

Post by metajack » Sat, May 04, 2013, 8:52 PM UTC

strmpnk wrote: post #3

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

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

Re: Go and Rust – objects without class

#44

Post by PommeDeTerre » Sat, May 04, 2013, 9:12 PM UTC

pcwalton wrote: post #41

PommeDeTerre wrote: post #21

Earlier quoted context omitted.

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

You keep showing up in unrelated threads talking about how JavaScript is terrible, even when it isn't remotely relevant to the topic at hand. Case in point: the models of Rust and Go have nothing to do with prototype-based OO. Typeclasses as Rust uses are in fact about as far as you can get from prototype-based OO: they are less dynamic, not more dynamic. There is no virtual dispatch involved at all. Neither Rust nor…

Patrick, please notice that I replied to pjmlp's comment, which specifically mentioned JavaScript and its prototype-based OO.

While the article may be about Rust and Go, some of the discussion here may naturally go beyond the article's content.

Re: Go and Rust – objects without class

#45

Post by usea » Sat, May 04, 2013, 9:48 PM UTC

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.

Re: Go and Rust – objects without class

#46

Post by SeanDav » Sat, May 04, 2013, 9:59 PM UTC

PommeDeTerre wrote: post #21

pjmlp wrote: post #6

Earlier quoted context omitted.

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.

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

You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO?

Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO.

Once again, where is your proof?

Re: Go and Rust – objects without class

#47

Post by pocketstar » Sat, May 04, 2013, 10:09 PM UTC

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.

Re: Go and Rust – objects without class

#48

Post by PommeDeTerre » Sat, May 04, 2013, 10:15 PM UTC

SeanDav wrote: post #46

PommeDeTerre wrote: post #21

Earlier quoted context omitted.

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

You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO? Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO. Once again, where is your proof?

Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches.

With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously better in many ways.

Have you ever worked on a significantly large JavaScript-based system that has been created by many developers over the course of several years, or even a decade? I find most people that have will know what I'm talking about. Experiencing it for yourself is much better than any academic citation I could give you.

Re: Go and Rust – objects without class

#49

Post by sixbrx » Sat, May 04, 2013, 10:19 PM UTC

cpeterso wrote: post #42

evincarofautumn wrote: post #40

Earlier quoted context omitted.

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

When a derived type add new fields, it is restricting the type's range, not expanding the base type's capabilities.

Yes and no. I think the poster does make an interesting point.

If the parent class is instantiable - which is a code smell already but also very common and even encouraged by some OO evangelizing[1], as is the case for the "colored point" example - then he's right, the derived class which adds fields does admit more values than the parent class does (excluding child values).

[1] encouraged by the commonly heard advice: "if you don't like exactly what the class does, then derive from it and supply your own customizations". Ie. this is the use of inheritance for ad-hoc customization, as opposed to a design-first approach which would have the parent be abstract (which has its own problems of course such as requiring great foresight).

Re: Go and Rust – objects without class

#50

Post by PommeDeTerre » Sat, May 04, 2013, 10:20 PM UTC

pjmlp wrote: post #37

PommeDeTerre wrote: post #31

Earlier quoted context omitted.

I don't think the assertion that JavaScript's prototype-based OO is more expressive because it lets you fake partial implementations of class-based OO with relative ease is true. Now, if we could reliably implement class-based OO systems comparable to, or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, for example, then maybe we could say prototype-based OO is more expressive. However, al…

> So prototype-based OO fails to deliver both in terms of expressiveness and maintainability. It is just a worse technique, when considering the facts. Trying to pretend it's good at things it clearly isn't good at doesn't make much sense to me. You are focusing too much on prototype OO. The models offered by Smalltalk, Beta, CLOS, Haskell and quite a few others are different approaches to the classical model known t…

I focus on JavaScript and its attempt at prototype-based OO because there's a huge amount of such code that already exists, and more is being written each day. It poses practical problems affecting many developers today.

While Smalltalk, BETA, CLOS, Haskell and other languages do have their own approaches, we really don't see them being used anywhere near as much as JavaScript, C++ or Java are. Realistically, Haskell is seen rarely outside of academia, aside from some very isolated projects. C++, and then Java, put an end to any real momentum that Smalltalk had gained during the 1980s and 1990s. BETA and Common Lisp see very little usage these days, too. They are pretty much irrelevant in a discussion of applied software development.

I wouldn't attribute C's success and C++'s success purely to UNIX or enterprise users. In fact, many of the most significant users are open source projects. They're successful because what they offer is what developers need. Flexibility, performance, portability and in C++'s case, sensible and practical object-orientation. People go out of their way to use C and C++, even when it isn't as practical (such as under Windows and various embedded platforms). This is quite different from people using JavaScript, which is used mainly because it's the only practical option available for browser-based scripting.