7 ms·

you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write. ...which makes it also very easy

you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write. ...which makes it also very easy to read.

Thaxll 6y ago
Then you write 2 functions, what you're talking about is a different question.
- adkadskhj 6y ago
  Maybe. If you have to remember two functions to _understand_ the code, is reading really easier? I imagine reading implies understanding, and while i definitely think Go is easier to read without understanding, i don't think that's the real implication.
- egeozcan 6y ago
  if having to write a separate function for each type of container is easy for you, then I can only respectfully disagree :) I'm saying this as someone who is learning go for fun.
hnlmorg 6y ago
I don't see the point of cherry picking highly specific examples because for every argument there will be just as many counterarguments from other domains. To be more specific: the point isn't whether Go is "always" simpler to write but whether it is generally simpler to write. I think the latter is true for all the domains I've written code in Go and I've solved some pretty hard problems in Go (check out my Github repositories if you don't believe me). The awesome thing about programming languages is that you're free to pick another language if that is a better fit for any specific domain or even personal preference. Hence why I've worked in more than a dozen different programming languages over the years. So rather than moaning that Go doesn't fit a particular pattern where you need to rely on generics, perhaps use a language that has generics to solve that problem and save Go for the occasions you don't need generics (which, if we're all honest, isn't something we need to rely on half as much as people claim when moaning about the lack of features in Go). As a veteran developer, what really annoys me the most is people who pick a language that isn't well suited for solving the problem at hand and then moan that language needs to change, rather than developers picking the right tools for the job. I'd rather see a language lack features but focuses to serves its core demographic well than see everything and the kitchen sink is thrown at it and everyone using it even when they know they shouldn't simply because they're too afraid to learn anything new. What we need is more appreciation that "general purpose languages" doesn't mean "should be used to do practically anything in". Then I'd think we'd all get along better.
- egeozcan 6y ago
  I meant it as a random example. I do not dislike go. As I've stated below, I actually am learning it (more like, the conventions around it), just for fun. I find it especially powerful for writing tools. That doesn't remove my rights to nitpick its shortcomings though.
unchar1 6y ago
I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.
- nicoburns 6y ago
  But all that boilerplate also makes it hard to read. You have to pick out the meaning amongst a bunch of noise.
  - marcus_holmes 6y ago
    Not once you're used to it. Humans are good at spotting patterns, and once you're used to the patterns of the boilerplate it becomes easy to read and you only notice the anomalies. The famous "if err != nil {" boilerplate becomes expected after each call and you only notice if it changes.
throwaway894345 6y ago
I would argue that it only makes it hard to write type safe generic functions that return modified slices. If you're writing generic code for the sake of writing generic code, Go is probably going to give you a bad time, but if you're trying to solve real problems, you can get a very long way with slices, maps, and interfaces/functions.
- erik_seaberg 6y ago
  filter/map/reduce are more productive than anything I could write without them.
  - fwip 6y ago
    Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny
  - throwaway894345 6y ago
    I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.
    - erik_seaberg 6y ago
      filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
      - throwaway894345 6y ago
        Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.
q3k 6y ago
I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages. I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5. In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).
- rob74 6y ago
  > there's always going to be more things PL people lust after How about non-nullable types?
  - q3k 6y ago
    Sure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.
- morelisp 6y ago
  As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.

you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write. ...which makes it also very easy to read.

Thaxll 6y ago

Then you write 2 functions, what you're talking about is a different question.

adkadskhj 6y ago
Maybe. If you have to remember two functions to _understand_ the code, is reading really easier? I imagine reading implies understanding, and while i definitely think Go is easier to read without understanding, i don't think that's the real implication.
egeozcan 6y ago
if having to write a separate function for each type of container is easy for you, then I can only respectfully disagree :) I'm saying this as someone who is learning go for fun.

hnlmorg 6y ago

I don't see the point of cherry picking highly specific examples because for every argument there will be just as many counterarguments from other domains. To be more specific: the point isn't whether Go is "always" simpler to write but whether it is generally simpler to write. I think the latter is true for all the domains I've written code in Go and I've solved some pretty hard problems in Go (check out my Github repositories if you don't believe me). The awesome thing about programming languages is that you're free to pick another language if that is a better fit for any specific domain or even personal preference. Hence why I've worked in more than a dozen different programming languages over the years. So rather than moaning that Go doesn't fit a particular pattern where you need to rely on generics, perhaps use a language that has generics to solve that problem and save Go for the occasions you don't need generics (which, if we're all honest, isn't something we need to rely on half as much as people claim when moaning about the lack of features in Go). As a veteran developer, what really annoys me the most is people who pick a language that isn't well suited for solving the problem at hand and then moan that language needs to change, rather than developers picking the right tools for the job. I'd rather see a language lack features but focuses to serves its core demographic well than see everything and the kitchen sink is thrown at it and everyone using it even when they know they shouldn't simply because they're too afraid to learn anything new. What we need is more appreciation that "general purpose languages" doesn't mean "should be used to do practically anything in". Then I'd think we'd all get along better.

egeozcan 6y ago
I meant it as a random example. I do not dislike go. As I've stated below, I actually am learning it (more like, the conventions around it), just for fun. I find it especially powerful for writing tools. That doesn't remove my rights to nitpick its shortcomings though.

unchar1 6y ago

I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.

nicoburns 6y ago
But all that boilerplate also makes it hard to read. You have to pick out the meaning amongst a bunch of noise.
- marcus_holmes 6y ago
  Not once you're used to it. Humans are good at spotting patterns, and once you're used to the patterns of the boilerplate it becomes easy to read and you only notice the anomalies. The famous "if err != nil {" boilerplate becomes expected after each call and you only notice if it changes.

throwaway894345 6y ago

I would argue that it only makes it hard to write type safe generic functions that return modified slices. If you're writing generic code for the sake of writing generic code, Go is probably going to give you a bad time, but if you're trying to solve real problems, you can get a very long way with slices, maps, and interfaces/functions.

erik_seaberg 6y ago
filter/map/reduce are more productive than anything I could write without them.
- fwip 6y ago
  Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny
- throwaway894345 6y ago
  I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.
  - erik_seaberg 6y ago
    filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
    - throwaway894345 6y ago
      Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.

q3k 6y ago

I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages. I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5. In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).

rob74 6y ago
> there's always going to be more things PL people lust after How about non-nullable types?
- q3k 6y ago
  Sure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.
morelisp 6y ago
As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.