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

131–140 of 185 posts

Re: FP-Go: Functional programming library for Golang

#131

Post by monksy »

_a_a_a_ wrote: post #130
cle wrote: post #98

Earlier quoted context omitted.

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 tha…

I think you should realize is theres a mindset in go. They're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it to look. It's also designed to be basically a toy language to "make programming easier". They don't want language improvements like this for the most part.

The creator made it because: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

Re: FP-Go: Functional programming library for Golang

#132

Post by randomdata »

garfij wrote: post #114
randomdata wrote: post #90

> If your pure function can return an error, then it will have a (T, error) return value in idiomatic go. In functional style the return value is Either[error, T] because function composition is easier with such a return type. This seems flawed. In idiomatic Go, T and error are always independently observable. The Either monad implies that they are dependent, which is not true.

I spent about 6 years writing Go at $dayjob, and while what you're saying is technically true, idiomatically you also generally wanted to avoid scenarios where you would _want_ to observe them independently. The standard behavior is is if `err != nil`, the result should be ignored.

That is incorrect. Idiomatic Go is abundantly clear that values must always be useful, even if all you have is the default value. Thus T must be useful regardless of the state of error, and vice versa. As such, they are free to be observed independently. That does not mean T and error cannot be in a relationship, but they are not dependents.

There being a relationship between T and error is common, but observance of error is only significant when the error is relevant. Quite often it is, but not always, and in the latter case you can, assuming the code is idiomatic, safely use T and ignore error. T must be useful, after all.

It may be possible to create a scenario where T is not useful when error is not nil if you really want to screw with people, but that code would decidedly not be idiomatic. Indeed, there is always some way to screw with people if you try hard enough, but that's really beyond this discussion.

The use of the Either monad here is trying to cover a dependency which doesn't exist.

Re: FP-Go: Functional programming library for Golang

#133

Post by _a_a_a_ »

monksy wrote: post #131
_a_a_a_ wrote: post #130

Earlier quoted context omitted.

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 tha…

I think you should realize is theres a mindset in go. They're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it to look. It's also designed to be basically a toy language to "make programming easier". They don't want language improvements like this for the most part. The creator made it beca…

> They’re typically, fairly young, fresh out of school

Okay, thanks for clarifying and snakes and ladders is a great game for kids but how long do kids remain kids? They don't and they shouldn't. They don't need constraining for long.

> 're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it to look.

And as a professional programmer I couldn't give a toss about this, I just want people to be consistent and sensible, and that means useful comments, documentation, a test suite, specs, not going insane on any particular style like OO/FP. You have to trust the programmer in the end cos all the guidelines in the world won't cure stupidity.

Re: FP-Go: Functional programming library for Golang

#134

Post by monksy »

_a_a_a_ wrote: post #133
monksy wrote: post #131

Earlier quoted context omitted.

I think you should realize is theres a mindset in go. They're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it to look. It's also designed to be basically a toy language to "make programming easier". They don't want language improvements like this for the most part. The creator made it beca…

> They’re typically, fairly young, fresh out of school Okay, thanks for clarifying and snakes and ladders is a great game for kids but how long do kids remain kids? They don't and they shouldn't. They don't need constraining for long. > 're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it t…

I'm not sure how I'm replying to your message.

However the quote was made by the creator, not me. It's pretty frustrating that the justification and entire philosophy of the language surrounded is "we can't get better at this because it requires work" (Queue up the next few replies to me from people that say "but needless complexity and business value" )

> nd as a professional programmer I couldn't give a toss about this, I just want people to be consistent and sensible, and that means useful comments, documentation, a test suite, specs, not going insane on any particular style like OO/FP. You have to trust the programmer in the end cos all the guidelines in the world won't cure stupidity.

