[HN Gopher] Membrane: Media Framework for Elixir
___________________________________________________________________
Membrane: Media Framework for Elixir
Author : lawik
Score : 103 points
Date : 2025-05-10 13:33 UTC (3 days ago)
(HTM) web link (membrane.stream)
(TXT) w3m dump (membrane.stream)
| victorbjorklund wrote:
| This is such a cool project. Haven't used it for any serious
| things but just the ability to have a high performance media
| streaming framework inside of Elixir is amazing. You literally
| could build Twitch just using BEAM and nothing else (a Postgres
| database is probably good to have though).
| clacker-o-matic wrote:
| That would be the dream. Do you know of any major apps using
| elixir besides telecom?
| dlachausse wrote:
| There are several companies that are known to use elixir in
| production...
|
| https://elixir-lang.org/cases.html
| throwawaymaths wrote:
| Tubi (relevant), Tvlabs, pagerduty, divvy
|
| All not on the list.
|
| There's also the legendary bleacherreport abandoning elixir
| and totally shooting themselves in the foot.
|
| Several fintech companies moved off - brex, ramp. I think
| for brex they were told by VCs to hire XYZ CTO and the CTO
| couldn't elixir. Hilariously I ran into ramp people totally
| in the wild who complained that "they couldn't find elixir
| devs". I told them "you just randomly ran into one". I
| think their hiring processes were likely broken, but what's
| new in silly valley?
| dlachausse wrote:
| I don't understand the fixation on hiring $LANGUAGE devs.
| If you can't find any developers using your current
| stack, pay for a course or a book for them and train them
| on it. Training a competent developer to use a new
| programming language has to be easier, cheaper, and
| faster than rewriting your entire software stack.
| throwawaymaths wrote:
| If you're a cto hired in to a company you need to make
| your mark somehow.
| jerf wrote:
| You can always find stories of people moving off of
| stacks. Sometimes they just legitimately evolved in a
| direction the stack wasn't the best solution for.
| Sometimes they should never have picked the stack in the
| first place. Sometimes a new leader came in who had
| preconceived notions that the company needed to conform
| with. You really have to look at the specifics of the
| story to know if it's relevant to you.
|
| In my very opinionated opinion, it's actually reasonably
| uncommon for me to read a story of someone leaving a
| stack and not classifying it as one of the things I
| listed above. Of the cases I would consider "legitimate",
| it's usually a performance issue; some languages and
| runtimes are just intrinsically slower than others, or at
| least, intrinsically slower without an unrealistic amount
| of effort. (Elixir would be middling here. BEAM is kind
| of between the dynamic scripting languages and the
| compiled languages. The interpreter is simple enough that
| it can run much faster than the dynamic scripting
| languages but it would be completely unacceptable
| performance for any compiled language. You can run out of
| performance in BEAM, but it does take a system that needs
| performance and some growth to get there.) The rest are
| probably complexity explosion of some framework, and this
| is almost always a UI framework problem.
| luckywatcher wrote:
| Divvy still uses Elixir extensively. I use to work there
| and still have many contacts there.
| lytedev wrote:
| Currently work here and we're definitely still building
| and supporting Elixir applications and enjoying it!
| throwawaymaths wrote:
| Thanks. Updated. Something about the best way to find an
| answer is to write an incorrect answer on the internet!
| ;-)
| cultofmetatron wrote:
| my startup is using elixir in production for the last 5
| years. we are a cloud based restaurant POS.
|
| no regrets. the ecosystem has been pretty solid for
| everything we've wanted to do. Stability/performance has been
| very good.
|
| also: if you're looking for a high profile startup using
| elixir, supabase is almost entirely elixir and discord uses
| it for some critical parts.
| rched wrote:
| Are you willing to share the name of your startup?
| cultofmetatron wrote:
| https://blinqme.com/
| atonse wrote:
| We've been running elixir in production since 2017.
|
| During the pandemic, our elixir app sent/received 45 million
| text messages, helped schedule 1.5 million vaccination
| appointments, and a few million COVID testing appointments.
|
| It all scaled and performed flawlessly. Any bugs were our
| fault :-)
| fridder wrote:
| Cars.com did a pretty extensive rewrite to Elixir
| vishalontheline wrote:
| OkNext.io is built using Elixir and Phoenix framework, if
| you're considering building a Web App and looking for
| examples.
| paradox460 wrote:
| PagerDuty, Pinterest, TheRealReal, Discord, Cars.com,
| Bleacher report
| ettomatic wrote:
| At the BBC we use Elixir quite extensively. I'll talk about
| this at ElixirConfEU in a few days if you are interested.
| dlachausse wrote:
| The BEAM even includes a database - Mnesia...
|
| https://www.erlang.org/doc/apps/mnesia/mnesia.html
| throwawaymaths wrote:
| Honestly I think mnesia is one of those "don't use it unless
| you know what you're doing" things. Just use postgres.
| jerf wrote:
| Mnesia is not a database by any modern definition of the term
| and it should generally be avoided. It is at least 4 if not 5
| orders of magnitude away from "being able to run Twitch".
| That is, yes, I'm serious, if you tried to run a Twitch clone
| "but 10,000x smaller" I would still expect Mnesia to
| completely fall over.
| toast0 wrote:
| Mnesia worked well enough for us at WhatsApp while I was
| there; although we didn't use it to store messages; long
| term message storage is on the end points (generally
| sqlite), messages in transit (offline) were stored in a
| file per user with the import/export written in C IIRC. We
| did add redundant in memory storage of messages in transit;
| but I don't remember the storage there; may have just been
| ets.
|
| We mostly used mnesia as a replicated key-value store, but
| we got a lot of value from having the data and the business
| logic colocated. Other nodes would send logical operations
| to processes on the mnesia node and those processes could
| run each operation one at a time on the data. Any
| concurrent logical requests for a given piece of data were
| implicitly serialized by the process mailbox. But almost
| all of our data was easy to shard, no high volume
| operations needed to address multiple tables.
|
| We heard _a lot_ of things about mnesia scalability limits
| that just didn 't match up with our experience; so I don't
| know what other people were doing, but you can get a
| glimpse of what we were doing in the Rick Reed talks at
| Erlang Factory. We certainly had some scalability
| challenges, but many (most?) are discussed in those talks;
| and my general recollection is that most of them were more
| like we were the only people running mnesia with tables of
| enormous size, so we had to make things work; but that's
| kind of how OTP is. The trickiest one to find, IMHO, was
| that IIRC mnesia_frag and ets (and our request sharding)
| all use(d?) the same hashing function, so adding more
| fragments would make distribution of keys per ets slot
| worse, ets wanted power of two slots, and would split based
| on average keys per slot, but we would have lots of keys on
| some slots and no keys on most slots. Changing the hash
| seed for ets was a 2 line code change that drastically
| improved performance on all of our sharded mnesia systems.
|
| Another fun one is that if you use mnesia to store data for
| long periods, you have to be _very_ careful with the
| binaries you store; it 's easy to end up with refc binaries
| that have extra space for append operations; storing them
| in mnesia means that append space is allocated but
| unusable; you might also store a sub binary that's a small
| part of a refc binary, the underlying binary can't be
| disposed of until the sub binary is. For both of those
| cases, cleaning the binaries before storing them with
| binary:copy/1 can really reduce your memory use. There's
| probably some cases where you do want to store a sub binary
| though?
|
| Mnesia doesn't (or didn't) include a good way to handle
| when two mnesia nodes sharing a schema disconnect and
| reconnect. We mostly solved that by ensuring our network
| was stable enough that that rarely happened. If your
| network is not stable, you _will_ have a bad time with
| distributed Erlang in general, and Mnesia in specific.
|
| If I were building Twitch but smaller, and on the BEAM, I
| would absolutely put account databases in Mnesia; but
| messages and media would probably live as files. I wouldn't
| tend to put those into a SQL database on a server either
| though.
| schultzer wrote:
| mnesia is great, and you can get very far before you would
| make the jump to anything else. And it can be way faster then
| any other database. For obvious reasons.
|
| Although it would be great if it spoke SQL, maybe one day it
| will: https://github.com/elixir-dbvisor/sql since we can
| already pass it and get the AST.
| troupo wrote:
| And when you do have to jump off, you'll be screwed.
| Because the jump off is usually from in-memory Mnesia with
| guaranteed sub-millisecond responses to a proper database
| with at least a magnitude higher latency. And you realize
| that your app is completely dependent on sub-millisecond
| responses :)
| schultzer wrote:
| Low latency is addictive. And by the time when you think
| you might need to change you're probably become such a
| skilled engineer that you realize that everybody that
| shit on mnesia does not know what they talk about. :)
| Sean-Der wrote:
| Fantastic project, and the team behind it is really good! The
| developers I have worked with are passionate about building
| things the right way (not just making it work/adding kludge).
|
| I felt like I was seeing the future when I saw the
| visualization/rendering of PeerConnection stats on the server
| side. The video compositor is really neat also how they have it
| working with live modifications.
|
| I wish I had more time/a chance to use it on a project myself.
| mml wrote:
| I really wish Nvidia had gone in this direction instead of
| gstreamer :/
| AlphaWeaver wrote:
| I looked at using this for a client project a few months ago. We
| use Erlang and Elixir at work, and it's my go-to for anything
| serious.
|
| Be aware that parts of their stack use a custom license for some
| components... but a large portion of it is OSS Apache 2.0, which
| is nice if you can stick to those parts!
| kingofheroes wrote:
| I recall doing a tutorial for Exilir, the Phoenix framework in
| particular, a few years back and I actually enjoyed using it.
| Anyone know any good up-to-date tutorials someone could use?
| malkosta wrote:
| The official ones are still the best:
| https://hexdocs.pm/phoenix/overview.html and
| https://hexdocs.pm/elixir/introduction.html
| tortilla wrote:
| For Phoenix/LiveView, the pragmaticstudio's courses are great.
| I just completed https://pragmaticstudio.com/courses/phoenix
| nw05678 wrote:
| During my foray into Elixir I never found the develop environment
| as smooth as other languages.
| bo0tzz wrote:
| A bunch of work is currently going into improving that.
| innocentoldguy wrote:
| What do you mean by "develop environment"? Are you referring to
| IDE support or features like mix, IEx, pry, releases, etc.?
|
| If the latter, Elixir has one of the best development
| environments, in my opinion. Mix is fantastic, releases are
| easy, and Elixir's error messages in IEx are the clearest I've
| seen in my 30+ year career.
|
| I use Emacs to write code, and beyond syntax coloring, I don't
| want anything else, so you may have a point if you're talking
| about IDE support.
___________________________________________________________________
(page generated 2025-05-13 23:00 UTC)