It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either con

It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache! The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned. As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it. One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types. I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).