I agree with you. For the most part the industry has had expected language style guide lines (See the Java Style guide) and has had tools that support opting out of guidelines and defining organizational or project based expectations. This is not the case in Go. Gofmt will break your spaces decision and go to tabs. (https://news.ycombinator.com/item?id=7914523) Their response is they don't give a flip.

Re: FP-Go: Functional programming library for Golang

#135

Post by _a_a_a_ »

monksy wrote: post #134
_a_a_a_ wrote: post #133

Earlier quoted context omitted.

> They’re typically, fairly young, fresh out of school Okay, thanks for clarifying and snakes and ladders is a great game for kids but how long do kids remain kids? They don't and they shouldn't. They don't need constraining for long. > 're highly opinionated about how you structure code, how you format your code (capitalization on all functions as a means to express public/private, tabs, etc), and how they want it t…

I'm not sure how I'm replying to your message. However the quote was made by the creator, not me. It's pretty frustrating that the justification and entire philosophy of the language surrounded is "we can't get better at this because it requires work" (Queue up the next few replies to me from people that say "but needless complexity and business value" ) > nd as a professional programmer I couldn't give a toss about…

Okay, by stating their position I took it that you were supporting their position, which I see now was my misunderstanding. Gotcha, and thanks

Re: FP-Go: Functional programming library for Golang

#137

Post by charlieflowers »

KingOfCoders wrote: post #47
charlieflowers wrote: post #8

Earlier quoted context omitted.

`Either` works pretty well in Go. I implemented it and it felt reasonably close to Rust/Haskell (without `try!` of course).

I don't think you should bolt every concept into every language. One USP of Go is how dead simple it is to learn and how fast it compiles (because it is dead simple - compare it to Rust compile times). I did a lot of Lisp and Haskell, scaled a startup on FP Scala code and sold it. I did put Option everywhere. In the 2000s I came up with the Iterable hack for Option in Java public abstract class Option[T] implements I…

I agree about cramming features across languages. Plus, Software dev is social. I only did this in code for myself.

That being said though, it actually fit really well in golang. Allowed functions that used to return ‘null, err’ to return an Either, which improved on all the downsides of returning null (if you return null your callers have to check for it).

It actually improved the ergonomics quite a bit. ‘Either’ fits nicely into golang, but I doubt it will become mainstream anytime soon.

Re: FP-Go: Functional programming library for Golang

#138

Post by awused »

randomdata wrote: post #132
garfij wrote: post #114

Earlier quoted context omitted.

I spent about 6 years writing Go at $dayjob, and while what you're saying is technically true, idiomatically you also generally wanted to avoid scenarios where you would _want_ to observe them independently. The standard behavior is is if `err != nil`, the result should be ignored.

That is incorrect. Idiomatic Go is abundantly clear that values must always be useful, even if all you have is the default value. Thus T must be useful regardless of the state of error, and vice versa. As such, they are free to be observed independently. That does not mean T and error cannot be in a relationship, but they are not dependents. There being a relationship between T and error is common, but observance of…

This is nonsense. This isn't about idiomatic Go or not, there is only one way to do things in Go, so a function doing things in that one way doesn't communicate anything to the caller. If you try to open a file, and the file doesn't exist, you have to return a useless nil pointer alongside the error and there is no way to magic up a "useful" T. Usually err != nil means T == nil, so trying to blindly use T assuming it's "useful" will panic and crash your program.

The idiomatic Go way to work around this is to write comments saying "sometimes T is non-nil even if err is non-nil, you need to handle this" and hoping your callers read your comments.

Funnily enough, your philosophy is far more true in a language with proper sum types. In Haskell/Ocaml/Rust, returning a tuple of (T, error) does mean that both T and error should both be "useful", because if they weren't the function would have chosen to return one or the other but not both. You're reading meaning into Go code where meaning can't be present, because there's no choice to be made, and ignoring languages where you actually can have the semantics you want Go to have.

Re: FP-Go: Functional programming library for Golang

#139

Post by cle »

_a_a_a_ wrote: post #130
cle wrote: post #98

Earlier quoted context omitted.

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 tha…

> Do we have to do the "I don't really get it so nobody else should have it" kind of thing.

Do we have to do the ad hominem thing? I studied FP and type theory in grad school. It's possible to know about FP and not want to use it in software engineering.

Re: FP-Go: Functional programming library for Golang

#140

Post by awused »

vlowther wrote: post #116
garfij wrote: post #114

Earlier quoted context omitted.

I spent about 6 years writing Go at $dayjob, and while what you're saying is technically true, idiomatically you also generally wanted to avoid scenarios where you would _want_ to observe them independently. The standard behavior is is if `err != nil`, the result should be ignored.

Anything that implements or consumes `io.Reader` or `io.Writer` would dispute that.

Yeah, there are counterexamples, but the only way to know is to read the comments or source code of the function you're calling. (T, err) doesn't convey any useful information and, in the overwhelming majority of cases, err != nil means T is a meaningless default value that should be ignored or a null pointer.

By and large I think the stuff in this repo is too much and doesn't fit Go. I don't particularly want Go to pretend to be functional, but Either and Option at least would be nice to have in the stdlib and help prevent this exact issue where there are rare exceptions to normal practices. I don't see them getting widespread use without being part of the stdlib though. If Either/Option were common in Go but io.Reader was one of the few APIs returning (T, error), that would convey a lot more information.

Post reply on HN