Hello, I evaluated Go at the very beginning and after making proof of concept I decided to stay with Elixir. One of the reasons was that Go has garbage collec

Hello, I evaluated Go at the very beginning and after making proof of concept I decided to stay with Elixir. One of the reasons was that Go has garbage collector that can "stop the world" which is really not acceptable in some low-latency applications. BEAM VM does GC per erlang process. Secondly, significant chunk of such framework is about interoperability with C as there're tons of libraries we're going to wrap around. cgo essentially requires developer to reimplement in definition of every single structure and function we're going to ever use. It's a massive overhead (not in sense of computational overhead but time spent). NIFs are way simpler, there just regular C code you can link with libraries without any overhead. Remember that in such framework we're going to do quite o lot of pointer arithmetic and having plain C code is a huge advantage. All that together allows us to have greater flexibility on how to design C layer. cgo binds us to a particular solution that is not really well designed. With Elixir we can even write C code in Rust as was suggested in another comment. Please remind that what is really computationally expensive will be often written in C/C++ anyway or done by GPU. Framework does not add that much overhead in macro scale, it's often just a glue and abstraction layer. And finally, if you read our goals, we clearly state that if we have to make a tradeoff, we put reliability over performance. The motivation to start Membrane was that while designing broadcasting systems we struggled to achieve true 24/7 availability with existing frameworks. You can't compare 20+ years of Erlang development in this area with Go. I mean both maturity of the VM, as well as battle-tested design patterns, built-in supervision, hot upgrades and so on. Go is cool, trendy and has very loyal user base but it's not free of caveats.