It could probably be argued that this is simply acknowledging reality, and that C++ lets you get away with murder if you want to. But maybe that’s what I want.

I think a good feature for C++ would be a “safe” (or “verified”?) block or method decorator that could enforce some set of restrictions on semantics, e.g. single mutable borrow. The problem is that those functionalities are part of the compiler APIs and not standardized.

The Rust compiler is also not standardized, but they can get away with it.

So, in interest of matching this code I wrote an example of spawning 1_000_000 processes that each wait for 3 seconds and then exit.

This is Elixir, but this is trivial to do on the BEAM and could easily be done in Erlang as well:

    #!/usr/bin/env elixir
    
    [process_count | _] = System.argv()
    
    count = String.to_integer(process_count)
    
    IO.puts "spawning #{count} processes"
    
    1..count
    |> Enum.map(fn _c ->
      Task.async(fn -> 
        Process.sleep(3_000) 
      end)
    end)
    |> Task.await_many()

    » time elixir --erl "+P 1000001" process_demo.exs 1000000
    spawning 1000000 processes
    
    ________________________________________________________
    Executed in    6.85 secs    fish           external
       usr time   11.79 secs   60.00 micros   11.79 secs
       sys time   15.81 secs  714.00 micros   15.81 secs

Ultimately, although imo the BEAM performs quite well here, I think these kind of showy-but-simple tests miss the advantages of what OTP provides: unparalleled introspection abilities in production on a running system. Unfortunately, it is more difficult to demonstrate the runtime tools in a small code example.

It comes down to the kind of lock being used. Scenarios which require strict data sharing handle them as they see fit - for recoverable states the lock can simply be released in a `finally` block. Synchronous/blocking `lock` statement does this automatically. All concurrent containers offered by standard library either do not throw or their exceptions indicate a wrong operation/failed precondition/etc. and can be recovered from (most exceptions in C# are, in general).

This does not preclude the use of channel/mailbox and other actor patterns (after all, .NET has Channel<T> and ConcurrentQueue<T> or if you would like to go from 0 to 100 - Akka and Orleans, and the language offers all the tools to write your own fast implementation should you want that).

Overall, I can see value of switching to Erlang if you are using a platform/language with much worse concurrency primitives, but with F# and C#, personally, Erlang and Elixir appear to be a sidegrade as .NET applications tend to scale really well with cores even when implemented sloppily.

Task exceptions can simply be handled via try-catch at the desired level. Millions of concurrently handled tasks is not that high of a number for .NET's threadpool. It's one thing among many that is "nothingburger" in .NET ecosystem which somehow ends up being sold as major advantage in other languages (you can see it with other features too - Nest.js as a "major improvement" for back-end, while it just looks like something we had 10 years ago, "structured concurrency" which is simple task interleaving, etc.).

It's a different, lower-level model, but it comes with the fact that you are not locked into particular (even if good) way of doing concurrency in Erlang.

You can for example configure a process to have enough initial memory so as not to ever run into GC, this is especially useful if you have a process that does a specific task before terminating. Once terminated the entire process memory is reclaimed.