This has prompted me to look at how the Tor Project's Arti reimplementation is going. They've got way further along than I realised:
https://tpo.pages.torproject.net/core/arti/
https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...
Hosting onion services is apparently still a work-in-progress, though, and turned off by default.
I was already able to host onion services last year by using the crate directly. A few footguns related to flushing but it generally works as expected. I will however say that the code quality could be improved though. When trying to contribute, I found a lot of somewhat bad practices such as having direct file read/writes littered around without abstraction which made refactoring difficult (trying to add different storage/cache options such as in-memory only or encrypted)
Opting not to over engineer the solution with abstractions nobody asked for until you came along is the definition of best practice. something not being designed for any and all use cases doesn't make something bad practice. Reading and writing from a filesystem you always expect to available is more than reasonable. Modular code for the sake of modularity is a recipe for fizz buzz enterprise edition.
> along is the definition of best practice
Not disagreeing or agreeing, but "best practice" is probably one of the concepts together with "clean code", that has as many definitions as there are programmers.
Most of the time, it depends, on context, on what else is going on in life, where the priorities lie and so on. Don't think anyone can claim for others what is or isn't "best practice" because we simply don't have enough context to know what they're basing their decisions on nor what they plan for the future.
Letscage [0] is also using Arti to implement its privacy features.
[0]: https://github.com/letscage