3 ms·

Wouldn't any of the Rust implementations be what you need (Yrs, Diamond Types or the Automerge rust re-write)? Given you can bind to a Rust implementation in JS

Wouldn't any of the Rust implementations be what you need (Yrs, Diamond Types or the Automerge rust re-write)? Given you can bind to a Rust implementation in JS or Python or whatever else.

simonw 3y ago
I want someone else to write the Rust-to-Python bindings for me because I'm lazy! More importantly, I prefer not to be the only user of something like this - a Rust-Python wrapper that someone else has already tried running in production is a lot more trustworthy than something I knock together myself.
- josephg 3y ago
  Bindings are relatively easy to write, test and run. The hard part is usually just keeping them up to date with API changes.
josephg 3y ago
This is certainly the direction most crdt libraries are headed. A fast, well tested rust implementation with native bindings to Python, go, c, java, etc. And a wasm bundle to run the same algorithm in the browser. Yjs (well, yrs), automerge and my own diamond types are all in rust and moving in this direction. Webassembly support amongst javascript bundlers has been getting a lot better lately. And having only one codebase to optimize and test cuts down immensely on work.
iudqnolq 3y ago
I've only looked into yrs. Unfortunately copying a js API into rust and using unsafe whenever you get a borrow check error feels doomed. > Currently we didn't have any known undefined behaviour bugs caused by [casting pointers we don't have exclusive access to to mutable references]. In the future we may want to adopt different way of working with blocks with more respect regarding borrow checker rules, but currently priority was compatibility with Yjs. https://github.com/y-crdt/y-crdt/issues/233#issuecomment-1368466733 https://github.com/y-crdt/y-crdt/issues/233#issuecomment-136... Edit: I've only played around with my own toy crdt implementations, but I think this is also completely unnecessary. Yrs has a whole transaction API for concurrently mutating the same document instance through a shared handle. Not only is it unsound but there are also a bunch of places that will just panic if called concurrently. But you can just structure your program differently. For example, you could have a single thread/task per document that all the clients connect to. That isn't to say yrs isn't impressive. It's quite good for someone's first rust project written all at once in a short period of time. But I don't think it's production ready, and I'm skeptical it's fundamental architecture can be.

Wouldn't any of the Rust implementations be what you need (Yrs, Diamond Types or the Automerge rust re-write)? Given you can bind to a Rust implementation in JS or Python or whatever else.

simonw 3y ago

I want someone else to write the Rust-to-Python bindings for me because I'm lazy! More importantly, I prefer not to be the only user of something like this - a Rust-Python wrapper that someone else has already tried running in production is a lot more trustworthy than something I knock together myself.

josephg 3y ago
Bindings are relatively easy to write, test and run. The hard part is usually just keeping them up to date with API changes.

josephg 3y ago

This is certainly the direction most crdt libraries are headed. A fast, well tested rust implementation with native bindings to Python, go, c, java, etc. And a wasm bundle to run the same algorithm in the browser. Yjs (well, yrs), automerge and my own diamond types are all in rust and moving in this direction. Webassembly support amongst javascript bundlers has been getting a lot better lately. And having only one codebase to optimize and test cuts down immensely on work.

iudqnolq 3y ago

I've only looked into yrs. Unfortunately copying a js API into rust and using unsafe whenever you get a borrow check error feels doomed. > Currently we didn't have any known undefined behaviour bugs caused by [casting pointers we don't have exclusive access to to mutable references]. In the future we may want to adopt different way of working with blocks with more respect regarding borrow checker rules, but currently priority was compatibility with Yjs. https://github.com/y-crdt/y-crdt/issues/233#issuecomment-1368466733 https://github.com/y-crdt/y-crdt/issues/233#issuecomment-136... Edit: I've only played around with my own toy crdt implementations, but I think this is also completely unnecessary. Yrs has a whole transaction API for concurrently mutating the same document instance through a shared handle. Not only is it unsound but there are also a bunch of places that will just panic if called concurrently. But you can just structure your program differently. For example, you could have a single thread/task per document that all the clients connect to. That isn't to say yrs isn't impressive. It's quite good for someone's first rust project written all at once in a short period of time. But I don't think it's production ready, and I'm skeptical it's fundamental architecture can be.