8 ms·

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, whic

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

cookiengineer 4y ago
Generics are useless when there is no way to integrate them with your rest of the code. As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument. The things that I mentioned are from another point of view where language designers and implementers decided to implement the interactions with their data types in a different way, by providing overloadable methods with different function signatures for the same function name whereas in golang everything must be "namespaced" in a sub sub sub package. Good luck finding the right methodology where to sort in a method that can handle two different structs. If they're nested it's not even possible cause golang's dependency resolver doesn't allow cyclic dependencies. Parsing html5 in golang is a nightmare, and I've realized that this language is not made for such a use case.
- kgeist 4y ago
  >As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API You don't have to use reflection, there are typecasts: "value, ok := arg.(MyType)" You can also switch on a type. How is it different from instanceof in practice?
  - cookiengineer 4y ago
    The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type. If item instanceof HouseStruct {} Elseif item instanceof ContainerStruct {} With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.
    - kgeist 4y ago
      I'm not sure I follow what you mean. In Go the equivalent to your example is: switch val := item.(type) { case HouseStruct: case ContainerStruct: }
      - erik_seaberg 4y ago
        Doesn’t type switch require an interface value? Go tries not to add boxing-like overhead to generics.
        deleted 4y ago
        [deleted]
anonymoushn 4y ago
Go helps devs by creating extra work like checking for inner nil and outer nil, hitting the "if err != nil { return nil, err }" button on their keyboard, using reflection to instantiate unexported structs written by library authors who decided nobody should ever be able to make an interface-compatible wrapper that adds capabilities to their library, and relying on the language to enforce the checking of error return values, which it won't actually do if you don't assign any of the return values to variables.
- dgb23 4y ago
  Library authors not exporting their fundamental data structures is very painful, but this happens in many other languages too.
- throwaway894345 4y ago
  There is no “inner/outer nil”. People just need to understand how interfaces work (they’re a reference type and sometimes they reference another reference type, so just like any language with nullable pointers/references, either the pointer or the pointee can be nil). 101 level stuff. There are valid criticisms of Go (I’m not a fan of nil in the first place, for example), but this inner/outer nil myth needs to die.
  - anonymoushn 4y ago
    Sure, if any method anywhere takes a pointer receiver, then anyone can declare an interface that matches that method, and that interface is (among other things) like an Option<Option<T>> in Rust or a ??T in Zig. It's weird to post "There is no inner/outer nil" since the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true. For some reason, most languages do not encourage the users to create types that are similar to Option<Option<T>>. Have you actually taken this stuff to a group of first-semester CS students and had them understand it and think it was a good design? In the stdlib there's this function: // String returns the source text used to compile the regular expression. func (re *Regexp) String() string { return re.expr } which takes a pointer-to-struct receiver and does not check it for nil before using it. So any program that declares a Stringable interface, diligently checks Stringables to make sure they are non-nil, then calls String() only on the non-nil ones is allowed to panic on this line from the stdlib because re == nil. The wonderful tutorial[0] teaches beginning go programmers to write the same sort of bug in the first lesson about interfaces. [0]: https://go.dev/tour/methods/9 https://go.dev/tour/methods/9
laerus 4y ago
No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.
- Matl 4y ago
  - ratww 4y ago
    That was a generic argument, but still a valid one. Go is a language that indeed misses several features, including safety features, that help people perform their job better, and their excuses for that aren't exactly well thought. It is a systemic issue with the language, and criticising it ca feel like a cheap shot, but that's they way it is. It's nice that they're reverting their position on that (re: generics), but there's still a long way to go. Also: just because someone isn't forced to use it, doesn't mean it's immune to criticism, no matter how vague it is. And also, some people are forced to use it at their day job. Again, just because they can quit their job, doesn't mean the language is immune to criticism. I would suggest some introspection if criticism of something you like is causing you to dismiss their arguments and attack them, no matter how bad they are. There was no attack to you. I don't understand why this always happens in Go discussions. It's a language with a lot of potential, but people still stoop down to attacking others in order to defend it should be frozen in time.
    - morelisp 4y ago
      > Go is a language that indeed misses several features... that help people perform their job better... It is a systemic issue with the language The only language in which "misses several features" is not "systemic" is C++, and having every feature seems also to not really help anyone do their job better. I'm sure your language of choice is perfect, though.
      - 4y ago
iasay 4y ago
That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.
- kgeist 4y ago
  When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error conditions more carefully and made us more aware of potential edge cases, which didn't happen when we were writing in PHP because you only saw the happy path when looking at the code (i.e. little mention that something can go awry because exceptions are hidden from control flow). I remember in one such case, we found out you couldn't just bubble up an exception, you had to process it immediately, otherwise data could end up in an inconsistent state. However, repetition can introduce bugs, too, for example a very common mistake is to write this: if err != nil { return nil } instead of this: if err != nil { return err } which is pretty serious because you essentially ignore the error. This particular pattern is so common your brain often ends up completely skipping it and it's pretty hard to detect during code review.
  - tored 4y ago
    Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code 1) not properly checking return values from standard library functions 2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc 3) different handling of old style errors vs exceptions This is an unfortunate legacy of PHP, it is messy and error prone. I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too. I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed. What I'm trying to say is that we need stricter compilers. My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

