This is why I really want an OCaml back-end to Elixir, entirely possible, just needs to get done. 
For note, F# was based on OCaml, most code that works in F# works in OCaml almost unaltered (except for the accessing of .NET specific oddities). So if you like F#… 
Also, can’t F#'s Agents crash everything by calling the wrong thing? That is a .NET limitation, it does not have the hard guarantees of something like the BEAM, regardless of the language or libraries used…
Two things, F# does not have modules like OCaml, that is one of the big things it is missing, it has most of the abilities, but not all, last I saw anyway. Also based on Active Patterns - F# | Microsoft Learn for Active Patterns, can’t you just do that with a single function call between the match and input? What does this gain other than magically coercing types (which OCaml abhors as it harms readability)?
But yes, I badly badly want some for of typed Elixir, and an OCaml backend to Elixir would be wonderful!
OOP. I can still remember reading my first book on OOP about polymorphism, inheritance, data hiding, encapsulation and thinking “Wow, this is incredible” (I had only done some C, Basic, and assembly at the time.). Honestly I don’t get that feeling with FP alone (older now hah!). But Erlang/Elixir + OTP was exactly what I was looking for with ibgib. It was so natural to code the engine in it, and I feel blessed that I found this ecosystem (and community). But I digress…my point is that to me the BEAM isn’t about the “actor model” or FP or any other individual patterns or aspects built on top of something to be concurrent - it just is concurrent.
. I apologize if I offended.
Wow! Consequently, I took to Ecto’s syntax like a duck to water. 
Anyway, now I’m an old man reminiscing…I definitely need to continue to keep my eye on F#, now that I’ve been immersed more in the FP world.