GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.
I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.
Go is explicitly not functional. Many builtin functions mutate (look at Sort for an example). There's no map.
https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...
Functions are only almost first-class. For example... http://play.golang.org/p/WB133vrGKD
Go does have powerful constructs, but to call it "functional" is maligned.
I would also argue that it's not always easy to reason about and follow. The reason we build abstractions, which Java allows perfectly, is so that we can ignore the hidden complexity and reason about code more easily.
Go explicitly makes it difficult to hide underlying complexity. If I want to make, for example, a Bimap (which Java has many clean implementations of) I get to pick from two poisons in Go: Either I must force everyone who uses it to type-cast on every get (implement the bimap via taking and returning interface{}), or I must surface the implementation details (two maps) and have users directly manipulate those since the builtin uni-directional map is a type-safe generic data-structure which I can't replicate in the language itself. This might look appealing at first, but since I also need to do some Locking my interface for allowing people to manipulate those maps directly rapidly becomes troublesome.
Neither of those choices sound appealing to me.
Honestly, if you want to avoid java now you have a plethora of options. You can develop for android with Scala and get basically first-class support.
You can develop for android via webview+html+js and use something like http://ocsigen.org/js_of_ocaml/ to write OCaml and have a wonderful actually functional language.
You can wait for Rust to have some android bindings implemented and use a wonderful language that allows powerful features like macros that are excellent for interface-building.
I don't mean to bash on Go since it does have a place somewhere, I just feel that it is not the correct language for something UI heavy nor anywhere that suitably complex abstractions and complexity-hiding are a necessity.
A similar situation has occured in ios development where the functional aspects of Swift do not complement the existing design of the coca framework.
We can save 100 lines of code there by coupling 2 slightly related things forever (and arbitrarily choosing this criteria for division as the most important).
I've made game before I knew OO programming. I haven't knew it then, but I used Interpreter Pattern - there was data model, with a list of records, each record had some enums deciding how game logic should handle it. There was main loop updating the model using these enums to choose logic to run on this record.
It wasn't pretty but it worked, I was able to modify it however I wanted, to choose logic to run on some record basing on enums, other atributes of given record, attributes of parent records, or of colliding records, on whatever I wanted basicaly.
Then I rewrote the game to use OO design (I was enthusiastic- this is exactly what I need - I thought). It turns out that I had to choose arbitrary divisions. I can divide game objects into Solid and non-solid, Static and Movable, Visible and Invisible, and also Smart vs Dumb Objects. Which division should be first in class hierarchy? All the rest would need to be duplicated anyway. SmartMovableVisible, SmartMovableInvisible, SmartStaticVisible, etc... Ugly.
Inheritance solves part of the problem and leaves you with inconsistent solution.
The real solution is strategy pattern, and composition over inheritance. It can be done just as well in languages without inheritance (but with lambdas).
I wrote the OO game in C++, but I avoided multiple inheritance, because there were warnings everywhere: "don't use multiple inheritance". And I don't think it would be much help in the end.
Another thing inheritance doesn't solve - when you want to choose which logic should run on your "object" depending on dynamic conditions.
For example I had ParticleEffect abstract class, Smoke and Fire derived from it. Fire reacted differently to collisions with stuff, than smoke. Fire partices were smaller with each frame to simulate flames, smoke was getting bigger and more transparent with each frame to simulate, well, smoke.
Then I wanted to make fire that turns into smoke after a couple of frames.
Solution 1 - merge both classes, make enum field inside, switch it after a couple of frames [not OO design - behaviour depends on fields not on classes]
Solution 2 - destroy fire object after a couple of frames and create new smoke object in its place [unnessesary allocation and deallocation is bad in games, also this complicates identity - for fire and smoke it doesn't matter, but for player and bullets it's important - I need to ensure player isn't hit by bullets he shoot, that's achieved by keeping "parent" pointer in each object, when the player is recreated because he got new behaviour - all the pointers are wrong and need to be updated].
I can't change class of object dynamicaly, so all the OO divisions are static in time, I have to workaround class hierarchy to model my problem correctly.
Another thing - in collision detection, the logic to run should depend on both colliding objects types, and some of their fields. With OO I have to workaround this again (because most OO languages are single-dispatch).
Another thing - OO data is much harder to serialize. Structural data allows banal serialization. This is solved in some languages (like Python or Java) by providing serialization in the core language, but in C++ or javascript serializing arbitrary object graph correctly is nontrivial. Serializing list of records was trivial even in Turbo Pascal ;)
"Give me an object like Foo, but with this one little thing changed."
Compression is a little dangerous because it requires the programmer to understand a fair amount about the context from which compressed code will take its meaning. Not only does this require available source code or excellent documentation, but the nature of inherited language also forces the programmer to understand the source or documentation. If a programmer needs a lot of context to understand a program he needs to extend, he may make mistake because of misunderstandings.
(from Patterns in Software, which is a really deep if long-winded book)
The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
Instead of
foo.WriteToFile("/tmp/foo")
You might write:
file.Write(foo.Representation()).
I promise that most inheritance in the real world is attempting to reuse something like "WriteToFile". "I wouldn't want to copy-paste the file-writing code, so I'll inherit from something that can write itself to the file." No. Don't do that.
Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods.
All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.
It's not struct inheritance[1], so I wasn't sure what you were talking about.
That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9
I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it.
In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.