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 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.
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 things like tail call optimization.
There's better languages than Go if you want to / have to do functional programming.
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.
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.
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"
> 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.
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 "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.
Okay, let's do it. ISTM you started the ad hom with loose accusations of people reading blog posts, ignoring that many people actually have solid commercial experience with it and are being "actually being productive" with it, nor did you justify your view they were "productivity sinks", so I couldn't take you seriously.
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.
I tend to agree. I’ve done a lot of JS and Python where I end up spending time doing functional tricks basically just because I’m bored and it makes things interesting. With Go when I’m bored I start profiling and making a zero alloc version of a function that only runs once a week.
Love expression-oriented pseudo-FP (F#, Scala, Rust), but I think this recent trend of trying to shoehorn Haskell-lite features into mainstream imperative languages is, to put it gently, extremely awkward.
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!
totally agree, for me golang is a strongly imperative language and that's ok. I'm willing to be proved wrong, but I would imagine if you want to do functional programming it's going to be a lot easier to just use a different language.
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.
I've always had a hard time breaking into FP paradigms. The basic tutorials feel a bit like math proofs and it's hard to connect the ideas into things I'm actually doing.
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.
It's an interesting exercise, but this library doesn't fit well into the Go ecosystem's habit of writing straightforward, imperative, boring, verbose, simple-to-read code. Even as someone who likes FP tools, I won't be using this.
I'm glad to see this idea getting some traction again. I haven't used Go much in the last few years, but I started playing around with a similar idea back in 2016 when I was working on a small compiler for a configuration management tool, and later put together a small stand-alone proof of concept library(https://github.com/rebeccaskinner/gofpher) as part of a talk (https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...) I gave in 2017.
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.
Seriously, why? The only compelling argument for monadic effect systems I see is in languages with no easy-to-use and lightweight concurrency, and this is where Go shines. I thinks this is cool and all but I don't think it can ever be justified with this added complexity in Go. I have worked much with Cats Effect in Scala, which is nice but it adds some serious cognitive overhead.
One of the design aspects is to make a distinction between functions with and without side effects (pure). In a way to tell these apart by looking at the function signature without having to read the function body.
The library uses a function signature without an input but with an output for this purpose. Aside from the trivial case of a constant function, such a signature can only mean that the function has side effects.
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 looks like a pain to modify if you're not intimately familiar with the fp-go library and are just trying to insert a debug statement. Also, the passing two values in parallel via a chain of functions seems really brittle.
The real cheat of examples like this is using only existing functions. Once you add a closure with current Go syntax it goes to 11 on the hideous.
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).
I agree that the code will become unreadable as soon as you try to use inline functions (since there are no lambda expressions).
However, the fp style (independent of this library) encourages to decompose the codebase into small and - if possible - pure functions. For testability.
Once the code is structured that way, it's no longer a `cheat`, these pure functions can be used right away in function composition to create more complex structures.
It is very probable that data is an Either[Error, Result]. So you are forced to handle the error.
You could also probably add a mapLeft and deal with an error at every step of computation.
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
The example actually does handle all errors, because the values are of type `Either` and the composition functions take this into account.
If you would like to handle a particular error sitation explicitly, e.g. to enrich it with context or to transform one error into another, you may use `MapLeft` or `Swap`.
Unfortunately there is no way to use variadic arguments in a type safe way in go (yet) - except for the special case that all arguments are of the same type.
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.
It feels like they buried the lede, because the referenced Go code is horrendous. I'd be afraid to put that on the front page of my repo, too, if my library lead to code that reads/looks like that.
Not picking sides here (though disclosure: I use and like FP techniques/tools/languages/libraries).
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.
Because in some cases the aspect whether or not the language is functional is not the only decision criteria for the choice of language. If it was, I would absolutely recommend to consider a language than go.
But if go is selected because of different criteria (i.e. interoperability with an existing eco-system, cross compilation support, FIPS compliance, ...) then this library can help to apply fp paradigms in you go code. Hopefully to make it readable and testable.
As much as I like the functional paradigm, I don't think it will work well on Go due to two simple reasons:
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.
1) I would argue that with fp style you might want to structure your code into small, pure functions, anyway, for testability reasons. Also many functions from the go library are already pure functions with one input and one output, so they can be used right way, e.g. `Atoi` from `strcov` or `ToUpper` from `strings`.
Also go has the nice feature that you can pass methods on structs (member functions) from their instance as functions (the instance reference is bound in a closure). So lambda functions are not really needed that much
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.
Was just scrolling through the docs. Does anyone feel comfortable with all these generic type annotations? I'm not expert programmer but this looks overkill to me.
This is also one of my favorites, but it can get even more verbose. However this is how the go type system is designed to work with covariance. Without the `~` operator these functions could only be used for a much smaller range of inputs.
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.
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)
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.
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.
> 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.
> 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.
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.
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.
>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.
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.
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).
I think a compile to Go approach would have been better. It would allow bypassing most of the warts and still potentially allow interoperability with existing Go code. It would also likely be better received as it would be clear that this is not supposed to be Go.
This library could be only useful if someone trying to build new Programming Language with its own ecosystem with Golang runtime as backend, like for example Scala on JVM. In upcoming versions Go 1.22 they are also improving code inlining support, so that might help.
Trying to merge this abstractions and patterns with existing Golang's philosophy and community libraries is simply a case of over-engineering.
I hope this remains just a curiosity that showcases a fascinatingly bad idea, rather than that anyone out there thinks that this is a good idea and start depending on it.
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.
Indeed, this was the exact stuff that I loved not having to deal with in Go: architecture astronauts pushing their code golf on everyone else.
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.)
"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 literally zero but I bet it's statistically-significantly fewer than all of them.
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: 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...
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.
I've ended up using at least a half dozen generic helpers in every application I've written since they were added. They've made my coding easier, more concise, and help with testing. Adding generics to Go was well-founded.
AIUI, Go intentionally avoids programming language features considered too advanced by its authors in order to lower the bar (to make it easier for most programmers to pick up, that is) and to keep the code uniform, supposedly to the advantage of companies using it. While hammering unidiomatic approaches into a language virtually always is awkward: there are other libraries and programmers, even if you are fine with the rules you have to follow in order to emulate the desirable features using a library. The combination of those things looks even stranger than they do separately.
The issue they link for semantic-release is hilariously baffling to me. It seems they don't support keeping a project at 0.y.z per semver because "you should just dev up to 1.0.0 faster bro" and "we know better than you bro".
cool exercise but its ultimately lubing a square peg to fit in a round hole.
A pragmatic systems programming language with garbage collection and good support for functional programming already exits. Its called Ocaml and really deserves more love.
I think map() is useful, even if it does not look like Go and rubs a little against the sprit of simplicity of Go. Wish the for loop in Go would return a result, which could accomplish the same but would be a little bit more Go like
x := for y := range z { return y } // unclear return :-(
If you want Either, use Haskell.
There seems also to be a performance problem with map(). It would work better if Go had Iteration instead of slices, otherwise map() creates a lot of slices. And if map does not return a slice you have an ugly
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 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
}
but today I think one should embrace the language and if it does not work for you, use something else.
For Go I think something like Zigs !i32 would fit in perhaps, if one wants a higher level of error handling.
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.
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.
Either as a pattern is _used_ everywhere, but the standard library in go doesn't have one (people just use a tuple), so it's _always_ encoded wrong. It's very annoying.
There is no tuple type in go. When you see a func() (A, error) that is not a function returning a tuple. It is a function returning two values that cannot be composed. You can't A(B()) if B returns two values. It's pure comedy.
I didn't look too much at this but are they offering an alternative to the (IMO ugly) error checking pattern Go enforces? It's interesting to me shoehorning this into Go in particular. Go is notoriously stringent on how you write code.
Never thought I’d see these three things together. The library looks extremely well done, although I’d expect some interesting reaction as Go is as imperative as it gets.
As a Rust guy, I disagree. For one, Rust does not have lazy evaluation, just like C which is why I raised the point C is incompatible with FPP. Lazy evaluation in C (and Rust) can be emulated by function pointers (and closures), but it is not easy to use
Ultimately it is, but I guess my point is that having goofy signatures like these down in the bowels of a library (like FP-Go, or Scala's stdlib) might just be necessary goofiness because FP is FP. (Not to knock FP. Engineering is about tradeoffs.)
I don’t know who to feel more sorry for: the junior programmer who has dutifully taught themselves idiomatic go and explicit error handling being shown a large unreadable codebase full of this nonsense on their first day, or the the poor sods having to tear this nonsense out of a large tangled codebase in three years time.
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/