Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FP-Go: Functional programming library for Golang

github.com

Post reply on HN
Print view View original

121–130 of 185 posts

Re: FP-Go: Functional programming library for Golang

#121

Post by eweise »

jpk wrote: post #43
sambeau wrote: post #37

I’m sorry, but this is just awful. func TraverseTuple10[F1 ~func(A1) IOEither[E, T1], F2 ~func(A2) IOEither[E, T2], F3 ~func(A3) IOEither[E, T3], F4 ~func(A4) IOEither[E, T4], F5 ~func(A5) IOEither[E, T5], F6 ~func(A6) IOEither[E, T6], F7 ~func(A7) IOEither[E, T7], F8 ~func(A8) IOEither[E, T8], F9 ~func(A9) IOEither[E, T9], F10 ~func(A10) IOEither[E, T10], E, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, T1, T2, T3, T4, T…

Big Scala vibes here, see also [1]. 1: https://github.com/scala/scala/blob/v2.13.11/src/library/sca...

That looks pretty straightforward actually.

Re: FP-Go: Functional programming library for Golang

#122

Post by stouset »

Cthulhu_ wrote: post #69
physicles wrote: post #36

This is a tour de force, and it accomplishes the goal of enabling FP using the Go syntax and toolchain. But code written using this library is no longer Go: most Go programmers can't grok it, and it's awkward to call normal Go libraries because there's no way to know if that function you're calling is pure. If your goal is to "make it easy and fun to write maintainable and testable code in golang" by making pure func…

It's syntactically Go but it adds a functional DSL on top of it - that is, you can't just know Go, you need to learn the ins and outs of this library too (plus functional programming) before you can use it. I cannot recommend this unless you really have to for whatever reason. Besides readability, another factor to consider is performance; Go is not optimized for functional programming structures. It doesn't have thi…

> you can't just know Go, you need to learn the ins and outs of this library too… before you can use it.

That is… literally just how libraries are. You need to understand the underlying language and the semantics and details of the library API.

Re: FP-Go: Functional programming library for Golang

#123

Post by yoyohello13 »

physicles wrote: post #36

This is a tour de force, and it accomplishes the goal of enabling FP using the Go syntax and toolchain. But code written using this library is no longer Go: most Go programmers can't grok it, and it's awkward to call normal Go libraries because there's no way to know if that function you're calling is pure. If your goal is to "make it easy and fun to write maintainable and testable code in golang" by making pure func…

This is basically lodash all over again. Now I need to know two languages to read your code.

Re: FP-Go: Functional programming library for Golang

#124

Post by jerf »

cle wrote: post #118
jerf wrote: post #109

Earlier quoted context omitted.

"Nobody" uses this stuff in Go. I mean I'm sure it's not literally nobody, but I'm yet to encounter even one example of someone using this stuff in the wild. I'd love to be able to survey the authors of the dozen-ish variations on this posted over the last couple of years (most of the much less elaborate than this) and see how many of them are still using it in their real code. Again I'm sure the answer isn't literal…

Saying no to generics sends a strong signal to FP astronauts to "take it somewhere else". This saying no to a huge number of things is the superpower of Go and its community IMO, but those "go away" signals are getting weaker over time, which increases the likelihood of needing conversations and decisions about when to use what style, which is exactly the sort of thing I enjoy not having to do with Go. For example: t…

The primary "conversations" that are spawned almost entirely consist of 1. people saying no thank you and 2. people expressing concern that this will become successful.

You can stop worrying about generics causing this.

Iterators may do a bit, but I still think that based on what is currently baking that people are going to find trying to do large amounts of work through iterators is not going to scratch their itch to do everything in a foreign paradigm.

If you want to work in a certain paradigm, then for pete's sake, do it. Go do it in a language where it's the best solution. Don't find the best solution in X, then try to jam it into Y at all costs. This isn't special to X = Haskell and Y = Go, it's true for all combinations of languages.

Re: FP-Go: Functional programming library for Golang

#126

Post by lenkite »

38 wrote: post #119
lenkite wrote: post #111

Earlier quoted context omitted.

Actually, this sample is pretty easily followed and readable to anyone familiar with iterators, tuples, filter, map and transduction. Sure the stuff like Pipe3/Map2 is irritating because Go doesn't have function overloading. Now, try and do the equivalent in "normal" Go code - it will be 3x-5x the lines of code. (Probably more)

it has no error handling. also look at the API, what a joke: https://godocs.io/github.com/IBM/fp-go/function and check out the "constants": https://godocs.io/github.com/IBM/fp-go/function#pkg-variable...

It actually does have error handling. It uses a Result type

    type ReaderIOEither[A any] RE.ReaderIOEither[context.Context, error, A]
In fact the test code you linked actually even does a check on the result:

   assert.Equal(t, E.Of[error](count), result())
In order to avoid all those excessive functions and 'silly' constants, Go needs to support const and variadic generics like C++ does. Then the API would become quite clean.

I am not supporting the use of this library in prod code used in a large team - but its OK for small tools where one needs to iterate quickly. Folks familiar with FP constructs (esp users of fp-ts) would follow this code almost immediately. Basically the dirtiness and pain (most of it) has been encapsulated into the library.

Re: FP-Go: Functional programming library for Golang

#127

Post by vjerancrnjak »

38 wrote: post #119
lenkite wrote: post #111

Earlier quoted context omitted.

Actually, this sample is pretty easily followed and readable to anyone familiar with iterators, tuples, filter, map and transduction. Sure the stuff like Pipe3/Map2 is irritating because Go doesn't have function overloading. Now, try and do the equivalent in "normal" Go code - it will be 3x-5x the lines of code. (Probably more)

it has no error handling. also look at the API, what a joke: https://godocs.io/github.com/IBM/fp-go/function and check out the "constants": https://godocs.io/github.com/IBM/fp-go/function#pkg-variable...

This library is almost a copy of fp-ts library (TypeScript).

You are forced to handle errors. The result is almost certainly an Either[Error, Result].

fp-ts in TypeScript is not syntactically nice but it feels simple enough that after a week you can be pretty comfortable with it. Although, TypeScript compiler might be much better at inferring types than Go. My experience with fp-ts is that most of the time I do not have to write any type annotations except the top level ones.

The API looks fine, you will find similar type annotations in fp-ts and in Haskell, that's just how handling variadics works in most languages and for useful abstractions like traverse/map/chain you need to have the variadic ones available to avoid having to deal with arrays of anonymous functions (that might all need to have the same type).

When you spend a significant time writing fp-ts you barely look at the types. The experience of writing the code is smooth. Code written still has similar pitfalls as regular imperative programming, pyramids of doom, readability, most of the functions "annotated" with async but they are pure or can be pure if you order the data better etc.

I would say there is friction in the beginning, but as time passes, the brain learns how to parse the code. The effect felt very similar to me when I shifted from colored syntax to just plain black on white. After some point brain does its magic.

Re: FP-Go: Functional programming library for Golang

#129

Post by 38 »

lenkite wrote: post #126
38 wrote: post #119

Earlier quoted context omitted.

it has no error handling. also look at the API, what a joke: https://godocs.io/github.com/IBM/fp-go/function and check out the "constants": https://godocs.io/github.com/IBM/fp-go/function#pkg-variable...

It actually does have error handling. It uses a Result type type ReaderIOEither[A any] RE.ReaderIOEither[context.Context, error, A] In fact the test code you linked actually even does a check on the result: assert.Equal(t, E.Of[error](count), result()) In order to avoid all those excessive functions and 'silly' constants, Go needs to support const and variadic generics like C++ does. Then the API would become quite c…

> In order to avoid all those excessive functions and 'silly' constants, Go needs to support const and variadic generics like C++ does.

oh yes, lets look to C++ as a shining example. lets please not ruin another language by bolting on functional programming. if you want functional programming, use a functional language.

If you want to use Go, just use a for loop like everyone else.

Re: FP-Go: Functional programming library for Golang

#130

Post by _a_a_a_ »

cle wrote: post #98
physicles wrote: post #36

This is a tour de force, and it accomplishes the goal of enabling FP using the Go syntax and toolchain. But code written using this library is no longer Go: most Go programmers can't grok it, and it's awkward to call normal Go libraries because there's no way to know if that function you're calling is pure. If your goal is to "make it easy and fun to write maintainable and testable code in golang" by making pure func…

I believe these things are mostly productivity sinks, which is why I am such a Go fan and also so sad to see these types of projects in Go. This is exactly what I was afraid of when generics were introduced, and now I get to spend time arguing with people who read some blog post about how functional programming and type theory will save the world, instead of actually being productive. Ugh.

Do we have to do the "I don't really get it so nobody else should have it" kind of thing. I have a reasonable level of experience with FP and a lot of general experience (I'm not someone who "read a blog post", I've used it commercially) and I find that it's very handy at the right time. So it can be abused like anything else. So people can write over-complex stuff, true, so blame the language because it's easier than addressing the root problem which is people (it's always people isn't it). In a good language (Scala) it really makes a difference.

Please dial back your casual critiques.

> This is exactly what I was afraid of when generics were introduced

Good god. IDK, perhaps hardware would better suit your skill set? It certainly scares me off, but you might have a good mind for it.

Post reply on HN