4 ms·

WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta.

WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta. This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language. I've been using the https://github.com/samber/lo https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs. I would really enjoy a chaining library, and some tooling to make type coersion a bit cleaner.

aston 5y ago
You might like Go-Chainable: https://github.com/neurocollective/go_chainable https://github.com/neurocollective/go_chainable
earthboundkid 5y ago
I find that the function boilerplate of Go is too long because there's no equivalent of an arrow func. I can't see those kind of libraries taking off until there's an easier way to write a closure.
edenlinger 5y ago
I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go. I should probably shut up and just be happy lots of other people are using a language I enjoy :)
- kortex 5y ago
  > I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring. What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame. But I am a fan of abstraction so I'm not the best judge.
  - morelisp 5y ago
    Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.
    - kortex 5y ago
      Great point. Although, that sounds like a typical example of "let's write it the ergonomic but less performant way first, then profile and refactor as needed". That seems very tractable for that sort of refactor, especially with type safety. Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.
      - lifty 5y ago
        And now we introduced 2 new problems: 1. We have 2 ways of doing stuff (boring loop vs map) 2. We have a new hidden way to introduce performance degradation by importing a library that uses map You might argue that you should know what you're importing, but in practice, it can hurt the overall ecosystem. I'm still supporting the introduction of generics, but the tradeoff should be clear to everyone.
- honkycat 5y ago
  > If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide. I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't be condescending to me and assume I just "don't get it" or that I am too lazy to learn the "go" way of doing things. I am seeing that a lot in this comment section. You are judging others and coming to conclusions because we like something you do not like. I can totally understand your perspective, because I also see the danger of introducing more "power" into a language that was elegant and simple. I respect your disagreement with introducing generics to Golang. However, please extend us the courtesy of assuming we are at least remotely competent.
  - edenlinger 5y ago
    Man, I totally missed the mark if this is how you interpretted my comment. I never meant to imply any competence level. Certainly didn't meant to direct any judgment at you. Simply trying express the issue I had with the lo package. I'm really happy we have gotten generics. I think some of our lower level tooling will be much easier to build. I know lots of the community will likely be happy to have non reflect based ORMs come out of that work. I have a coworker who has expressed interest in building a new json:api parsing library with generics. Happy we have it. The map/reduce/filter and some of the other _ style helper functions from lo was what I was trying to speak to. Those idioms just don't seem to fit well in the language. The clarity of the single way to do something in Go has been immensely refreshing. I appreciate that so often Go code looks like Go code. I also don't find myself pondering which iterator to use or chain together to accomplish something. I just quickly go to a for loop and move on. In Ruby/Java/JS/Python I often find myself deciding which chainable to use instead of just solving the problem and moving on. The language is certainly not without its warts or shortcomings. To me it feels like if those kinds of options are things you really enjoy using in a language, it would feel more natural to use a different tool. Sacrificing that clarity seems to remove some of the biggest reasons to use the language as opposed to something with fewer limitations. Sorry if I came across as condescending. Not a stereotype of the community I intended on perpetuating.
- int_19h 5y ago
  It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc. 18 years later, the C# and Java developers are doing fine.
  - pjmlp 5y ago
    It's worth remembering that C# did have them pre-release, Microsoft decided to release .NET 1.0 without them to avoid postponing the release date until they were fully done. This is clearly described in the HOPL papers regarding generics in .NET.
chakkepolja 5y ago
generic is really useful, but map-filter-reduce doesnt work well in go, youre just retrofitting it from your favorite language. The place for generics in Go is data structure libraries, ORMs etc..
morelisp 5y ago
So, I don't want to tear too much into someone's side project, but a lot of this is exactly what people are worried about. As an example, let's take the `Chunk` function, since that's something I know I have three implementations that differ only in type in one project, pre-generics: result := make([][]T, 0, len(collection)/2+1) length := len(collection) len(collection)/2? If you're splitting a list of size M into N chunks, you know exactly how many chunks you need a priori, and it's not M/2+1. for i := 0; i < length; i++ { chunk := i / size if i%size == 0 { result = append(result, make([]T, 0, size)) } But worse: You allocated a whole new slice to store the chunk! What a waste. But, you know, the real frustrating thing in the end is that it allocated anything at all. Chunking can also happen iteratively on the source slice: func [T any]([]T, int) (chunk []T, remaining []T) And then it will be zero-alloc. But, once you see this, you see we could write something that works on indices: func (len int, size int) (split int) And get nearly the same effect, without any generics. Go < 1.18 forces you to factor down to the last one if you're pursing highly abstract code (or you write it inline if you're not, and it's as fast). It's not pretty, and you need one more line of boilerplate to slice the slice, but it is fast. Go 1.18 has a nicer option that gets rid of the line of boilerplate, but it's no longer the easiest solution to reach for. (See also my comments at https://news.ycombinator.com/item?id=29905908#29926708 https://news.ycombinator.com/item?id=29905908#29926708 - just because you have a generic type doesn't mean you should use it as much as possible, even if you do need to use it once.) I'm happy to see generics in golang. It will simplify a ton of my higher-level code like REST endpoints, and be a minor boon to low-level code. But this library, as useful as some parts may be, is also a great example of why they're a dangerous tool.
- morelisp 5y ago
  Actually, I take that back, I will shit on a side project. `lop.PartitionBy` strongly suggests they're just copy/pasting whatever implementation they can to show off generics, without making sure it makes sense at all.

