3 ms·

If I'm allowed to make a critique, I'd say that the module doesn't look very much like Go. The (ab)use of generics and having every policy to its own package fe

If I'm allowed to make a critique, I'd say that the module doesn't look very much like Go. The (ab)use of generics and having every policy to its own package feel a little over-engineered. I might be slightly biased, because, not knowing about this project, I implemented half of the functionality in my own simpler module: https://git.sr.ht/~mariusor/ssm https://git.sr.ht/~mariusor/ssm

1oooqooq 3y ago
circuit breaks and a end point health dashboards are sure ways to be promoted above ic5 in most dysfunctionaly big companies. I've spend a lot of time ripping them out of java projects abusing those patterns for internal services, where service interruption was caused more by the delays from the circuit breakers than actual problems with the internal end points. but everyone who added them got promoted in the past. and on those companies, most java people are now go devs when they were retrained during the move to the clouds because then most tools were go or python.
jodah 3y ago
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: https://failsafe-go.dev/type-safety/ https://failsafe-go.dev/type-safety/
- mariusor 3y ago
  > allowed different parts of the API to be independent and composable while still ensuring that result types align I found that states are not really required to know anything about internals of the executed code. All that a policy needs to know if the next state is an error or not, that's all. I might have simplified the problem too much for my library to be useful in real life applications, but I still hold hope that a stateFn func(context.Context) stateFn is expressive enough for implementing the whole functionality. If I may make another suggestion, I found that for more complicated flows, it is useful to be able to build a graph. I have made a rough approximation of a toold for my project based on parsing the go sources and inferring a state diagram from it. You can check it here: https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd (Apologies for the lack of documentation, my work is much more recent than yours :D)

1oooqooq 3y ago

circuit breaks and a end point health dashboards are sure ways to be promoted above ic5 in most dysfunctionaly big companies. I've spend a lot of time ripping them out of java projects abusing those patterns for internal services, where service interruption was caused more by the delays from the circuit breakers than actual problems with the internal end points. but everyone who added them got promoted in the past. and on those companies, most java people are now go devs when they were retrained during the move to the clouds because then most tools were go or python.

jodah 3y ago

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: https://failsafe-go.dev/type-safety/ https://failsafe-go.dev/type-safety/

mariusor 3y ago
> allowed different parts of the API to be independent and composable while still ensuring that result types align I found that states are not really required to know anything about internals of the executed code. All that a policy needs to know if the next state is an error or not, that's all. I might have simplified the problem too much for my library to be useful in real life applications, but I still hold hope that a stateFn func(context.Context) stateFn is expressive enough for implementing the whole functionality. If I may make another suggestion, I found that for more complicated flows, it is useful to be able to build a graph. I have made a rough approximation of a toold for my project based on parsing the go sources and inferring a state diagram from it. You can check it here: https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd (Apologies for the lack of documentation, my work is much more recent than yours :D)