4 ms·

> Go is still plenty fast with it It is not. Your program might still hit acceptable speed targets, but you're taking enormous absolute perf hits for extremely

> Go is still plenty fast with it It is not. Your program might still hit acceptable speed targets, but you're taking enormous absolute perf hits for extremely questionable gains. https://news.ycombinator.com/item?id=30696210 https://news.ycombinator.com/item?id=30696210

KingOfCoders 4y ago
Thanks for the tip, I've written code for 40+y and have been paid in 10+ languages, I'm writing the code that I think is easiest to maintain for the years coming in the language I consider the best for the job.
- mseepgood 4y ago
  As long as it's only you who has to maintain the code and not another Go programmer ...
  - KingOfCoders 4y ago
    The Go developers I know understand map() and filter() perfectly well.
- saturn_vk 4y ago
  What a condescending comment in response of someone trying to help
  - KingOfCoders 4y ago
    s/trying to help/trying to be right/g The linked comment was about an implementation of partition with the specific problem of allocating too many slices in the opinion of the author. It was not about lo in general, did not help or shared any performance numbers E.g. for a size of a usual lists of <50 elements with filter() or the use case of three chunks, that people use when writing web applications (which I do, I don't write a database in Go - something the author could have found out my asking instead of assuming).
    - morelisp 4y ago
      There's no ergonomic loss to using the faster approach. It's just cargo culting patterns from other languages even though they're less accessible and less performant in Go. The problem with your comments isn't the context for what you're doing, it's the "40y, scaled and sold" bullshit. That's bragging, not an argument nor context. Or as a senior colleague used to remind me, "shipping is easy if you're willing to ship shit." I'm not here to discuss shipping.
      - KingOfCoders 4y ago
        "shipping is easy if you're willing to ship shit." What a nasty comment.

KingOfCoders 4y ago

Thanks for the tip, I've written code for 40+y and have been paid in 10+ languages, I'm writing the code that I think is easiest to maintain for the years coming in the language I consider the best for the job.

mseepgood 4y ago
As long as it's only you who has to maintain the code and not another Go programmer ...
- KingOfCoders 4y ago
  The Go developers I know understand map() and filter() perfectly well.
saturn_vk 4y ago
What a condescending comment in response of someone trying to help
- KingOfCoders 4y ago
  s/trying to help/trying to be right/g The linked comment was about an implementation of partition with the specific problem of allocating too many slices in the opinion of the author. It was not about lo in general, did not help or shared any performance numbers E.g. for a size of a usual lists of <50 elements with filter() or the use case of three chunks, that people use when writing web applications (which I do, I don't write a database in Go - something the author could have found out my asking instead of assuming).
  - morelisp 4y ago
    There's no ergonomic loss to using the faster approach. It's just cargo culting patterns from other languages even though they're less accessible and less performant in Go. The problem with your comments isn't the context for what you're doing, it's the "40y, scaled and sold" bullshit. That's bragging, not an argument nor context. Or as a senior colleague used to remind me, "shipping is easy if you're willing to ship shit." I'm not here to discuss shipping.
    - KingOfCoders 4y ago
      "shipping is easy if you're willing to ship shit." What a nasty comment.