
Go and Rust – objects without class (2013) - Immortalin
https://lwn.net/Articles/548560/
======
steveklabnik
Being from 2013, this is speaking about Ancient Rust, but after giving this a
quick re-read, it still seems up to date, with maybe minor syntax and idiom
issues.

We _will_ be adding some sort of thing kind of like inheritance to Rust.
[https://github.com/rust-lang/rfcs/issues/349](https://github.com/rust-
lang/rfcs/issues/349) is the RFC issue, and it outlines:

    
    
      * cheap field access from internal methods;
      * cheap dynamic dispatch of methods;
      * cheap downcasting;
      * thin pointers;
      * sharing of fields and methods between definitions;
      * safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable;
      * syntactically lightweight or implicit upcasting;
      * calling functions through smartpointers, e.g. fn foo(JSRef<T>, ...);
      * static dispatch of methods.
    

That being said, we don't expect this to ever be the primary method of
modeling in Rust. It's just that sometimes, you do have something which is
legitimately represented by inheritance or something like it.

~~~
wrl
Is there any schedule for when that'll be worked on? It's a big thing I'm
waiting on for porting some UI toolkit work to Rust.

~~~
steveklabnik
Everyone is working on HIR/MIR at the moment, because it will enable a lot of
different kinds of work to happen in parallel after it lands.

The stage it's in is "Niko has a draft RFC that he hasn't published yet." Then
there will be discussion, and then implementation.

~~~
heinrich5991
What's HIR/MIR?

~~~
steveklabnik
To build on the other answer, right now, the compiler does

    
    
      AST -> LLVM IR
    

Which works, but you have to do all of the compilation passes and static
checks on the AST. After this work is done, we'll have

    
    
      AST -> HIR -> MIR -> LLVM IR
    

These two intermediate representations will make it easier to write frontends
and backends to Rust, as well as making it easier to implement various
optimization and analysis passes, and making them faster.

Also, in today's world, for example, we can't stabilize syntax extensions
because we'd have to stabilize the AST. But we _can_ stabilize {H,M}IR, much
more easily. On the backside, we're very coupled to LLVM right now, and while
that probably won't change, if someone wanted to write a backend, they could
write their own codegen based off of MIR.

------
cmrdporcupine
Smalltalk-72 (well, Smalltalk before Smalltalk-76) did not have inheritance.
And I believe Alan Kay is on record indicating he felt that inheritance in
Smalltalk had often been misapplied or not well understood, and spoke well of
Self and other experiments with classless object models.

If we're in the "OO" world, and need something analogous to inheritance, I'd
rather have an object system with tools for explicit delegation over a system
which tries to conflate delegation of behaviour with subtyping. IMHO this is
one of the greatest uglinesses of Java (C++ has it too but it's not used much
these days.)

~~~
chimeracoder
Yes, Alan Kay was very clear that he does not believe inheritance to be a key
part of object-oriented programming.

> OOP to me means only messaging, local retention and protection and hiding of
> state-process, and extreme late-binding of all things. It can be done in
> Smalltalk and in LISP. There are possibly other systems in which this is
> possible, but I’m not aware of them.

For context, he said this in 2003, at the height of Java's popularity.

~~~
JulianMorrison
Erlang probably also counts.

~~~
cmrdporcupine
[http://blog.blainebuxton.com/2003/09/erlang-i-got-
following-...](http://blog.blainebuxton.com/2003/09/erlang-i-got-following-
reply-from-alan.html)

Kay says: Erlang is worth looking at.

------
ryanolsonx
It's refreshing to write software with these languages and not having to deal
with standard OO.

~~~
aikah
> Both Rust and Go add some new and interesting ideas which, like languages
> before them, will initially attract programmers, but will ultimately earn
> both languages their share of derision, just as there are plenty of
> detractors for C++ and Java today.

~~~
_sh
"There are only two kinds of languages: the ones people complain about and the
ones nobody uses" \--Bjarne Stroustrup

~~~
thomasz
That's a bad cop out. There are widely used languages like c# and python that
cause very little whining.

~~~
dcsommer
Define "very little"...

~~~
choudanu4
Language feature-wise, I think python 3 has very little complained about it.
The chief complaints about python I hear are anything to do with packaging
software and multi threading the second of which will hopefully be fixed by
3.7.

Obviously, the 2 to 3 debacle is a constant source of grief, but I don't think
that necessarily fits in with the subject at hand: language features that
people contest over.

------
segmondy
Lisp's CLOS has defclass for class defintions, but not your typical class that
encapsulates data and code. You can do just fine with defstruct and make good
use of CLOS. There are very few things that are new under the sun. :-]

~~~
lispm
DEFSTRCUT uses inheritance, too. single.

------
realharo
> _If this restriction were to be encoded in the type system, GtkMenuShell
> would not be a true subtype of GtkContainer as it cannot be used in every
> place that a GtkContainer could be used — specifically it cannot be the
> target of gtk_container_add(myButton)._

This is easily solvable by making the Container be a generic class "Container
of <T extends Widget>". If the language supports such things of course, so not
really talking about GTK specifically here. Then a Container<MenuItem> is not
a subtype of Container<Widget> (so you're not violating LSP), yet you can
still write code that operates on all kinds of containers without giving up
any compile-time type checking.

I agree with a lot of the other things in the article, just this was not a
particularly good example, because it's more about the shortcomings of a
specific language than the shortcomings of subtype polymorphism in general.

------
Animats
Structure embedding is not inheritance. It's just structures as first class
types. This becomes clear as soon as you create a structure that contains two
strings.

------
tambourine_man
Javascript's influence?

If so, the circle is now complete, as we are about to get classes in ES6

~~~
cmrdporcupine
Classlessness in OO systems was around a long time before JS was even
conceived of.

I recommend this book: [http://www.amazon.com/s?search-alias=stripbooks&field-
isbn=9...](http://www.amazon.com/s?search-alias=stripbooks&field-
isbn=9814021253)

"Prototype-Based Programming: Concepts, Languages and ApplicationsMay 14, 1999
by James Noble and Antero Taivalsaari"

The first OO language I learned was the embedded programming language of
LambdaMOO ("MOO"), which was used to extend the virtual world. It was
prototype based, with a single delegate called the parent subbing in. It still
had inheritance, but a different kind.

~~~
tambourine_man
_Classlessness in OO systems was around a long time before JS was even
conceived of._

Oh I know that. It's just that being the most popular programing language in
the world helps setting trends, even when you don't invent them.

~~~
cmrdporcupine
I find it unfortunate that lack of classes is seen as some chief defect of JS.
It's actually one of the things I like about it.

Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object
system I think is nice.

~~~
aikah
Well , not anymore since ES2015 has classes,class inheritance,super and co.
Prototypical inheritance is bizarre, verbose and dangerous.

~~~
masklinn
ES2015 doesn't have classes, it has a class statement which desugars to
prototypal inheritance.

And as Self demonstrated long before Javascript even existed, prototypal
inheritance is neither bizarre nor verbose let alone dangerous. As with most
other things, Javascript just has a completely mangled version of it for (I
can only assume) original implementation simplicity.

~~~
cmrdporcupine
Yes I find it very unfortunate that 99% of people's exposure to 'prototype
inheritance' is JS's rather inelegant form of it. Though like many things with
JS if you are disciplined it can be used elegantly.

