I don't think you need inheritance for this at all. Inheritance might make providing an API a little bit easier, but it is not required, especially not for the consumer of an API. That Go structs have methods and you can embed structs into other structs and also be able to call those methods gives just enough "object orientation" which is necessary. The Go gtk bindings are a good example for this. For the user, they feel like a normal object oriented API.

Strictly speaking, no language features are required other than the bare minimum, and we can write everything in assembly. The fact of the matter is that golang remains has failed to make headway into the UI space, and its language features make it very poor to work with for large code bases.

That is a non-argument. I was clearly not speaking about the bare minimum, but about required in a practical sense. Have you looked at the Go gtk bindings? If not, do so! The Go bindings are way nicer than the original C interface, Gtk was designed for. Gtk fundamentally has an object-oriented design. As it is based on pure C, it has its own thin object layer. However the "object oriented" features of Go blend much better with that design than the native C. Because you can build type hierarchies of structures and each structure type has methods. I very much regret that Go hasn't made bigger headway into the UI space, but it is a chicken and and egg problem. You need UI bindings to write UI applications. In general, there isn't enough development happening, especially for Linux. And alas, too many new developments get lured into writing electron apps. And there are of course a lot of QT apps.

But in my eyes, Go+Gtk should be a great combination for the desktop, as the bindings have a nice API and Go is really approachable for newcomers - it was one of the design criteria to not have too high learning efforts. If anything, there could be more documentation on how to use Gtk. And so far, my Go+Gtk programs can be easily recompiled and run on the Mac :)

> has failed to make headway into the UI space,

That's true (so far).

> and its language features make it very poor to work with for large code bases.

Not in my experience. We have quite a large codebase at work and we implement new features just fine. At least it looks better than in my previous C++ projects, where after a few years the code structure became a big rigid.

C++ is not really the benchmark to try to beat. There are superior languages for large code bases, but they're not "hip".

I agreed with you when you were talking about inheritance, but the claim that Go is not good for working with large code bases seems odd to me. Working with large codebases was one of Go's design goals. The idea is to split up programs into small packages with clear APIs, and these can be developed and maintained independently by hundreds of developers. I'd say it works quite well.

(I'm not claiming it's the best, just that it works well. Technically, I'd still prefer Ada's extreme modularity with explicit interface definitions.)

> Working with large codebases was one of Go's design goals.

Which they failed to meet. There is nothing special in golang that is designed for large codebases. The opposite in fact, things like how they designed interfaces is counter to large code bases. There are much better languages that do well in large code bases.

It only failed because no one was willing to spend the money it requires to make it happen.

See how much money might already been spent into Flutter development.

COM/UWP doesn't do class inheritance, only interfaces. It also provides delegation mechanisms.

Just like Win32 object model, is based on message dispatch across windows classes, not necessarly inheritance.

Just like game engines based on component architectures.

It's in theory only a problem with Go interfacing with GUI libraries that are inheritance based, line Gnome. But I agree in general, GUI dev is one domain when inheritance becomes extremely useful in some cases, from a lib consumer perspective.

Other immediate-mode GUIs, like Dear ImGui, don't use and wouldn't benefit from inheritance.