[valenterry]

> Fault tolerance and supervision hierarchy might be unnecessary as mentioned.

It's not like there is suddenly no fault tolerance though. Erlang has a certain way of handling/dealing with errors/faults and so does Rust and other languages. I would not by default assume that Erlang's errorhandling is superior.

> That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance.

I would much rather say that runtime introspection has to comete with a static type system.

As I said many times, I really like the BEAM (saying that after having worked with Akka quite a bit) but Erlang/Elixir... those languages are really not great. There are many languages that way better. I also know that there is a new one for the BEAM (forgot the name) but so far we are mostly stuck with E&E.

[Fire-Dragon-DoL]

The reason why I haven't brought it up is because they are not the same thing, so they can't compare. Of course rust type system is great, but at the same time the memory management is not something necessary to most software.

Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).

[valenterry]

> Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).

My problem with this statement is, that it emphasizes the language (Elixir) but what you really mean is the paradigm of using the BEAM no? As in, using Erlang or Elixir doesn't really matter for those good practices, even if Elixir is nicer in some regards.

In that case, it should be written like that, otherwise it will confuse people and prompt them to disagree, like I did.

[Fire-Dragon-DoL]

No, I don't think so. Sure the language is structured to work with beam, so the line is somewhat blurry, but in my mind I was referring to practices that the language itself promotes:

    - no state, unless when you really need it
    - avoid mocks unless you really need
    - pipeline-style approach where writes happen only at the end (io at the edge of the system)
    - prefer integration tests

Just things you figure out as you write elixir code