Correct, see the github mirror[1]. I don't know how well supported that feature is compared to main branch. If it was completely stable, then it would have already landed in the main stable branch. Clarity about the roadmap of that branch would be nice.
It does, but the map has a reference to it, so it will "leak" (in gc languages an unwanted reference is considered a leak). If this map got rather large, you could end up with a rather large heap and it would be un-obvious why at first.
gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern.
Ignoring Postgres and comparing apples to apples, rqlite has limitations on "safe" SQL statements[1]. This might be a big deal breaker for you than it might for others. As dqlite replicates the pages and not the SQL statements over raft, which means dqlite doesn't have _that_ problem. Using random() and now() are classified as non-deterministic[2].
Using the application to send the time, although not idea could be used as a workaround, but attempting to use non-deterministic functions in triggers becomes a lot harder.
It depends what you call a deal. Are they new trade deals from scratch, absolutely not. Are they trade deals that have been copied from the EU trade deals to satisfy ongoing deals ("rollover" deals), yes they are. Are we getting the trade deals that Boris promised, absolutely not.
(parent post tried to abolish blame and called out the grandparent post as the issue, hence why the lack of continuation)
I don't, you messed up!
The fact that you're actually incentivising contributors to make PRs of any quality and without standards, whilst forcing the burden on to maintainers (without reward) and you do very little (no tutorials about how to make quality PRs, no standards information on what comprises of a good PR, no quality guidance what so ever!).
This seems like a marketing stunt that has backfired and you're saying that you don't deserve some backlash?
I feel the lack of additional type arguments on methods will be considered a mistake in the longer term. Although the way it's designed it can be added in additional revisions but considering it's taken rather a long time to get here, I don't hold much hope for it landing for some time.
Attempting to define a generic Map function turns out to be somewhat troublesome[1]. This would be really painless if you had type arguments, instead, we have to define an interface to allow peeping into the type and creating a type from a zero value.
Don't get me wrong, I do applaud the efforts for better type system, it's just a weakness in the proposal.
It really can (LXD cloud setup from personal experience), the problem is that if you don't serialise your writes then yeah, fun times to be had. There are compromises for all databases. People just like telling others their opinion as fact, and how wrong everybody is apart from themselves of course.
I find it disconcerting that you seem only to care about how dependencies are managed and that to me is superficial compared to the ideas and actions of the book and the code.
I used Dqlite for a side project[1], which replicates some of the features of LXD. Was relatively easy to use, but Dqlite moves at some pace and trying to keep up is quite "interesting". Anyway once I do end up getting time, I'm sure it'll be advantageous to what I'm doing.
1. https://github.com/adobe/avmplus