aston 5y ago

You might like Go-Chainable: https://github.com/neurocollective/go_chainable https://github.com/neurocollective/go_chainable

earthboundkid 5y ago

I find that the function boilerplate of Go is too long because there's no equivalent of an arrow func. I can't see those kind of libraries taking off until there's an easier way to write a closure.

edenlinger 5y ago

I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go. I should probably shut up and just be happy lots of other people are using a language I enjoy :)

kortex 5y ago
> I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring. What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame. But I am a fan of abstraction so I'm not the best judge.
- morelisp 5y ago
  Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.
  - kortex 5y ago
    Great point. Although, that sounds like a typical example of "let's write it the ergonomic but less performant way first, then profile and refactor as needed". That seems very tractable for that sort of refactor, especially with type safety. Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.
    - lifty 5y ago
      And now we introduced 2 new problems: 1. We have 2 ways of doing stuff (boring loop vs map) 2. We have a new hidden way to introduce performance degradation by importing a library that uses map You might argue that you should know what you're importing, but in practice, it can hurt the overall ecosystem. I'm still supporting the introduction of generics, but the tradeoff should be clear to everyone.
honkycat 5y ago
> If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide. I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't be condescending to me and assume I just "don't get it" or that I am too lazy to learn the "go" way of doing things. I am seeing that a lot in this comment section. You are judging others and coming to conclusions because we like something you do not like. I can totally understand your perspective, because I also see the danger of introducing more "power" into a language that was elegant and simple. I respect your disagreement with introducing generics to Golang. However, please extend us the courtesy of assuming we are at least remotely competent.
- edenlinger 5y ago
  Man, I totally missed the mark if this is how you interpretted my comment. I never meant to imply any competence level. Certainly didn't meant to direct any judgment at you. Simply trying express the issue I had with the lo package. I'm really happy we have gotten generics. I think some of our lower level tooling will be much easier to build. I know lots of the community will likely be happy to have non reflect based ORMs come out of that work. I have a coworker who has expressed interest in building a new json:api parsing library with generics. Happy we have it. The map/reduce/filter and some of the other _ style helper functions from lo was what I was trying to speak to. Those idioms just don't seem to fit well in the language. The clarity of the single way to do something in Go has been immensely refreshing. I appreciate that so often Go code looks like Go code. I also don't find myself pondering which iterator to use or chain together to accomplish something. I just quickly go to a for loop and move on. In Ruby/Java/JS/Python I often find myself deciding which chainable to use instead of just solving the problem and moving on. The language is certainly not without its warts or shortcomings. To me it feels like if those kinds of options are things you really enjoy using in a language, it would feel more natural to use a different tool. Sacrificing that clarity seems to remove some of the biggest reasons to use the language as opposed to something with fewer limitations. Sorry if I came across as condescending. Not a stereotype of the community I intended on perpetuating.
int_19h 5y ago
It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc. 18 years later, the C# and Java developers are doing fine.
- pjmlp 5y ago
  It's worth remembering that C# did have them pre-release, Microsoft decided to release .NET 1.0 without them to avoid postponing the release date until they were fully done. This is clearly described in the HOPL papers regarding generics in .NET.

chakkepolja 5y ago

generic is really useful, but map-filter-reduce doesnt work well in go, youre just retrofitting it from your favorite language. The place for generics in Go is data structure libraries, ORMs etc..

morelisp 5y ago

So, I don't want to tear too much into someone's side project, but a lot of this is exactly what people are worried about. As an example, let's take the `Chunk` function, since that's something I know I have three implementations that differ only in type in one project, pre-generics: result := make([][]T, 0, len(collection)/2+1) length := len(collection) len(collection)/2? If you're splitting a list of size M into N chunks, you know exactly how many chunks you need a priori, and it's not M/2+1. for i := 0; i < length; i++ { chunk := i / size if i%size == 0 { result = append(result, make([]T, 0, size)) } But worse: You allocated a whole new slice to store the chunk! What a waste. But, you know, the real frustrating thing in the end is that it allocated anything at all. Chunking can also happen iteratively on the source slice: func [T any]([]T, int) (chunk []T, remaining []T) And then it will be zero-alloc. But, once you see this, you see we could write something that works on indices: func (len int, size int) (split int) And get nearly the same effect, without any generics. Go < 1.18 forces you to factor down to the last one if you're pursing highly abstract code (or you write it inline if you're not, and it's as fast). It's not pretty, and you need one more line of boilerplate to slice the slice, but it is fast. Go 1.18 has a nicer option that gets rid of the line of boilerplate, but it's no longer the easiest solution to reach for. (See also my comments at https://news.ycombinator.com/item?id=29905908#29926708 https://news.ycombinator.com/item?id=29905908#29926708 - just because you have a generic type doesn't mean you should use it as much as possible, even if you do need to use it once.) I'm happy to see generics in golang. It will simplify a ton of my higher-level code like REST endpoints, and be a minor boon to low-level code. But this library, as useful as some parts may be, is also a great example of why they're a dangerous tool.

morelisp 5y ago
Actually, I take that back, I will shit on a side project. `lop.PartitionBy` strongly suggests they're just copy/pasting whatever implementation they can to show off generics, without making sure it makes sense at all.