4 ms·

Well... there's also other side of the coin. There's value in visibility and lack of magic. > lack of decent error handling (if err !=nil { return nil,err} )

Well... there's also other side of the coin. There's value in visibility and lack of magic. > lack of decent error handling (if err !=nil { return nil,err} ) Errors are in 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. > or lack of decent polymorphism... 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. Go encourages composition instead of inheritance. That's something I wish more C++ codebases would do as well. Composition makes code inherently more maintainable and easier to refactor. Go tends to be easy to read and maintain. It does come with some cost. It's just a matter where your priorities lie. Software projects spend majority of their life as legacy, something that needs to be maintained.

allovernow 7y ago
>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?
- vardump 7y ago
  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.
- arwhatever 7y ago
  I don't see that composition should be cause for repeated code blocks.
- loopz 7y ago
  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.
- sseth 7y ago
  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.
mrbrowning 7y ago
> 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.
- loopz 7y ago
  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.
shrimpx 7y ago
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.
- loopz 7y ago
  Performance and making logic explicit.
whateveracct 7y ago
> 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.

allovernow 7y ago

>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?

vardump 7y ago
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.
arwhatever 7y ago
I don't see that composition should be cause for repeated code blocks.
loopz 7y ago
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.
sseth 7y ago
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.

mrbrowning 7y ago

> 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.

loopz 7y ago
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.

shrimpx 7y ago

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.

loopz 7y ago
Performance and making logic explicit.

whateveracct 7y ago

> 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.