biokoda

Schemas are per actor type and you can have many types. Actors are active or inactive. When you run a query against one, when it becomes active it will check if schema has changed and apply that before processing any query.

From that point of view yes you are right. There is a ton of nuance in CAP. Usually in these discussions the CAP question is if it is eventually consistent or not.

It's raft; thus firmly CP.

Yes a user space thread pool which is what node.js does on top of libuv.

History has proven that anyone no matter their abilities is going to shoot themselves in the foot regularly while using C. Some just less frequently.

> Depending on how you define "big changes".

The way every reasonable person would. This release being the obvious example.

That is entirely untrue. Releases are regular, big changes are anything but.

> Well, someone probably said the same about Go or React-Native when they first came out too

RN came from a giant company that uses it in its core product. Big difference.

Yes SQLite with type check constraints.

io_ syscalls only really work on XFS and require O_DIRECT which means kernel is not caching anything. Unsuitable for web servers.

Changing the number of cores given to a VM is not so uncommon.

> There's no middle ground.

Not at all. This is what the ? operator is for (was try! before).

The idiomatic rust way is to have your own Error type that implements From for other Error types that you may encounter (io::Error, Utf8Error, etc.).

Then you can simply just write let result = dosomething()?; for any operation that may fail. If an error happens, function will return with the error.

I don't think you can do it any cleaner, given the constraints Rust is operating under.

Overly complicated