Author here - yes, Failsafe-go definitely took some inspiration from Polly, but it also borrows ideas from the Failsafe JVM library [1]. Polly and Failsafe influenced each other back and forth over the years.
Author here - I do get this critique, and of course API design is subjective, but there was a rationale behind the design choices. Putting each policy in its own package allowed the API to be slightly more concise. And having the API use a generic to represent a function's result type allowed different parts of the API to be independent and composable while still ensuring that result types align. A bit more on that here:
While I didn't know Bob personally, he did he an impact on me.
Bob was the first person I looked up to as an open source engineer early in my career. I studied his code closely, and learned a lot from the way he was able to distill complex problems into beautifully crafted APIs. Those learnings, along with some of his principles of software design, shaped my own work, including in open source, to this day. When Bob went on to great success I was not surprised in the least. He was a great engineer and deserved to still be with us.
For anyone wondering if there is a set of Hazelcast like data structures and primitives that actually have safe, strong consistency (based on Raft consensus), check out Atomix:
There's nothing more detailed that I know of. Is there a particular feature area/comparison you're curious about? I can add a bit more detail.
> It's not apparent to me what the advantage of either interface is. In both situations I have to define a "lambda"
What I meant by this bit is that the user experience is different. Failsafe can be used with method references or lambda expressions [1], which are a nice, concise way of wrapping executable logic with some failure handling strategy. You cannot do this with Hystrix since all logic must be wrapped in a HystrixCommand impl, which cannot be implemented as a lambda.
> either seems acceptable.
Like anything, it just depends on what you want. If retries and general purpose failure handling, consider Failsafe. If request collapsing, thread pool management and monitoring, consider Hystrix.
Author here: fully agree. Blindly retrying an operation any failed operation could lead to cascading failures or system overload, which is what circuit breakers are intended to avoid. Generally, it's just good to think about which failures can or should be retried or recovered from and what recovery should look like. A tool like Failsafe just makes it easier, hopefully, to do what you think is appropriate for the situation.
As for which failure handling strategy is safer or what it means to fail safely, in my experience it not only depends on the use case but the type of failure. Certain exceptions, even in a networked application, can and should be retried or recovered from while others cannot. Sometimes retrying is good, sometimes preventing subsequent executions (via circuit breakers), sometimes falling back to an alternative resource. It's all based on the scenario.
Author here - We were aware of Maven Failsafe plugin (since we use it), but felt comfortable using the name anyways since Failsafe is an excellent description of what the library is about, it covers a different technical area than the Maven Failsafe plugin, and "Maven Failsafe plugin" is almost always referred to using that entire name whereas, hopefully, Failsafe will come to refer to this new library.
> I have a debit card, I don't need to carry anything else.
If your card hasn't been stolen (via a hacked merchant) and your account wiped out yet, consider yourself lucky. You might want to carry a credit card as your primary instead. When (and I do mean when) it is stolen, at least it's only credit instead of your bank account balance that is impacted (and which can takes weeks or more to get back).
But otherwise, Reason looks very cool. A nice mashup of technologies to create something that certainly looks more useful than the status quo. I hope this takes off, but I think the biggest challenge nowadays, even for good technology, is finding an audience amidst a plethora of choices. Technology, as always, is a popularity contest.
This, usually. It's fair to point out that very specialized clocks, such as Google uses with Spanner, can allow you to achieve some consistency without coordination/locks, but for pretty much anyone else the rule you stated very much applies.