The approach confuses me because there is so much praise for the Erlang VM but to get all its benefits of the Erlang VM they need to use ports. (Which they confess is going to be slower).
Anyway even with NIFs we delegate to them only code that cannot be written in Elixir or it really makes no sense to keep it in Elixir e.g. in performance reasons. Even if 30% of the framework will be in C it's way easier to manage 30% of C code than 100% of C code.
Moreover, all the hard stuff, such as parallelism, being able to inspect running state of the VM, ability to spread app over cluster, I/O scalability, being multiplatform etc. comes out of the box with BEAM VM. There are many things that are give the point of using Erlang VM even if part of the code is in C and is potentially dangerous.
If you used Golang you would also get parallelism, I/O scalablity, multiplaform capability... all the things you list as advantages for BEAM. The only thing that BEAM is giving you "extra" vs, say, Golang is the ability to spread your app over a cluster easily. But again, I'm sure you can achieve that with some sort of a load distributer if you used Golang on multiple machines. Also with Golang it is easy to do CPU intensive tasks because its "closer" to the metal. So I guess what I'm saying is that for your specific use case (that involves a lot of media related CPU intensive work like video/audio processing) I wonder if the BEAM VM will give you that many advantages. With Golang in this case I think you can get the scalability, reliability as your current setup with one big advantage: better performance. But this is just my ~5 min view of the subject...
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.
Additionally, as someone in this thread has already pointed out, it is also a matter of taste and preference on choosing Elixir over Golang.
A point about Elixir macros -- I think you will find that while macros increase your productivity, they make debugging the code a bit more difficult.
Wish your project best of luck. The website looks slick!
It's possible to make them crash the VM if they leak memory or don't prempt when asked. In Rust you can make better guarantees about your code and there is this that allows you to write them in Rust: https://github.com/hansihe/rustler
P.s. I know there is a little arrow that does an animated automatic scroll upwards but for me needing such a thing is a clear indication of a flawed design. Instead of fixing the symptom you should fix the root cause..
Displaying the menu and home icon on
screen at all times, comes with trade offs such as:
- less screen space available for other items
- implementation difficulties with floating fixed icons
- distraction from content
- overlap with on-page elements
And that's just what I can think of at 6am, pre-coffee. I would imagine the actual team has dozens of reasons behind their choice.
To choose not to do so is design choice, taking into account the entire situation.
Now you as a single particular end-user may not agree with their choice, but that's not a universal "flaw", but the essence with compromise in general---someone will lose out and be unhappy.
Making the navigation menu not easily accessible at all times, where I count having to scroll up 3 pages not easily accessible, is a design flaw to me. Note that my first comment also mentioned to _me_, but that may have been missed before the first coffee went in :).
I imagine the following scenario:
* I have 3 source audio/video feeds
* I need to follow a pipeline along the lines of:
-- ingest the source feeds
-- stitch segments from the sources together into an output stream following some business rules
-- extract metadata from the source (e.g. speech-to-text)
-- transmux/re-encode the output to different renditions (bitrate/resolution combinations)
-- Output the rendtions and metadata
Is that a reasonable understanding of what this framework is meant to enable?
When I tried to use it for the last time (1-2 years ago) it also had severe stability issues but maybe that improved over time.
Maybe drop me an email at firstname.lastname@example.org so we can discuss the matter in greater detail?
I love when OSS projects reusing ICO templates;)