either
exceptions
either | exceptions | |
---|---|---|
3 | 1 | |
443 | 48 | |
4.3% | - | |
7.3 | 5.4 | |
23 days ago | 13 days ago | |
Rust | Haskell | |
Apache License 2.0 | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
either
-
What's the deal with Error Handling - Custom Error enum and the different libraries out there.
Restricting what can go into a Result in the error variant is quite restrictive. It's often very convenient to use Result as a sort of "this or that" type without any connotations about errors, particularly as an internal convenience. Arguably one might want to use either instead, but it's a lot of ceremony to bring that in for simple use cases.
-
Is there a RFE for this feature and if so, what is it called?
P.S. you can use either to make it work on stable rustc
-
Ask HN: Would you support government open source grants?
The European Union does not have as large a software industry as the USA so there would be a less strong argument of government/corporate competition. It could take the form of government grants depending on the size. My rationale is that governments benefit from the general prosperity of open source more so than solo authors or small companies.
I am restricting the scope to simple and small libraries where investment is more clearly beneficial unlike Tensorflow as that is large and complex.
Here is an extreme example, the 'either' crate is a 'rayon' dependency and many others. Paradoxically a project of this size likely does not need funding but it is really important.
https://github.com/bluss/either
exceptions
-
Async Control Flow
I see. Do you think rethrowing the original exception is the the right approach in all cases, or only in this case? In the documentation I wrote for the exceptions package, I recommend to let the release block's exceptions take priority, to match base's behavior. Should I recommend the opposite?
What are some alternatives?
distributed-process-platform - DEPRECATED (Cloud Haskell Platform) in favor of distributed-process-extras, distributed-process-async, distributed-process-client-server, distributed-process-registry, distributed-process-supervisor, distributed-process-task and distributed-process-execution
either - the EitherT monad transformer
tauri - Build smaller, faster, and more secure desktop applications with a web frontend.
control-monad-exception - Explicitly Typed exceptions as a library
categories - categories from category-extras
failure - A simple type class for success/failure computations.
recursion-schemes - Generalized bananas, lenses and barbed wire
streamproc - Haskell library providing a continuation-based stream processor arrow
control-monad-omega - A Haskell monad for fair enumeration of infinite sets.
record - Anonymous records
hask - Category theory for Haskell with a lens flavor (you need GHC 7.8.3, not 7.8.2 to build this!)