19 ms·

I use samber/lo in every project https://github.com/samber/lo https://github.com/samber/lo (Go is still plenty fast with it)

mseepgood 4y ago
That's really misguided. Go is not a functional programming language, it's an imperative programming language. You're going against its design. You're like these people who write Java and "class hierarchies" in Go, just from a different angle. If you like FP you should use Haskell instead of Go. I say this as a fan of Go.
- KingOfCoders 4y ago
  A map() is much easier to read and understand than create slice, for loop, return slice. Coding is about reading code.
  - morelisp 4y ago
    An unfused map-filter chain is a performance disaster waiting to happen.
    - KingOfCoders 4y ago
      In Go or in general? I've written code for companies with 50k+ concurrent writing users, I've bootstrapped and scaled and sold a startup on Scala (which has bad performance b/c of immutable lists but with usual list <100 elements no problem) and I haven't seen this in other languages, but I'm not experienced enough in Go and haven't deployed something major in Go yet.
      - morelisp 4y ago
        Other popular languages will fuse either via JIT or via some kind of linear types. You should preen less in your comments.
        KingOfCoders 4y ago
        I think it's always easier to understand a point of view if you know where someone is coming from and the context. "An unfused map-filter chain is a performance disaster waiting to happen." Could you share your experience with that perfromance disaster here?
- Zababa 4y ago
  I don't think things are that simple. I like functional programming, but I also like good tooling, having a rich ecosystem, job opportunities, backward compatibility, simplicity, people to talk to. There are lots of things that can weigh on your choice of language. Semi-functional Go might be the sweet spot for some people, and absolute hell for others.
morelisp 4y ago
> 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).

mseepgood 4y ago

That's really misguided. Go is not a functional programming language, it's an imperative programming language. You're going against its design. You're like these people who write Java and "class hierarchies" in Go, just from a different angle. If you like FP you should use Haskell instead of Go. I say this as a fan of Go.

KingOfCoders 4y ago
A map() is much easier to read and understand than create slice, for loop, return slice. Coding is about reading code.
- morelisp 4y ago
  An unfused map-filter chain is a performance disaster waiting to happen.
  - KingOfCoders 4y ago
    In Go or in general? I've written code for companies with 50k+ concurrent writing users, I've bootstrapped and scaled and sold a startup on Scala (which has bad performance b/c of immutable lists but with usual list <100 elements no problem) and I haven't seen this in other languages, but I'm not experienced enough in Go and haven't deployed something major in Go yet.
    - morelisp 4y ago
      Other popular languages will fuse either via JIT or via some kind of linear types. You should preen less in your comments.
      - KingOfCoders 4y ago
        I think it's always easier to understand a point of view if you know where someone is coming from and the context. "An unfused map-filter chain is a performance disaster waiting to happen." Could you share your experience with that perfromance disaster here?
Zababa 4y ago
I don't think things are that simple. I like functional programming, but I also like good tooling, having a rich ecosystem, job opportunities, backward compatibility, simplicity, people to talk to. There are lots of things that can weigh on your choice of language. Semi-functional Go might be the sweet spot for some people, and absolute hell for others.

morelisp 4y ago

> 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).