https://github.com/kdungs/go-result

Result types for Go; because (T, error) can be considered a ✨ monad ✨.
https://github.com/kdungs/go-result

experiments functional-programming go golang monad

Last synced: 8 days ago
JSON representation

Result types for Go; because (T, error) can be considered a ✨ monad ✨.

• Host: GitHub
• URL: https://github.com/kdungs/go-result
• Owner: kdungs
• License: mit
• Created: 2023-04-13T22:16:57.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2023-05-11T17:52:25.000Z (over 1 year ago)
• Last Synced: 2024-06-21T16:52:54.726Z (6 months ago)
• Topics: experiments, functional-programming, go, golang, monad
• Language: Go
• Homepage:
• Size: 78.1 KB
• Stars: 1
• Watchers: 2
• Forks: 0
• Open Issues: 3
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# Result types for Go

_Because `(T, error)` can be considered a ✨ monad ✨._

> Your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should!

Imagine Go code without `if err != nil`. Would this be sacrilege? You might think so. For me, it was a fun exercise to get to know Go generics. Don't try this ~~at home~~ in prod.

The central idea is to treat `(T, error)` as a monad. There are two separate packages that implement this idea in different ways:

1.  [`package result`](result/) exposes a dedicated type `R[T]` that wraps `(T, error)`. On top of that, it implements functions to perform computations on `R[T]`. Since Go does not have generic member functions, those are free functions.

2.  [`package then`](then/) offers functionality to (lazily) compose functions that return `(T, error)`.

There's actually an [ongoing discussion around how to improve error handling in Go 2](https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md).