Horusiath

zero-copy implies zero copying, not "sometimes we manage to return slices instead of reallocating byte/string buffers".

1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics.

I was looking for something like that and eventually found Crystal (https://crystal-lang.org) as a closest match: LLVM compiled, strong static typing with explicit nulls and very good type inference, stackfull coroutines, channels etc.

Welcome to Pony: https://www.ponylang.io/

Last time I've checked none of the common reverse proxy servers (most importantly nginx) supported WebTransport.

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.

(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.

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

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 ;)

Can we make it work in Windows by any chance?

Mostly because of user experience. F# as .NET language has entire ecosystem of high quality libraries to pick from, good IDE support (not as good as Java/C#, but definitely better than Haskell) and smaller learning curve. It's also way more robust than Rust - meaning that you can make a working project with decent performance much quicker. I say that as both F# and Rust developer. IMO the language that covers similar area and may be more tempting to learn is Scala. But if you already know how to utilize .NET platform, then reusing that knowledge in F# is just easier.

Only if you're the only user of that API or these entities are eternal once created. In any application with multiple users it's a normal thing for system state to change between two API calls.

Midori was conceptually closer to what Pony lang offers.

No, it only proves that C# and F# are two different languages.

GraphQL was created at Facebook specifically for internal APIs.

AFAIK Facebook created GraphQL specifically for their gateway API - a service used as a facade between internal service mes(s/h) and their client - not for internal ones themselves. That's why things like schema stitching didn't came from FB - they weren't using it in that context.

Actually in F# computation expressions are way more powerful, as they can define their own "keywords" within given semantics. This is for example, how `query{}` computation expression works - and unlike linq it can support things like left joins natively just because entire sql-like syntax is defined by library, not hardcoded into language. Same for async, yield generators etc.

It's not described in the docs, but elswhere [1] in their github repository you can find the note about rga, which is Replicated Growable Array CRDT, that can be used for building indexed linear sequences - shortly speaking arrays of elements with insert/remove semantics.

[1](https://github.com/SyncFree/antidote/blob/842874ca5ecffe947e...)

This is not only a DB specific, a whole banking industry works like that. Systems that have <10 years are considered new ones. To keep things working, just produce 5x more services created solely to move data from one place to another. No focus on programming discipline or sense of purpose and constant fear to change anything, because that could break things and we have not enough tests or monitoring infrastructure to even detect that. But in finances, IT is not on a focus. After all, we're just a "cost center" ;)

OData - which was essentially LINQ over URL - was nice (but incomplete) idea with terrible realization. We've used it in two projects in the past and we've fallen back from using it in both cases:

- OData never got wider adoption outside (and even inside) MS. GraphQL is already adopted on every major platform.

- OData had shitton of documentation and format changes with every version. Backward compatibility not included. GraphQL has clear specification which is pretty stable since its first publication.

- OData queries had no validation. You could send almost every query just to get runtime response that your framework/library doesn't support that functionality - even if it was developed by Microsoft itself. On the contrary all major GraphQL server implementations have full feature support.

- Thanks to Introspection API GraphQL has self-descriptive metadata model, which is great for tooling and compile time query verification. Also versioning, schema and documentation are all included into GraphQL from start.

- And finally GraphQL focuses on exposing capabilities of your service into well defined format understood by frontend, not on exposing subset of your database to the user - like OData did.

It depends on the actual implementation of the server side, that you're using. From what I remember (this may have changed):

- Ruby implementation can dig into Active Record to perform batching of the queries, that normally would be executed in parallel.

- JavaScript implementation may use DataLoader library to support the same batching behavior for basically any async (promise-based) operation. See this presentation, it shows how the issue look like and how Data Loader helps to solve it: https://www.youtube.com/watch?v=c35bj1AT3X8&t=15m42s

- Python and Elixir implementations can make use of information about query subsegments, so you can prefetch necessary data.

- F# implementation works in similar way to Elixir but it's not limited to analyse GraphQL query fragments, but can also perform live analysis of the user-defined resolve functions code to determine a tree of used F# objects and properties instead. This allow to diverge GraphQL domain model from the underlying database model.

- A lot of other libraries are dedicated to particular database or query language and map GraphQL schema directly onto database model, so GQL query is translated directly into underlying database query model (including joins).

He is writing that statement from a perspective of engineer of high performance / low latency systems. If one uses that argument while developing N-tier "enterprise" application with huge ORM, DI and web framework on top of it... that's missing a point.

You have to inherit from Akka.net classes, which makes me very nervous from a testing standpoint.

How do classes make you nervous? Testing support is one of the strongest parts of akka (see Akka.TestKit) - you can even simulate things like networks delays or VM shutdowns.

Persistence still confuses me after reading it 5 times.

Yes for people not familiar with concepts of eventsourcing, Akka.Persistence can be enigmatic indeed. But you're not forced to do eventsourcing when using Akka.

Maybe it's time to look into JRuby backed by Truffle+Graal? These guys seem to make something really promising. See: https://www.youtube.com/watch?v=lRMWwjqbXUo

Your example is not zero-cost. You've simply traded program memory for CPU cycles. Not always fair trade in cases, where C is used.

WTF? You're moaning, that the systems programming language invented over 40 years ago has no means for automatic memory allocation management and high level abstractions. Sorry but this is just crappy post.