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.

> Waiting 200ms for the database + an additional 20ms for rendering

Those are pretty awful numbers. https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...

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

It's far from clear if tokio is not a dead end.

You can write low level code. Tier 1 platform list is very short however.

https://forge.rust-lang.org/platform-support.html

A huge win compared to C is fearless refactoring. Making changes to an existing codebase in C is a minefield. Refactoring in Rust is a breeze.

The relatively low portability of rust programs is definitely one of its largest shortcomings.

The point of Erlang is that it makes writing robust distributed systems easy and fast. The language itself is tiny.

Scala on the other hand is not remotely small and easy to understand.

Lots of companies (like us) use it as basically a replacement for C/C++. They just don't discuss it much.

Anyone needing that can also extract tikv's raft implementation. It's actually quite easy.

One plus is the best choice. Great hardware, reasonable price, up-to-date Android no horrible skins on top of stock.

C/C++ compiler will compile your code if it is correct. Rust will not compile code if it can detect that it will not work or it is not safe even though the syntax is correct. It can guarantee the program is memory safe (double free, user after free, null dereferencing, using uninitialized memory, array bounds checks).

This makes large refactorings so much easier. It also makes working on large projects with lots of people much easier.

A single repo can have lots of crates

> The only problem is that the compiler is very slow now, so it doesn't scale to large code bases

The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway.

Also they are putting quite a lot of work into making it faster. Before you get to that large code base it will be better.

This is like reading criticism of Erlang which we use. A bunch of people (the vast majority of which never shipped anything in it) have plenty of arguments against it, those of us that actually use it love it to bits.

Rust is productive, efficient and a joy to use. For things we required C/C++ before, we will be using Rust now.

Anycast is pretty standard.

> When you're doing voip you're doing so over UDP because TCP has far too much latency to be agreeable,

Lots of wifis, corporate especially block all UDP traffic. Sometimes they even block all non http/https traffic. Apps like Skype or Biocoded will find a way to route the call, but that can sometimes mean it has to go over https!

VOIP calls are very sensitive to intermittent connectivity.

Sometimes wifi will work in batches. No packets will get through for a few hundreds of milliseconds (or seconds), then they will get sent all at once.

Sometimes UDP traffic is blocked completely and the call has to get relayed over TCP. Now no packets can get dropped and you get delays due to retransmits.

Sometimes 3g/4g connection disappears because someone entered a building an overpass or passed a corner in a city.

Sometimes the sides of the conversation are far and the audio delay is high.

If any side of the conversation encounters a problem described above both will get a bad quality.

Because a Rust library is safer, equally efficient, faster to develop, easier to build and can expose a C interface.