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 functions first-class, is there another way to do that without inventing a new language?

From experience and inspired by Carmack's classic essay on FP in C++[1], I tend toward a functional style: minimize state, treat locals as const, avoid non-const globals, enable parallelism by isolating state. Go makes it easy to write static analysis tools, so go vet could be augmented to, for example, keep track of which functions are pure, and show some yellow underlines at those places where input parameters are mutated.

I'd use something like that.

[1] http://sevangelatos.com/john-carmack-on/

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 things like tail call optimization.

There's better languages than Go if you want to / have to do functional programming.

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

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.

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

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.

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"

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.

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.

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.

Then it got even harder with you dissing generics, which are so fundamentally valuable, such a labour-saver, that the idea of programming being better without them is beyond my ken.

So please lay out your case and I'd be willing to talk.

That said, I actually do remember my first exposure to Golang being a blog post about using monads to avoid incessantly typing `if err != nil`. Very much like that original author, my personal values in software engineering just don't align with Go at all, and that should be OK!

I'm biased because I've built a career on Go at this point but the pragmatism and ability to just get things done in Go without faffing about with unnecessary abstractions is I think one of the strongest practical demonstrations of how incredible an imperative language can be, and for me personally at least, no FP language will ever beat the productivity that I can achieve with Go, especially because at least in my problem ___domain the real world problems always have enough corner cases that FP wouldn't even be useful.

In Go I just systematically eliminate and handle each possible step and state, in a straightforward way, directly deal with the business logic, and then it's done and it works predictably and efficiently for years. Interfaces really are a sufficient form of polymorphism, too.

As it turned out, I accidentally started learning some functional-lite paradigms in Python. I learned that I actually do like some of these paradigms, and think through them already, I just couldn't connect my internal understanding with the language of FP.

I started learning Rust recently, as it's an exciting systems language with some hype. There, you see even more functional bits which is just a pleasure to use. I'm not in an area where purely functional would make sense but having the quality of life that certain paradigms brings is nice.

I'm still very much a novice in FP techniques, but the ability to try aspects as I go is helpful in learning.

At the time, I remember finding FP in go surprisingly ergonomic. Implementing the library to support it was a pain since the type system wasn't expressive enough to prevent everything from devolving into a pile of untyped reflection, but it was reasonably easy to keep that an implementation detail. On the whole, I felt like go would have lent itself well to the "dash of FP for flavor" style of programming that seems to be gaining popularity these days. Unfortunately, in 2017 at least, the Go community seemed to have very little interest in the idea.

I still have a fondness for Go. It always felt nice to use. If the language features have caught up to the point where a robust library like this is feasible, and the communities attitude has shifted, I might take another look at the language.

Are there any examples you'd be interested in in particular?

type IO[A any] func() A

If you consider this a valid approach, then the set of monadic helper functions make it easier to compose these effectful functions with pure functions.

This article https://betterprogramming.pub/investigating-the-i-o-monad-in... contains some more detailed reasoning.

https://github.com/IBM/fp-go/tree/main/samples

  data := F.Pipe3(
   T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"),
   T.Map2(H.MakeGetRequest, H.MakeGetRequest),
   R.TraverseTuple2(
    readSinglePost,
    readSingleCatFact,
   ),
   R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")),
  )

There's some chat about adding some variant of (x, y => z) to Go, though even then you're adding some more symbols to an already symbol-heavy structure and it looks even worse when you're not using x y z but (username, accountId => a few lines of username and accountId being used).

People should stop pushing these things already, no one cares but them.

Given the way fp-ts work, this library should be very type safe.

But of course, all of this looks much prettier and less verbose in haskell

This is why some of the functions that work with many arguments (such as `Pipe`, `Flow`, `Traverse` ...) carry their cardinality as a suffix. Their shapes are then auto-generated up to a max cardinality that seems to make sense in practice.

So the traverse tuple function does not only exist for cardinality 2 but also for higher ones. But unfortunately you have to specify it explicitly.

