Okay, thank you. We have to stay on our schedule. So our next speaker, Rona, she stood here
three years ago, but before the pandemic was a thing, and she gave us a challenge to solve
the go diversity problem within a year. Rona, is it solved?
As far as I can tell, yes. Well done. Well done. No, no. So actually, Marty has stole
this from me because, yeah, three years ago, I did challenge this forum to solve the problem
of lack of diversity within the Go community within a year. And then the pandemic hit and
it seems that these issues kind of took aside, were pushed aside, unfortunately. But we can
start again. So I'm here to talk to you today about a lighter topic is Go object oriented.
Now, it appears to be something that people have many opinions about. And I hope that
you do too because that will be fun. So I am Rona. I am a Google developer expert for Go.
I create workshops. That's kind of like my thing when I want to teach something. I make
a workshop about it. And in 2022, I kind of realized that after a few years of seeing
developers struggling with different paradigms around the Go typing system, specifically
with interfaces, I figured why not create a workshop about it. And I submitted it to
Go for Con Europe. It was the name of the Go workshop was object oriented design with
Go. And then the comments started coming. So something between object oriented is dead.
Somebody posted a comment on my tweet and then blocked me. Because apparently that's
how the internet works. So, yeah, and somebody blamed me for introducing Spring into Go.
Now, I have been a developer for 20 years, but I have not done any Spring in my life.
And that is such a specific accusation. I was fairly surprised. So I am not here to promote
my workshop, even though I am giving it again this year in Berlin in June, because that
will be bad. So what is object oriented programming? So it's the idea of separating
software into things or objects or concerns or instances and adding some functionality
to them usually called messages or methods or member functions. So that we can work
with software in a more intuitive way, the way that we understand how we interact with
the real world. That's it. Now, where there are things, it can get incredibly messy. That's
the business model behind Marie Kondo. Yeah. I felt the sigh. You don't have 14 items maximum
in your house. You're not alone. And we have this lovely quote from Joe Armstrong. The
problem with object oriented languages is that they've got all of this implicit environment
that they carry with them. You wanted a banana, but what you got was a gorilla holding a banana
and the entire jungle. And that feels like it does. It really does. So gone really went
a different way. It tried to sort of stay away from this. But we will see what remained
and what actually remained from this and what actually we were able to let go of in a second.
So we're going to hold a trial where we're going to check. You're going to be the jury.
You're going to decide if Go is object oriented. I'm going to try and convince you. I'm going
to show you the arguments for both sides. And I'm going to have to convince you that
it is object oriented or I am responsible for defamation. I am taking the goes good name
and dragging it through the mud, tarnishing it, hurting its reputation. You're the jury.
You will decide. So disclaimer, this is not a real trial. But and I'm the judge and the
rules are what I say they are, which is to say that these proceedings are going to be
ridiculous. But yeah, we're just going to have to do it. So what have we come to expect
from an object oriented language? Most of you know this by heart, really. We have classes
because classes and only classes can have methods. Classes can also have these constructors.
Classes are created, allowed to create objects safely. And we also expect inheritance. Objection.
So in go, we don't have classes. And therefore we don't have constructors. But we pretend
to have them. So here's where we pretend to have something. Now this one is quite fun.
So this is a package that I created. And you can see here that inside type robot, the Godoc
aggregated nicely, a function called new. Now you can see that it doesn't actually have
a receiver. It's not a method. It's not anything. And it's just a package level function that
the Godoc understood to be a constructor. And then he added it where it should be nicely
nested inside the robot type. Which is really interesting because what that means was that
the Go team essentially decided at some point that safe construction of objects is a tooling
problem, not a language problem. It's interesting. We work with constructors. Okay. All types
can have methods. So you've probably seen this or code similar to this at some point
in your life. So I created a new type my thing out of an integer. So we have a new type with
an underlying type int. I added a method foo to it using the receiver. Just remember that
we said earlier that we have objects interacting through messages. It's called a receiver because
it perceives. It's that easy. Come on. All together. Nobody agrees? What's going on?
Yeah, okay. Pathetic. I said I was going to judge. All right. And then we have, so now
we created a variable t of type my thing. We assigned it one. And then we're able to
call a method on t foo. Voila. We have a primitive type and it has a method. Because in Go, all
types are created equal. Thank you. Okay. So let's move on to inheritance. So we get
in Go. We get composition. We don't get inheritance. That's not something that's available to
us. So this little snippet here is supposed to show the difference. I created a type a.
It's an empty struct. I added a method foo to it. It has a method bar. foo calls bar.
That's nice. Returns bar. We have type p that embeds a. It can embed as many, as many as
many as many types as it wants. It embeds a. That means that now it has foo and bar.
And then it decided to override bar. Fine. Variable b of b lowercase b of type uppercase
b. To be confusing. Not to be confused. Okay. Get it. And we can call b.bar. And we expect
b.bar to be invoked directly. And then we call b.foo. Now, with inheritance, we would
expect b.foo, which returns a.bar, which is overridden, to be called. So we would expect
to get b in both cases. But that's not what's going to happen. Because we do not have this
type of polymorphism. That is true. Who was it that said it earlier? Raise your hands.
Round of applause to the gentleman. Okay. Moving on. So let's talk about single and multiple
inheritance because this really bugs me. So I started my career with seven years of C++.
And yes, it sounds biblical because it is. Thank you. Yeah. So I started with seven years
of C++. C++ actually has a really nifty feature. You can inherit a lot. You have multiple inheritance.
It's not limited. Java, Ruby, they allow you to inherit exactly once. That to me does not
feel like a feature. That feels like a limitation. I don't understand it. Let's say that you
have a truck and you want to describe a container of goods and a vehicle. You cannot inherit
from both. What do you do? Well, in Go we have composition. But in many, many languages that
offer inheritance, you only get single inheritance. Now, I will say this. If you feel, and I know
that a lot of people do, if you feel that inheritance is that important, it just doesn't
make sense that it will be so limited a feature that you will not be able to use properly or
fully. And I do believe also that that is the cause of all the messy code that we see
because the classes that I used to define were very small were one function, two functions.
I didn't have to make odd choices of what is going to go into a class or what wouldn't.
So it was really easy to be very expressive. So that's what I personally, my personal opinion
is about single and multiple inheritance. I don't feel in most common languages, since
it's usually single inheritance, I don't feel that it makes it something that is going to
determine whether a language is or isn't object oriented. Because if it is, then as far as
I'm concerned, single, any language that has single inheritance cannot be object oriented.
So Go is not object oriented. The usual argument summary, and I'm going to, like, you have
to understand that I'm aggregating here everything that was said to me over the internet, which
is a great source of information and also a great source of information. So Go is simple,
object oriented programming isn't, therefore Go is not object oriented. Go doesn't have
classes, so Go cannot be object oriented. It doesn't have inheritance, so it's not object
oriented. And lastly, and this one is a great argument, we're going to dive into that one.
Objects are not really messages, so Go is not object oriented. Now, this one is fun.
So this comes from the Alan Kay School. So all the fans of Alan Kay have jumped in to
let me know everything about the history of object oriented. So here's what I've got.
One person said, technically they aren't methods, so he's referring to method receivers. They
aren't methods on type T, they are functions where the first argument is type is the type.
The promotion to them as methods is syntactic sugar. It's why you can call, now look at
this, this is amazing. V.foo with bar or T, call the type, invoke a method on the type,
and provide V as a parameter. And it's true. Show you what it looks like. So same code
as before, we have a empty struct. We have method foo that we added to A. Quiet in the
court. We have method foo that we added to type A, which is nice. And we can invoke it
using two ways. One is clearly less common than the other. So this is the common way.
Or we can invoke it on the type and pass in lowercase a as a parameter. You have the screen?
That's why, by the way, a pointer receiver can be nil. So I have this game. I play this
game all the time with people who are new to go and I ask them what's going to happen.
So we are able to create methods with pointer receivers. So I add foo and make the receiver
a pointer. I create variable a, which is a pointer to uppercase a. It's zero value is
nil. And I invoke a.foo. And then I ask people what will happen. Now, we're not going to
be able to do this quiz here because we are late on time and we have to make up some time.
So I'm just going to run this. So high from foo is actually returned by foo, which means
that we are able to invoke a method on a nil pointer. It's possible because there is no
receiver. There is no actual receiver. Most of the time when we call a method in other
languages, what happens is that we have to go and go through some reference that's somewhere
in the address space of the variable itself. This tells us that it's not where the method
is at all. It's not where it's defined. It's not where the runtime looks for it. It's just
not.
So my co-organizer, my women who go co-organize it, Jessica Green saw this and said, ah, so
there is no spoon, which I thought was amazing because this is kind of a design thing, right?
So everything is in our minds. Really everything is in our minds. We sort of, you know, we
have these philosophical ideas and then we put them into code. If there is anybody who
actually thinks that the gopher that you saw, the gopher that you saw on the screen in the
maze, there is an actual gopher out there doing this, let me know. I want to hang out.
So where do receivers come from? So listen to this because this is very interesting.
Going to the Go team, the Inspiration 2 method receivers came from Oberon 2, which is the
object-oriented version of Oberon. Okay? And they're called receivers because they receive
messages, except there is no receiver. So everybody's right. Another thing that the
same person brought up, which is really cool, he said, well, I forgot to say who Alan Kay
was. What's wrong with me? Alan Kay is the creator of Smalltalk and also is considered
to be the person who coined the term object-oriented. So he's supposedly supposed to know stuff
about it. So that's why people quote him and that's fine. It's totally fine. And he has
a lot of opinions, which is also great. We encourage opinions. So what a person said
to me, so in Smalltalk, you don't need to explicitly declare that an object can have
a specific message. You send it a message and then it decides whether to handle it.
So duck typing. Now, this is really interesting. Can we do this in Go? Can we check if a certain
value, if it can handle a certain message or has, in layman's terms, has certain methods?
Well, the answer is yes through the magic of interface conversion. So again, we type
a, we added function foo. It doesn't do much. We don't actually care what it does. And we
created interface i, uppercase i. And this interface has one function, defines one function
foo that returns a string. And a coincidentally or pointer to a coincidentally also has foo,
which is a string. Now, this is where Go completely differently than other languages.
In Go, interfaces are implicit. In most languages, if you have, let's say, class A and you wanted
to implement interface i, you have to, at the time of creating that class, you have to say
something like class A implements i. That means that you cannot have a type that is
not aware, has no idea that an implements, that a certain interface exists and will implement
it. Not unless, not unless, that's why a lot of people move to scripting languages, because
that allows them to pick some code from the internet and use it. You know, just use it
unless of what's going on. And Go allows you to actually download some random code from
the internet and plug it in using your own interfaces. It's very strange. It's very unique.
So with that in mind, if you have implicit interfaces, it makes sense to be able to try
and be able to ask whether a type implements an interface, because maybe it does. In other
languages, it just doesn't make sense, because the answer will be no. Right? Right. Okay.
So therefore, we use interface conversion. Now, this is the syntax. What you need to
understand from this expression is that if everything was fine, then Val will have a
type, will have B, which is, which it points to A. And with the interface of i, inside
the interface of i, Val will have all of that and will be able to invoke foo, which is this
one, which is exactly what's going to happen. And this is how stringers work. Now, we said
that small talk, we said that, we said that small talk was created by Alan Kay and he
coined object-oriented. Well, actually, he created small talk with explicit, explicitly
with his ideas of what object-oriented is supposed to be. And it's important, because
according to Robert Grisimer, who is one of the creators of the Go programming language,
this is what, small talk was actually the inspiration for this kind of interface conversion,
so that at runtime, we can actually check if a type has certain methods. And Russ Cox
compared it to duck typing. And by the way, this is a really, really nice read. So if
you just Google Russ Cox duck typing, you will find it. It is a really nice read. He explains
how the runtime does it and also how the caching works, because obviously you cannot compute
well, compile time, you cannot compute every type against all the interfaces in the world.
It's really, really nice. And finally, we have a surprise witness. Martier is going
to be the proxy of said surprise witness. Do you have your?
I am here.
So before I introduce our witness, I am going to ask the witness, do you remember, given
an interview in 2010, to Danny Kalev?
I don't recall.
Well it's on the internet, so it must be true.
It's true.
I submit into evidence a web page. Exhibit 90210. So please read a portion of the text
from the web page in your own voice.
Go is an object oriented, even though it doesn't have the notion of a class, the type system
is more general. Any type, even basic types such as integers and strings, can have minutes.
Thank you very much. So what makes you such an expert to be able to say such, to make
some such claims?
I co-created the language.
You created the language. What is your name?
Rob Pike.
Thank you, Rob. New glasses?
Yeah, new dress. When they made it.
Thank you very much. Thank you, Martia.
So yes, Rob Pike actually said that in 2010. I don't know if he actually changed his mind
since. But the truth is that I feel that at this point it is clearly a matter of opinion.
So I would like to know yours since you are the jury.
Voting is now open. So the verdict. It's verdict time. I hope it's now open. Yeah, it is.
The co-team is not permitted to answer.
I believe one of my members asked the co-team last year if go is object oriented.
That's a dare.
I am going to give you 35 more seconds because we have to wrap it up.
Am I correct? You already see 105 judgments. 108. Oh, no.
I created a bunch of bots.
All right. So I have to close this. Unfortunately, let's find out what you said.
That's interesting. Why can't I see the results?
Yeah, I don't know what happened.
Let's do this. That's what I did. Wow.
Okay. So I am going to cancel these proceedings because clearly you're out of your minds.
As the judge, I condemn myself to providing you with stickers, lots and lots and lots
of stickers. Iris, Rona, thank you very much. I have to get off.
Thank you. If you have a sticker, you have also have to give her one if she convinced
you. Again, housekeeping announcement, if you submitted
lightning talk, check your mail, matrix, discord, WhatsApp, whatever you sent to me, I'll try
to contact you if you got accepted. If you aren't sure, our master on account has
contacted me on Twitter.