9 ms·

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It'

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is also pretty annoying. Let alone the "hack" with annotations for decoding/encoding everywhere, just so that you can use reflect API in the encoder implementations. For loop fatigue in golang makes it so unreadable in practice, and leads everybody to offloading manipulation of arrays/slices to helper methods, just to have the for loop there. The library that fixes this as good as possible with generics is the "lo" library (inspired by lodash) [1]. It's worth taking a look at it if you're curious how to implement it for your structs. [1] https://github.com/samber/lo https://github.com/samber/lo

hsn915 4y ago
What is for loop fatigue? Seems like a fake problem that one would only feel if they buy too much into functional programming. Some ideas in fuctional programming are useful, but overall, for loops are much more preferable to map/filter/reduce. For loops are much more easily amenable to incremental changes. "reduce" is particularly bad. It obfuscates control flow for no benefit at all.
- RhodesianHunter 4y ago
  >but overall, for loops are much more preferable to map/filter/reduce I strongly disagree on this one. A .map or a .filter are clear and concise while filtering or mapping, particularly in a streaming situation where you're only iterating the collection once. You can trivially write code using this paradigm that's easily readable, performant, and takes up a handful of lines that would take dozens in Go.
throwaway894345 4y ago
There’s a whole lot wrong about this comment, but the most obvious is the claim that Go lacks a new keyword. Firstly, Go has a new keyword and secondly who makes a big deal about whether or not a language has a new keyword?
- deleted 4y ago
  [deleted]
- tbarbugli 4y ago
  in Go ‘new’ is a function, not a keyword I think that parent probably refers to the lack of something like this: x := new MyType
  - kevin_thibedeau 4y ago
    This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.
    - petmon 4y ago
      How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.
      - morelisp 4y ago
        Your understanding is correct. That's also what you will effectively get with C or C++ on Linux anywhere you would have had a choice between C++ and Go to behind with.
        ericpruitt 4y ago
        Since when do heap allocation failures on Linux result in an abort? In C, malloc(3) will return NULL on failure and set errno accordingly. Sure, if overcommit is enabled, you might get a fault if you try to access memory that was allegedly allocated, but there is no strict "malloc failure === fatal error" relationship.
        morelisp 4y ago
philosopher1234 4y ago
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.
PhilippGille 4y ago
> but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. Generics landed in the latest stable version, 4 months ago. Before doing too many too early additions in the stdlib they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub). In these cases (another case was error wrapping prior Go 1.13) they start with experimental libraries in `golang.org/x/exp/...`, which they did here as well: https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps So while the stdlib doesn't have the functions you're looking for yet, this might change over time.
- kgeist 4y ago
  >they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub). The rationale can be found here: https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918

hsn915 4y ago

What is for loop fatigue? Seems like a fake problem that one would only feel if they buy too much into functional programming. Some ideas in fuctional programming are useful, but overall, for loops are much more preferable to map/filter/reduce. For loops are much more easily amenable to incremental changes. "reduce" is particularly bad. It obfuscates control flow for no benefit at all.

RhodesianHunter 4y ago
>but overall, for loops are much more preferable to map/filter/reduce I strongly disagree on this one. A .map or a .filter are clear and concise while filtering or mapping, particularly in a streaming situation where you're only iterating the collection once. You can trivially write code using this paradigm that's easily readable, performant, and takes up a handful of lines that would take dozens in Go.

throwaway894345 4y ago

There’s a whole lot wrong about this comment, but the most obvious is the claim that Go lacks a new keyword. Firstly, Go has a new keyword and secondly who makes a big deal about whether or not a language has a new keyword?

deleted 4y ago
[deleted]
tbarbugli 4y ago
in Go ‘new’ is a function, not a keyword I think that parent probably refers to the lack of something like this: x := new MyType
- kevin_thibedeau 4y ago
  This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.
  - petmon 4y ago
    How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.
    - morelisp 4y ago
      Your understanding is correct. That's also what you will effectively get with C or C++ on Linux anywhere you would have had a choice between C++ and Go to behind with.
      - ericpruitt 4y ago
        Since when do heap allocation failures on Linux result in an abort? In C, malloc(3) will return NULL on failure and set errno accordingly. Sure, if overcommit is enabled, you might get a fault if you try to access memory that was allegedly allocated, but there is no strict "malloc failure === fatal error" relationship.
        morelisp 4y ago

philosopher1234 4y ago

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.

PhilippGille 4y ago

> but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. Generics landed in the latest stable version, 4 months ago. Before doing too many too early additions in the stdlib they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub). In these cases (another case was error wrapping prior Go 1.13) they start with experimental libraries in `golang.org/x/exp/...`, which they did here as well: https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps So while the stdlib doesn't have the functions you're looking for yet, this might change over time.

kgeist 4y ago
>they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub). The rationale can be found here: https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918