dock VS sled

Just some friendly feedback: from the page you've linked to and this post, it's a little confusing to figure out what this is and why I should use it over the native Docker CLI. The GitHub page is a little more informative - even adding a framing headline like "A tool for using Docker containers as environments" or "Dock is a thin wrapper around the Docker CLI that makes Docker environments seamless" above the screenshot on your landing page would probably go a long way to communicating what your tool does and who should care.

I'm adding tests around the newest subcommand in dock, which is a thin wrapper around docker to streamline the use of Docker in a "development" context (as opposed to a deployment context). I recently added the run subcommand for running a command in the newest build of a Docker container, which will have certain configurable shortcuts, like running the command with the local user's ID, bind mounting the local project directory, and "nesting" the Docker daemon.

Hi /u/benzaita, thanks for sharing. I'm working on a tool with similar functionality (dock), so it's interesting to see a different approach in the same space. The features and Why use dockerized are great breakdowns of the advantages of this approach, and points that I've often made or observed myself, so it's great to have lists of these points to reference.

a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well.

[0] https://github.com/spacejam/sled

- Dropbox [3] uses a similar approach but they talk about it a bit more abstractly.

Sans-IO is more documented in Python [4], but str0m [5] and quinn-proto [6] are the best examples in Rust I’m aware of. Note that sans-IO is orthogonal to deterministic test frameworks, but it composes well with them.

With the disclaimer that my opinions are mine and mine alone, and don’t reflect the company I work at —— I do work at a rust shop that has utilized these techniques on some projects.

TigerBeetle is an amazing example and I’ve looked at it before! They are really the best example of this approach outside of FoundationDB I think.

[0]: https://risingwave.com/blog/deterministic-simulation-a-new-e...

[1]: https://risingwave.com/blog/applying-deterministic-simulatio...

[2]: https://dropbox.tech/infrastructure/-testing-our-new-sync-en...

[3]: https://github.com/spacejam/sled

[4]: https://fractalideas.com/blog/sans-io-when-rubber-meets-road...

[5]: https://github.com/algesten/str0m

[6]: https://docs.rs/quinn-proto/0.10.6/quinn_proto/struct.Connec...

Sled uses bw-tree actually https://github.com/spacejam/sled/wiki/sled-architectural-outlook

There is a valid argument to be made for threads over async in a large percentage of use cases where async is considered the default. If this is what you are referring to however, I don't think they ever referred to async as completely useless: https://github.com/spacejam/sled/issues/1123.

Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.

I'm not sure what you need. Are these of any use? https://github.com/meilisearch/heed https://github.com/spacejam/sled

There is also Sled but as I understand it that is being reworked to use the author's new DB core Marble

There are some databases like sled/FlashDB designed to be embedded to other applications even bare metal microcontrollers. But I do doubt the potential bussiness value of a pure embedded database.

https://github.com/spacejam/sled

To add transaction support, you probably need a good understanding of how the memtable works in Log Structured Merge trees: