rusty-editor VS sapling

The widget will be a "workhorse" in the rusty-editor , there are lots of places where it could be used:

If you like the project, please consider to make a donation: https://github.com/rg3dengine/rusty-editor or https://liberapay.com/mrDIMAS or https://www.buymeacoffee.com/mrDIMAS

If you want to give it a try the editor is for the library is at https://github.com/mrDIMAS/rusty-editor

The level is built in rusty-editor - https://github.com/mrDIMAS/rusty-editor

The headline times are a bit ridiculous. Are they trying to turn https://github.com/facebook/sapling/blob/main/eden/fs/docs/O... or some git fuse thing into a product?

You might be interested in how this problem was solved by our team at Meta, in EdenFS (https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...) and Watchman: https://github.com/facebook/watchman.

What you're describing is reasonably similar to EdenFS, except EdenFS runs in userspace.

Watchman layers a consistent view of file metadata on top of inotify (etc), as well as providing stateless queries on top of EdenFS. It acts as a unified interface over regular filesystems as well as Eden.

Back in the day, Watchman sped up status queries by over 5x for a repo with hundreds of thousands of files: https://engineering.fb.com/2014/01/07/core-infra/scaling-mer... I worked directly on this and co-wrote this blog post.

In truth, getting these working was a very difficult systems problem with a ton of event ordering and cache invalidation concerns. For smaller repos, it is much simpler to do linear scans. Since it is really fast on modern hardware anyway, it is also the right thing to do, following the maxim of doing the simplest thing that works.

It's not really anything like Mercurial anymore. It superficially resembles "hg" but it's a very hacked fork. It's more like sappling. https://sapling-scm.com

How does this compare to sapling? https://github.com/facebook/sapling

Coming from a Meta background (not speaking on behalf of Meta):

"package/dependency management" - Everything is checked into a monorepo, and built with [Buck2](https://buck2.build/). There's tooling to import/update packages, but no need to reinvent pip or other package managers. Btw, Buck2 is pretty awesome and supports a ton of languages beyond python, but hasn't gotten a ton of traction outside of Meta.

"linting, formatting" - [Black](https://github.com/psf/black) and other public ecosystem tooling is great, no need to develop internally.

"why is type checking the exception" - Don't know about Astral, but for Meta / Google, most everyone else doesn't design for the scale of their monorepos. Meta moved from SVN to Git to Mercurial, then forked Mercurial into [Sapling](https://sapling-scm.com/) because simple operations were too slow for the number of files in their repo, and how frequently they receive diffs.

There are obvious safety benefits to type checking, but with how much Python code Meta has, mypy is not an option - it would take far too much time / memory to provide any value.

Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling

Sapling is actively developed, not "dead after 3 months": https://github.com/facebook/sapling/commits/main/

Have not tried building Buck2 (no personal use for it), but its also actively developed: https://github.com/facebook/buck2/commits/main/

https://github.com/facebook/sapling/tree/main/eden

I'm still unsure if a complete, viable eden solution was released with all of its necessary components.