You were referring to callback-based interface that you planned on using but ended up with something different. I am curious on what your new, rust-y solution was :)
Oh, that's an excellent question! I moved on to what is called the "type-state pattern", which is basically a glorified application of state machines using enum types and pattern-matching.
I realized that the event-based mindset that I was so accustomed to in JavaScript isn't exactly applicable—or dare I say "idiomatic"—for what I was trying to achieve. The shift from a push-based model (using events) to a pull-based model (via polling the state machine) was a vastly simpler and cleaner solution than whatever I hacked together initially with interior mutability patterns. The push-based model was simply too prone to issues regarding concurrent mutable borrows. This, I realized, thanks to the type system.
Thanks for a well-written and informative article (and many others too)! I would love to see another that digs into this journey, where you explore how a push-based/callback mindset painted you into a corner in Rust and how you got out of there by the means you alluded (possibly idiomatic, pull-based, polling, etc.). In general, push- and pull-based interfaces are duals, so I am curious how the latter might be more conducive to a better design in Rust than the former. I hope you get round to it.
First of all, thank you for such valuable feedback! It's not often that I receive comments that request for greater details on a topic I brushed over. 😅
I would love to see another that digs into this journey, where you explore how a push-based/callback mindset painted you into a corner in Rust and how you got out of there by the means you alluded.
To make a long story short, I did in fact end up with polling-based state machines instead of event-based callbacks. Rust's type system really made it easy to encode the state transitions. In particular, enums and the type-state pattern were instrumental here.
But then again, I can go on and on about that in a future post. Thanks for the suggestion! I will make sure to give you a mention there.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So, what was the solution to the callback problem?
Apologies, but I'm not quite sure what you're referring to. Care to elaborate?
You were referring to callback-based interface that you planned on using but ended up with something different. I am curious on what your new, rust-y solution was :)
Oh, that's an excellent question! I moved on to what is called the "type-state pattern", which is basically a glorified application of state machines using
enumtypes and pattern-matching.I realized that the event-based mindset that I was so accustomed to in JavaScript isn't exactly applicable—or dare I say "idiomatic"—for what I was trying to achieve. The shift from a push-based model (using events) to a pull-based model (via polling the state machine) was a vastly simpler and cleaner solution than whatever I hacked together initially with interior mutability patterns. The push-based model was simply too prone to issues regarding concurrent mutable borrows. This, I realized, thanks to the type system.
Thanks for a well-written and informative article (and many others too)! I would love to see another that digs into this journey, where you explore how a push-based/callback mindset painted you into a corner in Rust and how you got out of there by the means you alluded (possibly idiomatic, pull-based, polling, etc.). In general, push- and pull-based interfaces are duals, so I am curious how the latter might be more conducive to a better design in Rust than the former. I hope you get round to it.
First of all, thank you for such valuable feedback! It's not often that I receive comments that request for greater details on a topic I brushed over. 😅
To make a long story short, I did in fact end up with polling-based state machines instead of event-based callbacks. Rust's type system really made it easy to encode the state transitions. In particular, enums and the type-state pattern were instrumental here.
But then again, I can go on and on about that in a future post. Thanks for the suggestion! I will make sure to give you a mention there.