Go provides a set of nice features (fast startup, easy cross-platform building, great tooling, good package management) that can be hard to come by with other languages. It is not unreasonable to want to have your cake (all of the above features) and eat it too (occasionally use functional idioms in addition to the usual imperative ones).

For this reason I try to keep abreast of the various FP libraries in Go, though I have yet to use one in anger.

- https://github.com/samber/lo

- https://github.com/samber/mo

The split is also nice as you can choose to just use the generic convenience functions from lo without the more FP related things from mo.

Step 2: Add “Monoids for the Endomorphism where the `concat` operation is the usual function composition.”

Step 3: …

Step 4: Profit?

1) Go doesn't have a concise lambda expression. This makes the functional approach in Go will be more verbose and less readable than the traditional imperative approach.

2) Go's type inference is not sophisticated enough. Most of the time you will still need to explicitly annotate the types, which, again, makes it more verbose and less readable.

2) I absolutely agree, type inference could be better. However this has improved over time and go1.21 has also made good progress. I would expect that type inference will continue to improve in the future. This library tries to easy the pain of having to specify types redundantly by carefully choosing the order of type parameters. Those parameters that can be inferred (e.g. because they are part of the immediate function argument) come last, whereas the parameters that cannot be inferred come first, so you only have to specify those. This compromizes on a consistent type ordering, preferring useability over (internal) consistency. Examples are `Left` and `Right` of the `either` package. The order of type parameters is reversed between the two to avoid excessibe typing.

func TraverseParTuple10[F1 ~func(A1) ReaderIOEither[T1], F2 ~func(A2) ReaderIOEither[T2], F3 ~func(A3) ReaderIOEither[T3], F4 ~func(A4) ReaderIOEither[T4], F5 ~func(A5) ReaderIOEither[T5], F6 ~func(A6) ReaderIOEither[T6], F7 ~func(A7) ReaderIOEither[T7], F8 ~func(A8) ReaderIOEither[T8], F9 ~func(A9) ReaderIOEither[T9], F10 ~func(A10) ReaderIOEither[T10], A1, T1, A2, T2, A3, T3, A4, T4, A5, T5, A6, T6, A7, T7, A8, T8, A9, T9, A10, T10 any](f1 F1, f2 F2, f3 F3, f4 F4, f5 F5, f6 F6, f7 F7, f8 F8, f9 F9, f10 F10) func(T.Tuple10[A1, A2, A3, A4, A5, A6, A7, A8, A9, A10]) ReaderIOEither[T.Tuple10[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]]

(https://pkg.go.dev/github.com/IBM/fp-go/context/readerioeith...)

cracks knuckles over keyboard

But this complexity is an implementation detail of the library, you do not have to understand it as a user of these functions. From my perspective it is a valid approach to move complexity from use application layer into the library layer, so it can be hidden there and tested once.

Kill it with fire but make sure to pour some Holy water first.

    client := H.MakeClient(HTTP.DefaultClient)
    readSinglePost := H.ReadJson[PostItem](client)
    readSingleCatFact := H.ReadJson[CatFact](client)
    
    data := F.Pipe3(
      T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"),
      T.Map2(H.MakeGetRequest, H.MakeGetRequest),
      R.TraverseTuple2(
         readSinglePost,
         readSingleCatFact,
      ),
      R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")),
    )
    
    result := data(context.Background())
    fmt.Println(result())

Now, try and do the equivalent in "normal" Go code - it will be 3x-5x the lines of code. (Probably more)

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

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.

    type ReaderIOEither[A any] RE.ReaderIOEither[context.Context, error, A]

   assert.Equal(t, E.Of[error](count), result())

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists.

>more baseless ad-hominem and ignoring the points

I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically.

> I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

That may be true, but of no relevance. I can see why I didn't bother reading it. Thanks for clarifying that it would have been a waste of my time.

>That may be true, but of no relevance.

So you agree with this, and it rebuts the entire contents of the first post I responded to. I wonder why you were posting irrelevant, off-topic content yourself. But I'm glad you finally agree that Go isn't flawless.

"That's the point. They are not equivalent, they represent different things" – Oh snap. Well, so much for that silly tangent.

If you want to actually have a discussion, you are going to have to go and understand the discussion that was taking place before you tried to take it in some weird and nonsensical direction. The non-sequitors may be entertaining, maybe even true, but off in la-la land with respect to the conversation taking place.

If your intent is simply to be my personal jester, then by all means, run with it. I'll continue to enjoy the laughs. Most people would pay good money to see an entertainer of this caliber, and you are offering it to me for free! I feel privileged.

> If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise

It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. That is extremely unusual and would be generally confusing.

https://google.github.io/styleguide/go/decisions#returning-e...

Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic.

I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error.

> If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise

This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee).

