6 ms·

Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks

by knocte 9y ago

IshKebab 9y ago
If you don't use languages because they have some edge cases and minor flaws how do you do any programming at all?
- Gigablah 9y ago
  You don't need to do any programming in order to make snarky comments on HN.
- coldtea 9y ago
  Does that sound like an edge case?
  - laumars 9y ago
    Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.
    - masklinn 9y ago
      You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. This issue can occur for any function which takes an interface-typed parameter. That's usually how it happens: somebody passes in a `nil` which comes from a pointer-typed variable: https://play.golang.org/p/ADTvLDDrw6 https://play.golang.org/p/ADTvLDDrw6 > But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway. No, it would not. In Java, null is null whether it's typed as a concrete reference, as an array or as an interface.
      - laumars 9y ago
        > You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the language. So Let's break the code down: first they create a struct exposed via an interface{} type T struct{} func (t T) F() {} type P interface { F() } func newT() *T { return new(T) } Then they create an initialized variable that object type: t := newT() t2 := t ...and set that interface{} to nil: if !ENABLE_FEATURE { t2 = nil } Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed: thing := factory(t2) fmt.Println(thing.P == nil) // returns nil If there's a likelihood that they could be working with nil interfaces then they should be first checking the value of the interface before checking the value of the methods within it. Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. So I'm not defending Go's behavior but their example is peculiar to say the least. That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.
        coldtea 9y ago
        >Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. Most OO languages wont report an interface as non null if its value is null. Go will.
        laumars 9y ago
        Indeed - I wasn't defending Go's behavior here. I was just replying to your question about whether it is an edge case or not. Since the code would be broken in any OOP language I do consider this to be an edge case. But that doesn't mean I like nor would defend Go's nil type system.
    - coldtea 9y ago
      >Checking the value of a property after you've nil'ed the parent object is enough raise an exception in most languages. Only you're not doing that here. If anything, it's the inverse. >But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway. In other languages the interface can be null as a value even if the interface has a not-null type.
- knocte 9y ago
  Having the worst error-handling approach is not an edge case. Plus, the lack of generics is a huge design mistake IMO.
laumars 9y ago
I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if you take Apple's approach of breaking your language with each iteration (as they do with Swift) you still end up with lots of wasted developer time porting your code with each new release. Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids playing in drag-and-drop environments like Scratch.
- mrkgnao 9y ago
  Does this look like a design mistake or a bit of oversight? There is no excuse why one should have to do result, err := Foo() if err != nil { ... } over and over again in a language designed after 2000. The usual argument is that Go's simplistic design "reduces complexity", yet explaining something basic as why the error handling system doesn't behave the way one expects needs you to know how the compiler represents interface types. The next decade will see Go adding in most or all the complexity real-world software asks for, without ever admitting that maybe it should've been supported from the beginning without the hacky workarounds. > Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids[...] Even though the bit in italics is pretty much the opposite of the "Go/JS pitch", I'll bite. Sure, learning to code at a high level means you need to take time to learn things (which is the opposite of the pitch). I just don't get why teaching yourself to "navigate the [brokenness]" of a language that was out-of-date the day it was released is preferable to learning to write in an expressive language that won't artificially handicap you or provide you with an arsenal of footguns. In all the time you were casting to and from interface{}, you could be exploring and using powerful and practical new ideas that make it less likely you'll suffer for failing to check one of those "err"s.
  - laumars 9y ago
    > Does this look like a design mistake or a bit of oversight? Honestly, I don't mind error handling in Go. I've used a wide variety of languages in production systems (I've lost count but it's more than a dozen) and I've found Go to be surprisingly good at giving detailed, context aware breakdowns of where issues arise and allowing me to easily handle them. Sure there are a thousand different ways to do this and Go picked the ugliest, but in spite of that I've found it to be surprisingly effective - even in the more complex projects I've written like murex (my alternative UNIX $SHELL) and the odd Linux FUSE file system I've written to scratch a particular itch. In fact for as many complaints like yours I've read there are also as many seasoned developers complementing Go's error handling. So I really think that particular issue is more a matter of personal taste rather than poor language design. However I'm _not_ going to defend the nil thing nor how interface{}'s are (ab)used as an alternative to generics. Those _are_ just bad design choices. But for all of Go's sins, I still find myself more productive writing Go code than I have in any other language for a long time (probably since writing Pascal in Borland's Turbo Pascal back in the 90s). Hence why I defend Go. I can understand idealistic opinions about language design (Go is opinionated too after all) but frankly what really matters is a developers ability to get an idea into something executable. And I feel a lot of the complaints about Go really miss the point about how productive that language is to a great many people and without sacrificing too much control to be useful in a practical sense.
logicallee 9y ago
What is on your list now?

Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks

