I'm quite productive in #rust now and for the most part it's a really pleasant experience. Until, that is, I have some thread/task that receives messages from some source and where I want to pass a custom handler (i.e. a callback function).
At that point, I completely stumble over lifetimes of the deserialized object I want to pass to my handler function and the type of the handler function argument. And, of course, it turns out it’s not a function – it's a closure! – because I need to capture the `Arc<RwLock<HashMap<Blurgh, Blarg>>>` that I'm going to update with what I learned from the message.
How do I learn to reason about this? 😩
Thing is, I *do* get it to work, but I don't really understand (or at least internalize) how this works, because the next time I'll stumble through this ”Sync! Send! fn! Fn!” dance again.
I'd be super happy to hear some recommendations on material that will help me get better at this – or any advice on the matter, really. 😌
@eh FWIW, the problem you’re hitting is challenging because it is hard to get both performance and correctness with threads. Most runtimes I’m using day-to-day “solve” this by functionally banning threads and making execution fully-deterministic (and, as consequence, sacrificing the potential performance multiprocessing allows).
If we want multiprocessing, we bundle the behavior into an entire queryable service and run it on multiple nodes. This is expensive both in terms of code labor (i.e. switching from a subroutine to an entire Dockerized service is more than a couple hours work) and overhead (now there’s a whole IPC framework in the loop, if not a network fabric).
I hear rumor Erlang simplifies this but I’ve never looked into Erlang closely enough to really know.
@mtomczak Yeah, true. In most cases I don't need the performance. My background is Erlang where you make that trade: The (single node/thread) performance isn't amazing, but the system as a whole can be very efficient. Maybe I can get the best of both worlds (ML-like type system and easy concurrency) when Gleam becomes more mainstream. :)