But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.

And the Go style guide says otherwise: if err is non-nil, you shouldn't even check the other return values. The Go proverbs are just words, it doesn't make them true or even good ideas. When Go proverbs don't agree with how Go code is written, including idiomatic Go code, reality wins over a bad theory. The Go style guide happens to better match real code written by real people, even the people directly responsible for the proverbs.

>I'd love to see some real-world code you think is idiomatic

To be fair, I have been talking about the Go programming language and idiomatic code written in that language. You seem to have a different idea of "Idiomatic Go" from everyone else's. Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.

Yes, it says you cannot trust functions, unless documented, to be idiomatic. Which is reasonable as not all code is idiomatic. The language goes to no lengths to enforce how the code is written in this regard (obviously). But we are talking about code that is known to be idiomatic.

> Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.

1. I don't see how it could be. What is idiomatic emerges from writing code and seeing what works and what doesn't. Most of the stdlib was written in the early days before anyone understood what works best. And, thanks to the go1 guarantee, modifying it now is out of the question.

2. If you believe that the stdlib is idiomatic, then you have to accept that returning an int (-1) to represent an error is idiomatic. The standard library is full of that. Which violates the premise of FP-Go that (T, error) is idiomatic. That is not my claim, that is theirs.

That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. It never affirms your particular, personal, definition of what "Idiomatic Go" is and directly contradicts it.

>If you believe that the stdlib is idiomatic

I believe most of the stdlib is idiomatic Go, especially the newer stuff. Your excuse earlier was that the older stuff in the stdlib isn't idiomatic but the newer stuff is. But the newer stuff doesn't match your personal standards for being idiomatic either. I would challenge you to point to a large body of code that actually matches your definition of idiomatic, I do not think it exists.

No, it is very much written from a consumer perspective. There is known, non-idiomatic, code where relying on T in its error state is problematic, so the guidance is reasonable and logical.

But we're talking about this from the producer perspective. These do not challenge each other and can exist in harmony.

> believe most of the stdlib is idiomatic Go, especially the newer stuff.

I wholeheartedly agree, at least with respect to the newer stuff, and have already said as such. Now this is where, in that newer work which is idiomatic, you point to a good example of where you can find meaningless return values when there is an error.

Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error, so we need to identify those which buck the trend if we want to hold it as a counterexample of this being an idiomatic practice.

This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever return meaningful non-error values with an error if explicitly documented, and the consumer should only ever expect those when documented.

>you point to a good example of where you can find un-meaningful return values when there is an error.

Okay, skimming the release notes for 1.21. The slog package, brand new in 1.21, contains a MarshalText method (and others, but this is the first I noticed). It returns ([]bytes, err) and it is not documented to be idiomatic as per your personal definition. Therefore, by your interpretation of the style guide and your own personal standards, it is not idiomatic. What's more, a nil/empty slice is potentially valid output from marshaling something, so the slice is entirely useless and must be ignored if err is non-nil. It is not valid to try to "derive meaning" (your terminology) from the slice being nil or not, so it is well and truly useless if err isn't nil.

