If that's the case there's libsql (https://github.com/tursodatabase/libsql) which already provides HTTP clients, embedded replicas (essentially good old SQLite but with replication support), self-hosted SQLite server and is maintained by a company using it for their own product.

Most of these points are related to strict type system. If that was the case, then Lisp wouldn't be functional programming language.

IMO the first and foremost principle of Functional Programming languages is that they are optimised around building programs in terms of function composition. And anyone who had to work with borrow checker and closures for 5sec knows, that this is not the case for Rust.

I think you've taken it backwards. The comment you were replying to is listing features that lead to robustness (many of which appear in strongly-typed functional languages in the ML family), not essential aspects of functional programming languages.

Indeed. I was listing the specific items the article (titled 'Why is F# code so robust and reliable? ') lists. Functional programming languages only came up to reject someone suggesting Rust as a language that can be included as robust/reliable in the context of the article's reasons for F# being robust/reliable

Lisp is a family of languages, most of which are not functional.

> (5-10x slower last I checked)

This was a thing around 2 years ago. Nowadays speeds is the same or in favor of Rust, depending on the benchmark in question.

It was still much slower ~6 months ago when I benchmarked it. I’ll rerun my benchmarks and confirm one way or another.

Oh amazing - it looks like the GP commenter is right. Yrs is significantly faster now than it was when I benchmarked it a few months ago. I'd update my comment above, but its too late.

For example, in one of my tests I'm seeing these times:

Yjs: 74ms

Yrs: 9.5ms

That's exceptionally fast.

This speedup seems to be consistent throughout my testing data. For comparison, automerge takes 1100ms to load the same editing history from disk, using its own file format. I'd really love to see automerge be competitive here.

(The test is loading / merging a saved text editing trace from a yjs file, recorded from a single user typing about 100 pages of text).

Yrs (Yjs on Rust) maintainer here: we actually had some idea about building extension to Postgres ;) Great to see that others share the excitement about this idea as well. See: https://github.com/y-crdt/y-crdt/issues/220

perfect, we'd love to collaborate with you. I'll jump into your github after our Launch Week (this week), or feel free to reach out directly (contact details in my bio)

I really hope plv8 maintainers can finally ditch v8 And pave the way for using yjs in all tits glory.

Unfortunately, v8 basically is a bloated mess and postgres just stopped supporting it cause it's build process is horrendous.

Yjs is being quite heavily used in the industry[1], and being researched by even more companies. There are also demos showing how to integrate it with an existing rich text editors[2]. If you have some ideas about the missing parts, you could also open topic on discuss.yjs.dev - the documentation page (https://docs.yjs.dev) has tons of useful links thou.

Re. other purpose projects - Yjs/Yrs main target are sequential data structures (text, arrays), but it also has support for maps and xml-like elements. In general you can build most data structures with it. I agree that it would be nice to have some other applications in demos though.

[1] https://docs.yjs.dev/yjs-in-the-wild [2] https://github.com/yjs/yjs-demos

I've described this issue in my blog post together with CRDT variants that address and solve it: https://bartoszsypytkowski.com/operation-based-crdts-arrays-...

In practice, many CRDT libraries nowadays (eg. Yjs and Automerge) are using structures that don't come with interleaving issues.

> semantic data-structures like rich-text or syntax trees is what's tricky and has unsolved challenges.

Yrs developer here:

- Yjs/Yrs have support for formatting attributes[1]. The matter if format attributes conflict resolution behaves as user desired is a subject to discussion (which is a common thing re. CRDTs and their trade offs), but its behaviour is consistent, convergent and algorithm itself works fast. This feature is in fact used in many rich text editors using Yjs bindings.

- Embedding non-string elements in text is supported as well.

- While syntax trees are not supported out of the box (AFAIK this CRDT is still being researched), Yjs also support XML nodes with attributes and nested children, which may be used for similar effects in some scenarios.

[1] https://docs.yjs.dev/api/delta-format

I'm one of the maintainers of this project: we're happy to hear some constructive feedback and proposals for improvements, so please don't hesitate to speak your mind at github issues: https://github.com/yjs/y-crdt/issues .

The internals are still very hot and in a state of flux, as we 1st decided to go with porting the Yjs, then leave cleaning and optimizations for 2nd step after we have something, that's compatible with existing Yjs behavior.

It targets the properties that Aeron protocol aims for too (https://github.com/real-logic/aeron).

Blog author here: as weird as it sounds, I have a prefetched Power Point template with color palette and settings, and I'm just using it for all presentations and diagrams ;)

Thank you, I will see what I can create using LibreOffice.