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.
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.