Moreover, I'll assert that if Either existed in the stdlib, it would return Either[bytes[], err] instead of ([]bytes, err), and it is a limitation of Go that they're using (T, error) which does not offer the appropriate semantics.

>Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error

This, too, is simply a lie.

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.

Go Proverb #5: Make the zero value useful.

> that should be ignored or a null pointer

nil is the zero value of a pointer, so it should be made useful per the above, but it is also inherently useful even if you put no thought into it. It allows you to know that there is an absence of a value out of the box.

And this is actually why the vast majority of (T, error) cases in idiomatic code sees T be a pointer, despite the computational and programatic downsides of using a pointer, so that nil can be returned when the value is not otherwise useful – exactly to ensure the value is as useful as possible, denoting the absence of a usable value.

If you read through idiomatic code, you'll notice that only when the underlying type is more meaningful is a pointer not used. Returning a slice is one such example. An empty set upon error is more meaningful than nil, usually. Another common instance is when 0 is meaningful, like in the aforementioned io.Reader interface. Idiomatically, one will always strive to return the most meaningful value they can.

> Either and Option at least would be nice to have in the stdlib

And if it were, then this Either wrapper in question would become useful as an overlay to it, as they would then share the same intent and meaning. But it does not match the current semantics of idiomatic Go code using the (T, error) pattern.

You can probably make it work, but code is about communicating ideas to other programmers. Either implies a dependence between variables. (T, error) has no such dependence. There is an impedance mismatch here which fails to properly communicate what is happening.

Yeah, it's a nice quip, but that's all it is. It sounds nice on first read to someone who doesn't program much. But it is inaccurate and not followed by Go, and is explicitly against the Google style guide.

The sophistry trying to paint a nil pointer as "useful" is just trying to defend a position you've dug yourself into in the process of this argument, so it doesn't really need to be addressed again.

>An empty set upon error is more meaningful than nil, usually.

This in particular is just a mistake in Go. Nil maps, unlike nil slices, cause panics, so people try to avoid ever returning them.

>But it does not match the current semantics of idiomatic Go code using the (T, error) pattern.

But it does match how (T, error) is actually used the majority of the time. The impedance mismatch is that code that currently has the semantics of Either, which is the vast majority of idiomatic Go, needs to use (T, error).

You are right. I concede nil is not useful. Therefore, we agree that (T, error) cannot exist. As we see in the style guide: "Returning a nil error is the idiomatic way to signal a successful operation that could otherwise fail." This means there is no way to check the error condition. One might be tempted to write `if err != nil`, but because nil is not useful that obviously won't work. That would make nil a useful value, just as I once thought – incorrectly, as you helpfully made me realize – a nil T would be.

And as the Go style guide indicates that you cannot use the T value without first touching the error value, which is, for all practical purposes, impossible since the error value may not be useful, there is just no way this pattern can be used in any actual program.

> But it does match how (T, error) is actually used the majority of the time.

Right. As you have pointed out – of which I was reluctant to admit to, but you said it enough times that it must be true! – (T, error) cannot be used. Period. Its values do not convey the useful information required to be useable. Either does, then, indeed, match how (T, error) is used most of the time... which is to say not at all!

You mentioned something about MarshalText in the slog package showing how an idiomatic function with errors might actually be written, but then we realized that there are multiple implementations with the same name. Which one were you referring to?

You say this sarcastically, but it is actually true. A nil pointer is not useful. Once you have determined that a pointer is nil, you have confirmed that the function returning it at all was a waste of both space and time. Though it's actually only half true: nil pointers are worse than useless and they provide negative utility, because they allow invalid code to compile. A better design - which is also more efficient, even considering the overhead of tagged unions - is to not return the pointer/value at all if it would be useless. Other languages allow for this, even C does allow for it with manually tagged unions. Go is rather unique, especially among modern languages, in how it doesn't provide any mechanism for it, so people use what is available to emulate that.

For the rest of it, well, you've contorted yourself into some really interesting positions.

