> In BoC, the equivalent of a message is received by multiple actors and operates with exclusive access to the message and all of the receivers.

(emphasis mine)

IIUC with actors, messages are processed by exactly one actor so it can be difficult to express transactions (e.g. transferring funds from A to B cannot be done atomically). Erlang somewhat fixes this with "selective receive" which re-introduces the possibility of deadlocks. BoC fixes both issues.

Both are rust/open-source/new/fast so it's difficult to understand why I should choose one over the other.

[0] https://dl.acm.org/doi/10.1145/1276377.1276438

Most arguments in the article boil down to "c++ has the reputation of X, which is partly true, but you can avoid problems with discipline". Amusingly, this also applies to assembly. This is _exactly_ why I don't want to code in c++ anymore: I don't want the constant cognitive load to remember not to shoot myself in the foot, and I don't want to spend time debugging silly issues when I screw up. I don't want the outdated tooling, compilation model and such.

Incidentally, I've also been coding in Rust for 5 years or so, and I'm always amazed that code that compiles actually works as intended and I can spend time on things that matter.

Going back to c++ makes me feel like a caveman coder, every single time.

- two 64-bits words representation

- fixed, 32 bits length

- short strings (<12 bytes) are stored in-place

- long strings store a 4 byte prefix in-place + pointer to the rest

- two bits are used as flags in the pointer to further optimize some use-cases

- nix, the command-line tool

- nix, the language

- nixpkgs with the general API/idioms (overriding, overlays)

- individual nixpkgs packages that sometimes deviate from common practices

- flakes (which I haven't properly looked into yet)

The Nix pills series [1] and nixpkgs documentation [2] do help a lot, but that is quite a lot to process.

[1] https://nixos.org/guides/nix-pills

[2] https://nixos.org/manual/nixpkgs/stable/

[1] https://en.wikipedia.org/wiki/Orthogonal_group#Canonical_for...

I always thought there was a kind of NP-flavor to the problems for which LLMs-like AI are helpful in practice, in the sense that solving the problem may be hard but checking the solution must be fast.

Unless the domain can accomodate errors/hallucination, checking the solution (by a human) should be exponentially faster than finding it (by some AI) otherwise there's little practical gain.

[1] https://ocaml.org/manual/5.2/bindingops.html

This is generally a good thing: the more you internalise the logic of borrow checking, the earlier you start thinking about "who owns what" instead of deferring the choice to later, which often ends up in a tangled mess of "incidental data structures" as it is sometimes called in the c++ world [1].

Of course in c++ this means you have to internalise this discipline the hard way, i.e. without the borrow checker helping you.

[1] https://isocpp.org/blog/2016/05/cppcon-2015-better-code-data...