2023/06/14/golang-focus-on-the-happy-path-with-step-functions/

[utterances-bot]

Focus on the Happy Path With Step Functions · Preslav Rachev

I am a software engineer with a decade-long experience developing software using Java, Go, and Elixir.

https://preslav.me/2023/06/14/golang-focus-on-the-happy-path-with-step-functions/

[christophberger]

By taking generics out of the way, I hope to make it more appealing to a larger group of Go applications.

This is an interesting statement. Have you observed that the presence of generics hamper the adoption of packages or coding techniques?

[Skarlso]

Nice, very interesting. this largely similar to the Errors are just Values pattern posted by Rob Pike back in 2015 -> https://go.dev/blog/errors-are-values

Works great with functions of similar signature. :) Honestly, this might be better than constructing daisy chains.

[lunemec]

Interesting idea, however how are you going to pass values between the step funcs? This example is too small to show any real complexity.

I think trying this on something that has some actual logic where you also want to debug, log, trace, things depend on one another, and so on, would show if it is feasible or not.

[thefuga]

Why not call it for what it is: a chain of responsibility? This has been around for ages. Back to the thread, it's a shame that the average gopher don't like design patters. As you've mentioned, there are places where this works wonderfully.

[preslavrachev]

Interesting idea, however how are you going to pass values between the step funcs? This example is too small to show any real complexity.

@lunemec This is what you need the steps struct for. It is your value carrier (you can also think of it as scratch space that you read or write from). In more practical terms, when I end up implementing a step function, the steps struct usually has a few attributes that are expected by all "steps" (e.g. db, mailer, etc.), and also, a tmp attribute that is also a struct. This one is my scratch space. I use it to store intermediate values between steps there.

I admit that this isn't pretty, but it solves the problem of not having to use reflection, or some other methods that may fail in runtime. If you are interested in checking out a slightly different approach that uses generics, you are very welcome to read my preceding article: https://preslav.me/2021/09/04/generic-golang-pipelines/

[lunemec]

@preslavrachev ah! I didn't notice that part, OK then that is cool. Thanks for the other link, pipelines were exactly what I was thinking, and you could potentially use this + channels to be able to run some steps concurrently (like i/o steps).

[ObsidianCat]

A gist with actually runnable implementation of this idea. https://gist.github.com/ObsidianCat/2be44ef1426434ca706384bc2ae7a40e