> Errors are on your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust.

Errors as values is a great idea. Errors as values without sum types or pattern matching, though, gives you twice the tedium and a tenth of the benefit, so once again Golang's slavish adherence to "worse is better" really just makes things...worse. The real problem here, though, is that those invisible gotos still exist: because of how limited Go's type system is, it's very easy to cause a panic with e.g. a nil pointer. Of course, the answer is to rigorously check the cases where a pointer could be nillable, but that trivially contradicts the idea that, when reading Go code, you can feel confident reasoning locally about its resilience if it handles all potential error values appropriately. IMO, this false sense of safety is even worse than just making exceptions first class citizens of the language, and it belies the notion that Go is especially maintainable.

Accessing nil would be a programming error, not normal errorhandling and code logic should inherently avoid the scenario, not hide or do coverup silently. If it breaks, let the process die.

The cost of simpler tools is you need to target better, simpler designs and refactor. This requires more from programmers but produces better code.

>Composition makes code inherently more maintainable and easier to refactor.

My understanding of composition comes from interfaces in C#. In my experience composition is actually more difficult to code and refactor, because it leads to bloat from repeated code as you cannot simply inherit. Refactoring then can become tedious as you may need to manually edit every repeated code block. Whereas with inheritance I define a function once and override it where necessary.

Am I misunderstanding something?

Composition tends to lead to more code reuse. And to more code that's still usable in unpredictable future.

Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid.

Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.

In go, composition has a special feature where if you include another type anonymously in a struct, the methods of that type are automatically available for the struct as well. It is also possible to "override" these methods at the struct level and call the anonymous member directly.

So you can get some of the conveniences of inheritance. The behaviour is of course different, because the composed member has no way of knowing the identity of the including struct.

Composition should lead to clean components for reuse. You might need some extra references, but it is more explicit, static and flexible. Inheritance sounds great in theory, but is a hierarchical blind-alley, though usable for static designs that never change much.

I don't see that composition should be cause for repeated code blocks.

> Lack of polymorphism also means you don't have to guess about concrete types when reading code. When troubleshooting, you can see what's going on without going through whole inheritance tree.

Parametric polymorphism would mean you never have to even consider the type of the code. It's a freeing abstraction with plenty of very simple reference implementations. And it lends itself to composition over inheritance.

And sadly I doubt Go will ever manage to get it.

Try/catch vs explicitly checking error values is like implementing sandboxing with os-level isolation versus with programming discipline. Why one would prefer offering guarantees like "will never crash/panic" using the latter technique instead of a guaranteed catch-all is incomprehensible to me.

Performance and making logic explicit.