cookiengineer 4y ago

Generics are useless when there is no way to integrate them with your rest of the code. As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument. The things that I mentioned are from another point of view where language designers and implementers decided to implement the interactions with their data types in a different way, by providing overloadable methods with different function signatures for the same function name whereas in golang everything must be "namespaced" in a sub sub sub package. Good luck finding the right methodology where to sort in a method that can handle two different structs. If they're nested it's not even possible cause golang's dependency resolver doesn't allow cyclic dependencies. Parsing html5 in golang is a nightmare, and I've realized that this language is not made for such a use case.

kgeist 4y ago
>As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API You don't have to use reflection, there are typecasts: "value, ok := arg.(MyType)" You can also switch on a type. How is it different from instanceof in practice?
- cookiengineer 4y ago
  The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type. If item instanceof HouseStruct {} Elseif item instanceof ContainerStruct {} With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.
  - kgeist 4y ago
    I'm not sure I follow what you mean. In Go the equivalent to your example is: switch val := item.(type) { case HouseStruct: case ContainerStruct: }
    - erik_seaberg 4y ago
      Doesn’t type switch require an interface value? Go tries not to add boxing-like overhead to generics.
      - deleted 4y ago
        [deleted]

anonymoushn 4y ago

Go helps devs by creating extra work like checking for inner nil and outer nil, hitting the "if err != nil { return nil, err }" button on their keyboard, using reflection to instantiate unexported structs written by library authors who decided nobody should ever be able to make an interface-compatible wrapper that adds capabilities to their library, and relying on the language to enforce the checking of error return values, which it won't actually do if you don't assign any of the return values to variables.

dgb23 4y ago
Library authors not exporting their fundamental data structures is very painful, but this happens in many other languages too.
throwaway894345 4y ago
There is no “inner/outer nil”. People just need to understand how interfaces work (they’re a reference type and sometimes they reference another reference type, so just like any language with nullable pointers/references, either the pointer or the pointee can be nil). 101 level stuff. There are valid criticisms of Go (I’m not a fan of nil in the first place, for example), but this inner/outer nil myth needs to die.
- anonymoushn 4y ago
  Sure, if any method anywhere takes a pointer receiver, then anyone can declare an interface that matches that method, and that interface is (among other things) like an Option<Option<T>> in Rust or a ??T in Zig. It's weird to post "There is no inner/outer nil" since the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true. For some reason, most languages do not encourage the users to create types that are similar to Option<Option<T>>. Have you actually taken this stuff to a group of first-semester CS students and had them understand it and think it was a good design? In the stdlib there's this function: // String returns the source text used to compile the regular expression. func (re *Regexp) String() string { return re.expr } which takes a pointer-to-struct receiver and does not check it for nil before using it. So any program that declares a Stringable interface, diligently checks Stringables to make sure they are non-nil, then calls String() only on the non-nil ones is allowed to panic on this line from the stdlib because re == nil. The wonderful tutorial[0] teaches beginning go programmers to write the same sort of bug in the first lesson about interfaces. [0]: https://go.dev/tour/methods/9 https://go.dev/tour/methods/9

laerus 4y ago

No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.

Matl 4y ago
- ratww 4y ago
  That was a generic argument, but still a valid one. Go is a language that indeed misses several features, including safety features, that help people perform their job better, and their excuses for that aren't exactly well thought. It is a systemic issue with the language, and criticising it ca feel like a cheap shot, but that's they way it is. It's nice that they're reverting their position on that (re: generics), but there's still a long way to go. Also: just because someone isn't forced to use it, doesn't mean it's immune to criticism, no matter how vague it is. And also, some people are forced to use it at their day job. Again, just because they can quit their job, doesn't mean the language is immune to criticism. I would suggest some introspection if criticism of something you like is causing you to dismiss their arguments and attack them, no matter how bad they are. There was no attack to you. I don't understand why this always happens in Go discussions. It's a language with a lot of potential, but people still stoop down to attacking others in order to defend it should be frozen in time.
  - morelisp 4y ago
    > Go is a language that indeed misses several features... that help people perform their job better... It is a systemic issue with the language The only language in which "misses several features" is not "systemic" is C++, and having every feature seems also to not really help anyone do their job better. I'm sure your language of choice is perfect, though.
    - 4y ago

iasay 4y ago

That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.

kgeist 4y ago
When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error conditions more carefully and made us more aware of potential edge cases, which didn't happen when we were writing in PHP because you only saw the happy path when looking at the code (i.e. little mention that something can go awry because exceptions are hidden from control flow). I remember in one such case, we found out you couldn't just bubble up an exception, you had to process it immediately, otherwise data could end up in an inconsistent state. However, repetition can introduce bugs, too, for example a very common mistake is to write this: if err != nil { return nil } instead of this: if err != nil { return err } which is pretty serious because you essentially ignore the error. This particular pattern is so common your brain often ends up completely skipping it and it's pretty hard to detect during code review.
- tored 4y ago
  Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code 1) not properly checking return values from standard library functions 2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc 3) different handling of old style errors vs exceptions This is an unfortunate legacy of PHP, it is messy and error prone. I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too. I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed. What I'm trying to say is that we need stricter compilers. My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.