Nope
FP-Go: Functional programming library for Golang
141–150 of 185 posts
Re: FP-Go: Functional programming library for Golang
#142This 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.
I think most of the stuff in this repo is too much and trying to beat a square peg into a round hole, but the little things like Option and Either patch a hole in Go. I don't think I'd use them without them being in the stdlib, though, which is where such fundamental types belong. Those aren't even really functional, unless you count null pointers as necessarily imperative.
>... read some blog post about how functional programming and type theory will save the world, instead of actually being productive
I see the opposite side in Go a lot, where without testing or trying anything they dismiss everything they aren't already using right now as useless ivory tower academia, which is its own set of popular blog posts. Seems both sides have a lot of time to argue on the internet though, oddly the people who actually write code tend to be the productive ones regardless of philosophy.
Re: FP-Go: Functional programming library for Golang
#143Earlier quoted context omitted.
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…
> you have to return a useless nil pointer
nil is useful. Notably, you can derive meaning from its nil-ness. If you try to open a file and it doesn't exist, returning a nil handle is quite reasonable, and one can check for the existence of that handle without needing consider the error.
If, say, you returned an invalid file descriptor when the file could not be opened, conceivably that could make the handle useless, but that would not be idiomatic. That would just be a terrible API design and unkind to the users of your API.
> Funnily enough, your philosophy is far more true in a language with proper sum types.
Of course. But not the Either monad specifically, as its intent is to communicate a dependence between two variables. That can be useful in some languages where variable dependence is a convention, but that is not applicable to idiomatic Go.
Frankly, the only thing funny here is the idea that it is useful to reply to a thread before reading it. Let me reiterate: Either is not a suitable representation of (T, error). They have very different semantics. There are data structures which can serve as a suitable representation of (T, error), but Either is not it.
Re: FP-Go: Functional programming library for Golang
#144Earlier quoted context omitted.
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…
> you have to return a useless nil pointer nil is useful. Notably, you can derive meaning from its nil-ness. If you try to open a file and it doesn't exist, returning a nil handle is quite reasonable, and one can check for the existence of that handle without needing consider the error. If, say, you returned an invalid file descriptor when the file could not be opened, conceivably that could make the handle useless,…
>Most notably, you can derive meaning from its nil-ness.
This is sophistry. If I try to "use" a nil pointer I get a crash. I have to carefully check that it's non-null even if error is null. You can "derive" the same "meaning" from Result[T, error] being an error instead of a T. You can "derive" the same "meaning" from Option[T] being empty. There is no special meaning that a null file gives me that I can't take from a Result containing an error.
There isn't some big philosophical difference that Go is taking a principled stance on, just a practical one: with those you get type safety, and if you do it wrong you get a compilation error. In the Go way if you do it wrong you get a runtime panic.
>that would not be idiomatic. That would just be a terrible API design and unkind to the users of your API.
That is the vast majority of the stdlib and the vast majority of all popular Go libraries. If idiomatic Go code is code where (T, error) means T is always a useful value even if error is non-nil, then there is vanishingly little idiomatic Go code in existence.
>as its intent is to create a dependence between two variables.
This is nonsense. To use your personal specific terminology, Either encodes a dependence between variables that already exists, it doesn't create it. That dependence exists in Go too, Go isn't a language where the fundamentals of programming change, it's the same in C where people write methods that take both a result and an error pointer.
Either is an option to use when there is a dependence. If there isn't a dependence, and both are always present, you can and should return (T, error) and not Either[T, error]. No one is trying to force Go to always use Either when (T,error) would be appropriate, just like you are not forced to in other languages. You just have choices in those languages you do not have in Go, and overwhelmingly people choose more appropriate types than (T, error) when given the choice.
responding to your edit: >Either is not a suitable representation of (T, error). They have very different semantics. There are data structures which can serve as a suitable representation of (T, error), but Either is not it.
It's odd that you acknowledge this, but then claim that I somehow claimed the opposite. Perhaps you should follow your own advice about reading. Either represents a subset of the four cases that (T, error) covers, and even in Go the two cases that Either covers are the only ones in the vast majority of usage. In Go, most, but not all (and no one is claiming all), uses of (T, error) would be better expressed as Either[T, error].
In fact, the different semantics is the entire point. The point is not to keep the semantics the same but change up the syntax. In Go (T, error) is used commonly, in idiomatic Go unless the stdlib is unidiomatic, to emulate the semantics of Either[T, error]. If (T, error) doesn't have the right semantics for your program - and rarely are all four cases considered - then a more appropriate type with matching semantics should be used instead.
Re: FP-Go: Functional programming library for Golang
#145Earlier quoted context omitted.
> you have to return a useless nil pointer nil is useful. Notably, you can derive meaning from its nil-ness. If you try to open a file and it doesn't exist, returning a nil handle is quite reasonable, and one can check for the existence of that handle without needing consider the error. If, say, you returned an invalid file descriptor when the file could not be opened, conceivably that could make the handle useless,…
> Most notably, you can derive meaning from its nil-ness. This is sophistry. If I try to "use" a nil pointer I get a crash. I have to carefully check that it's non-null even if error is null. You can "derive" the same "meaning" from Result[T, error] being an error instead of a T. You can "derive" the same "meaning" from Option[T] being empty. There is no special meaning that a null file gives me that I can't take fro…
> I have to carefully check that it's non-null even if error is null.
Yes, that is true; at very least you need to read to documentation to understand if there is a relationship or not. Whereas Either defines an explicit dependence between two values, freeing you from that. With that, clearly they cannot be equivalent representations. I am surprised this is not obvious to you.
Honestly, I don't know what the rest of that gobbledygook is all about. It reads like one of those weird posts by Rust users we keep seeing where one is wallowing in the sorrow of not being able to grasp Haskell.
Re: FP-Go: Functional programming library for Golang
#146Earlier quoted context omitted.
> Most notably, you can derive meaning from its nil-ness. This is sophistry. If I try to "use" a nil pointer I get a crash. I have to carefully check that it's non-null even if error is null. You can "derive" the same "meaning" from Result[T, error] being an error instead of a T. You can "derive" the same "meaning" from Option[T] being empty. There is no special meaning that a null file gives me that I can't take fro…
> I have to carefully check that it's non-null even if error is null. Yes, that is true; at very least you need to read to documentation to understand if there is a relationship or not. Whereas Either defines an explicit dependence between two values, freeing you from that. With that, clearly they cannot be equivalent representations. I am surprised this is not obvious to you. Honestly, I don't know what the rest of…
>As you explain yourself, they cannot be equivalent representations.
That's the point. They are not equivalent, they represent different things, and Either is a better fit for the actual code even in Go most of the time. Go shouldn't force people to use (T, error) when Either[T, error] is the correct choice.
But that's twice now you've resorted to ad-hominem attacks instead of responding to the content, so I'll take your implicit admission that you have no rebuttals.
Re: FP-Go: Functional programming library for Golang
#147Earlier quoted context omitted.
> I have to carefully check that it's non-null even if error is null. Yes, that is true; at very least you need to read to documentation to understand if there is a relationship or not. Whereas Either defines an explicit dependence between two values, freeing you from that. With that, clearly they cannot be equivalent representations. I am surprised this is not obvious to you. Honestly, I don't know what the rest of…
>As you explain yourself, they cannot be equivalent representations. That's the point. They are not equivalent, they represent different things, and Either is a better fit for the actual code even in Go most of the time. Go shouldn't force people to use (T, error) when Either[T, error] is the correct choice. But that's twice now you've resorted to ad-hominem attacks instead of responding to the content, so I'll take…
> That's the point. They are not equivalent, they represent different things
Good. I'm glad you came back to the first comment in the thread. I am not sure why it took you so long, but I respect that you got there eventually.
> I'll take your implicit admission that you have no rebuttals.
Naturally. You finally realized what I said is true, and we've talked about nothing else. What could there possibly be to rebut? You have clearly not thought this through.
Re: FP-Go: Functional programming library for Golang
#148Earlier quoted context omitted.
>As you explain yourself, they cannot be equivalent representations. That's the point. They are not equivalent, they represent different things, and Either is a better fit for the actual code even in Go most of the time. Go shouldn't force people to use (T, error) when Either[T, error] is the correct choice. But that's twice now you've resorted to ad-hominem attacks instead of responding to the content, so I'll take…
> That's the point. They are not equivalent, they represent different things Good. I'm glad you came back to the first comment in the thread. I am not sure why it took you so long, but I respect that you got there eventually. > I'll take your implicit admission that you have no rebuttals. Naturally. You finally realized what I said is true, and we've talked about nothing else. What could there possibly be to rebut? Y…
I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks loudly. You also dance dishonestly around the actual point I made in that last post. Again, I'd recommend following your advice about reading a thread before responding to it.
Re: FP-Go: Functional programming library for Golang
#149Earlier quoted context omitted.
Either is nearly in the language anyways. The vast majority of pragmatic go functions will return [Result, Error] and or just [Error]. We are only missing support to treat this as a monad.
To me, the problem is that Go returns two values which makes it hard to compose functions.
That's deliberate to stop you trying to compose functions that return errors. You should be explicitly handling the errors before you compose.
Re: FP-Go: Functional programming library for Golang
#150Earlier quoted context omitted.
> That's the point. They are not equivalent, they represent different things Good. I'm glad you came back to the first comment in the thread. I am not sure why it took you so long, but I respect that you got there eventually. > I'll take your implicit admission that you have no rebuttals. Naturally. You finally realized what I said is true, and we've talked about nothing else. What could there possibly be to rebut? Y…
I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks loudly. You also dance dishonestly around the actual point I made in that last post. Again, I'd recommend following your advice about reading a thread before responding to it.
> Your claim of "in Go values must always be useful"
I said no such thing. I said idiomatic Go indicates that you must always make values useful. This is an onus placed on the programmer, not something guaranteed by the language. However, since the Either monad here was said to be introduced to wrap idiomatic Go code, not whatever haphazardly written Go code you happened to find in a SourceForge repository, that is of relevance.
> was rebutted multiple times
Cool. I must not have read it. There was a lot of weird shit in there that had nothing to do with anything. I'm not sure how that would even find relevance to the discussion taking place. I get that first year computer science programs are starting up and you're excited to share what you learned in your first week, but I really don't care. You are not going to tell me anything I haven't heard many times before.