It's not a question what is or isn't better. That's off-topic. It's just a question of how can we actually deal with the situation with the tools that Go gives us? MarhsalText no doubt contains the answers, but we aren't sure where to find it given the ambiguity. You went to all the trouble of looking it up to tell us about it, but now want to keep it a secret?

https://github.com/koss-null/FuncFrog

still prefer non-FP part tho

Trying to merge this abstractions and patterns with existing Golang's philosophy and community libraries is simply a case of over-engineering.

Picture jumping into a codebase to quickly fix something, then stumble upon ChainFirstIOK or Eithersize5 because someone went overboard showing off that they remember FP from cs classes.

I’m quite sad to see this project as it demonstrates that Go is starting to lose many of the characteristics that attracted me to it in the first place.

(For some context, I know quite a bit about functional programming and formal type theory, having studied the latter in grad school. It is intrinsically very interesting but I believe it is a net negative in most software engineering contexts.)

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 literally zero but I bet it's statistically-significantly fewer than all of them.

For example: this entire HN thread. And all the other libraries you mention that keep soliciting conversations, nerd sniping people who could be spending that time making better products instead of quibbling over FP code golf. But maybe those folks will always find things to quibble over...

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.

Exactly, the place for FP was and always will be academia.

Real programs require real, readable logic.

I also like using generics for API request/response code, ex: https://go.dev/play/p/OWf9eFmg1qF

With generics you don't need to return any/interface{} / type assert at runtime

    func Request(req, resp any) error {
        // send request (http, etc)
        b, err := json.Marshal(req)
        if err != nil {
            return err
        }
        log.Printf("sent request %+v - %s", req, b)

        // read response
        if err := json.Unmarshal([]byte(`{"success": false, "error": "invalid login"}`), resp); err != nil {
            return err
        }

        return nil
    }

Is there some other established Go library that contains these collections/containers?

1. To look clever.

2. To make junior programmers look stupid.

A pragmatic systems programming language with garbage collection and good support for functional programming already exits. Its called Ocaml and really deserves more love.

https://grugbrain.dev

   public abstract class Option[T] implements Iterable[T] { }

   // Some then is a one element Iterator/ None is an empty iterator

   // With for you then can do something on Some
   // orElse left as an exercise to the reader
   
   for (String name: option) {
      // do something with name
   }

For Go I think something like Zigs !i32 would fit in perhaps, if one wants a higher level of error handling.

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.

Not an expert in Go but I think you can do this:

   func compose[A any, B any, C any](a func(A) (B, error), b func(B) (C, error)) func(A) (C, error) {
      return func(aInp A) (C, error) {
        res, err := a(aInp)
        if err == nil {
           return b(res)
        } else {
           return *new(C), err
        }
      }
   }

The bind operator (>>=) can be implimented in terms of composition:

   func bind[A any, B any, C any](a func(A) (B, error), b func(B) (C, error), aInput A) (C, error) {
      return compose[A, B, C](a, b)(aInput)
   }

From my experience, "handling" the error means wrapping it in another error and returning, which is what you get from other languages for free.

You can if A is a function which takes two arguments, e.g.

  package main

  import "log"

  func A(x, y int) { log.Printf("%d, %d", x, y) }
  func B() (int, int) { return 1, 2 }
  func main() { A(B()) }

And there are no slices or channels of tuples, return values must be destructured right away.

  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, T5, T6, T7, T8, T9, T10 any](f1 F1, f2 F2, f3 F3, f4 F4, f5 F5, f6 F6, f7 F7, f8 F8, f9 F9, f10 F10) func(T.Tuple10[A1, A2, A3, A4, A5, A6, A7, A8, A9, A10]) IOEither[E, T.Tuple10[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]]

1: https://github.com/scala/scala/blob/v2.13.11/src/library/sca...

"func CompareFunc[S1 ~[]E1, S2 ~[]E2, E1, E2 any](s1 S1, s2 S2, cmp func(E1, E2) int) int { "

Looks like Scala

Also yes it is awful.