by knocte 9y ago

Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks

IshKebab 9y ago

If you don't use languages because they have some edge cases and minor flaws how do you do any programming at all?

Gigablah 9y ago
You don't need to do any programming in order to make snarky comments on HN.
coldtea 9y ago
Does that sound like an edge case?
- laumars 9y ago
  Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.
  - masklinn 9y ago
    You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. This issue can occur for any function which takes an interface-typed parameter. That's usually how it happens: somebody passes in a `nil` which comes from a pointer-typed variable: https://play.golang.org/p/ADTvLDDrw6 https://play.golang.org/p/ADTvLDDrw6 > But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway. No, it would not. In Java, null is null whether it's typed as a concrete reference, as an array or as an interface.
    - laumars 9y ago
      > You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the language. So Let's break the code down: first they create a struct exposed via an interface{} type T struct{} func (t T) F() {} type P interface { F() } func newT() *T { return new(T) } Then they create an initialized variable that object type: t := newT() t2 := t ...and set that interface{} to nil: if !ENABLE_FEATURE { t2 = nil } Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed: thing := factory(t2) fmt.Println(thing.P == nil) // returns nil If there's a likelihood that they could be working with nil interfaces then they should be first checking the value of the interface before checking the value of the methods within it. Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. So I'm not defending Go's behavior but their example is peculiar to say the least. That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.
      - coldtea 9y ago
        >Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. Most OO languages wont report an interface as non null if its value is null. Go will.
        laumars 9y ago
        Indeed - I wasn't defending Go's behavior here. I was just replying to your question about whether it is an edge case or not. Since the code would be broken in any OOP language I do consider this to be an edge case. But that doesn't mean I like nor would defend Go's nil type system.
  - coldtea 9y ago
    >Checking the value of a property after you've nil'ed the parent object is enough raise an exception in most languages. Only you're not doing that here. If anything, it's the inverse. >But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway. In other languages the interface can be null as a value even if the interface has a not-null type.
knocte 9y ago
Having the worst error-handling approach is not an edge case. Plus, the lack of generics is a huge design mistake IMO.

laumars 9y ago

I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if you take Apple's approach of breaking your language with each iteration (as they do with Swift) you still end up with lots of wasted developer time porting your code with each new release. Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids playing in drag-and-drop environments like Scratch.

mrkgnao 9y ago
Does this look like a design mistake or a bit of oversight? There is no excuse why one should have to do result, err := Foo() if err != nil { ... } over and over again in a language designed after 2000. The usual argument is that Go's simplistic design "reduces complexity", yet explaining something basic as why the error handling system doesn't behave the way one expects needs you to know how the compiler represents interface types. The next decade will see Go adding in most or all the complexity real-world software asks for, without ever admitting that maybe it should've been supported from the beginning without the hacky workarounds. > Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids[...] Even though the bit in italics is pretty much the opposite of the "Go/JS pitch", I'll bite. Sure, learning to code at a high level means you need to take time to learn things (which is the opposite of the pitch). I just don't get why teaching yourself to "navigate the [brokenness]" of a language that was out-of-date the day it was released is preferable to learning to write in an expressive language that won't artificially handicap you or provide you with an arsenal of footguns. In all the time you were casting to and from interface{}, you could be exploring and using powerful and practical new ideas that make it less likely you'll suffer for failing to check one of those "err"s.
- laumars 9y ago
  > Does this look like a design mistake or a bit of oversight? Honestly, I don't mind error handling in Go. I've used a wide variety of languages in production systems (I've lost count but it's more than a dozen) and I've found Go to be surprisingly good at giving detailed, context aware breakdowns of where issues arise and allowing me to easily handle them. Sure there are a thousand different ways to do this and Go picked the ugliest, but in spite of that I've found it to be surprisingly effective - even in the more complex projects I've written like murex (my alternative UNIX $SHELL) and the odd Linux FUSE file system I've written to scratch a particular itch. In fact for as many complaints like yours I've read there are also as many seasoned developers complementing Go's error handling. So I really think that particular issue is more a matter of personal taste rather than poor language design. However I'm _not_ going to defend the nil thing nor how interface{}'s are (ab)used as an alternative to generics. Those _are_ just bad design choices. But for all of Go's sins, I still find myself more productive writing Go code than I have in any other language for a long time (probably since writing Pascal in Borland's Turbo Pascal back in the 90s). Hence why I defend Go. I can understand idealistic opinions about language design (Go is opinionated too after all) but frankly what really matters is a developers ability to get an idea into something executable. And I feel a lot of the complaints about Go really miss the point about how productive that language is to a great many people and without sacrificing too much control to be useful in a practical sense.

logicallee 9y ago

What is on your list now?