Trust me, you’re far from alone on that I personally alternate based on deadline and requirements. Rust has some really nice parts, but Go’s “it’s already done” standard packages is just amazing at times.
There’s a big range of things that the two languages cover, and since I typically interoperate via sockets (at least externally), it’s how I solve the problems. I actually dropped Python as a primary prototyping language in favour of Go a while ago; I write small (hacky/quick) utilities in Rust now (I went from Python to Lua to Go to Rust in that case).
IMO if you want to learn Rust well, build smaller things in it that speed up your work. Build them as a library + binary in the same crate, so you can merge the library into your binary or build a larger tool (eventually upgrading it).
I know, much of this is basic language learning advice/commentary, but I also struggled with the transition to Rust because I was so used to just knowing what I was doing in the other languages. (In my case Go is probably to blame for that because it is very intuitive, but it has massive gaps that make it so–like a total lack of generics in userland.)
I’d lean towards NoSQL options or triple stores, since most things like this tend to evolve a lot over the course of their lives. It’s really personal preference, and then what you can make perform.
Just remember that if you’re building a database, prototype with an existing one (embedded or external). If you need multiple users or crash resistance use an external database. Only build a new one if you can’t find a better option out there (I know people who use redis to prototype for this reason, and stick with it in development due to its capabilities). Re-inventing the wheel has its place, but you’re asking for additional development overhead each time you resort to doing it. (Now if only I could make myself realise that…)
I’d say look into CouchDB then, as it’s going to make your life a lot less complicated. It is by far not the only option, it’s just really easy to get working, and has all of the things you’re talking about as features. (Update database -> update view, but poll enabling stale views to prevent stalls.)
This could also be my Erlang bias, but I also tend to recommend RabbitMQ to people who need massive/complex queues with concurrency support. Don’t get me wrong, I’m sure at some point I’ll be recommending more and more Rust applications/approaches, it’s just that there’s a reason certain things are established, and until you actually try them out, or understand their patterns, you can’t really find a better way to approach it.