3 things that I believe are design flaws in #erlang/#elixir:

1. Let it crash. Usually if it crashes, something went wrong, and you're now hiding a problem. Also, you now need to think about how you restart correctly, which can get really complicated.

How not to crash you ask? Stay tuned.

1/3

2. Erlang term ordering. This is simply stupid. 23 < 42 is true, but so is {:ok, 23} > 42 and nil > 42. Both of the latter situations occur often accidentally, and are silent errors. Instead, this should fail loudly with an exception, as e.g. DateTime.compare does. There should be an Ord or Compare Elixir protocol to supersede Erlang term ordering. Or there should be a way to prevent such situations! How to do that you ask? Stay tuned.

2/3

3. Lack of a static type checker.

Erlang & elixir have such a simple type systems that it is easy to write a static type checker. 30 years into Erlang, and we still don't have a usable one. (There are small projects like https://github.com/gyson/ex_type/, check it out.)

Never again store invalid state in your GenServer! Never again crash because you forgot an exception or a case clause! Never again accidentally pattern match incorrectly!

Heck, we already have specs! It could be so simple.

3/3

FAQ about type checkers in Elixir/Erlang

Q: But we have dialyzer?
A: It's crap, slow, and doesn't find half the bugs a useful tool (a.k.a. type checker) would.
Q: But in a receive, the type of something could be anything!
A: Yes, that's why a term in receive would have type any().
Q: But I use Code.eval_string! (Bonus points if your string comes from the internet.)
A: You probably shouldn't. Anyways, you shouldn't trust the output of that, so it has type any().