Why Go And Rust Languages Abandon Inheritance

Hello everyone, I am Hu Ge. Today, let’s talk about why Go and Rust languages have given up inheritance. This topic may seem dull, but there are many interesting technical thoughts behind it, and even some “old jokes” among programmers to share.

Without further ado, let’s get straight to the point.🐯

First of all, we must admit that Object-Oriented Programming (OOP) is not a novel concept anymore. The well-known languages like Java and C++ basically rely on inheritance to organize code.

But have you noticed that as our codebase grows, inheritance often brings us a lot of trouble? Sometimes, to modify a feature, you have to trace back from the subclass all the way to the ancestor class, making you feel like Sherlock Holmes solving a case.😂

The Choice of Go and Rust: Say Goodbye to Inheritance, Embrace Composition

Why have these two languages, Go and Rust, decisively abandoned inheritance? It’s not because they “despise” object-oriented programming, but because they chose a more flexible way to solve problems—composition. You might ask, what is composition? No rush, let’s discuss it step by step.

The problem with inheritance is that although it feels great at first and code reuse is easy and enjoyable, it can lead to many potential troubles, especially when the system becomes complex. Inheritance is like running a chain restaurant; although there are unified standards, once one branch wants to add some unique dishes, you might have to integrate the menu, and the result becomes more and more chaotic.🐔🦆

Let’s consider a classic example: we have a duck and a chicken, and we find that they can both fly and have two legs and two wings. So we abstracted a parent class called “Bird” that both the chicken and the duck inherit from. At first glance, it seems perfect—code reuse and clear logic. But when we continue to expand our business—here comes the penguin. Oh no, this is a big problem; penguins can’t fly; they are just swimming birds. You can’t let penguins inherit from flying birds, can you?🐧

So, you have to continue to break it down and create subclasses of birds: “Flying Bird” and “Non-Flying Bird”. Later on, a rubber duck comes along, which not only can’t fly but isn’t even a real bird. At this point, your design begins to distort, and everyone starts debating what exactly is a bird? What should birds be able to do?

Composition over Inheritance: Flexible and Powerful

At this point, the designers of Go and Rust couldn’t stand it anymore. They believe that instead of dealing with a complex inheritance system, it’s better to keep it simple and use composition to solve the problem. The duck has wings, can fly, and can quack—these traits are directly combined into the duck object, without needing to inherit the entire “bird family” structure. As for the penguin? We just won’t add the “flying” trait; the penguin only needs the ability to “swim”.

In Go and Rust, this method of composition makes the code more flexible and easier to maintain. For example:

Composition in Go

package main

import "fmt"

// Define Flyable interface
type Flyable interface {
    Fly()
}

// Chicken class
type Chicken struct {}

func (c Chicken) Fly() {
    fmt.Println("The chicken is flying!")
}

// Penguin class
type Penguin struct {}

func (p Penguin) Swim() {
    fmt.Println("The penguin is swimming!")
}

func main() {
    var chicken Chicken
    var penguin Penguin
    
    chicken.Fly()    // The chicken is flying
    penguin.Swim()   // The penguin is swimming
}

trait Flyable {
    fn fly(&self);
}

struct Chicken;

impl Flyable for Chicken {
    fn fly(&self) {
        println!("The chicken is flying!");
    }
}

struct Penguin;

impl Penguin {
    fn swim(&self) {
        println!("The penguin is swimming!");
    }
}

fn main() {
    let chicken = Chicken;
    let penguin = Penguin;

    chicken.fly();   // The chicken is flying
    penguin.swim();  // The penguin is swimming
}