Just because you read it in a HN comment doesn't mean it works in the real world.
It has to deal with lots of third party interfaces, websockets, webhooks, etc. Erlang is notoriously bad for modern web stuff, with elixir making the ecosystem more brittle and lower quality. If you're building a system that needs to do a lot of back-and-forth, go is a much more usable tool.
Have you ever tried to debug a giant erlang clusterfuck, calling out to a dozen different service gateways, varying tuple msging nonsense all over the place, jankedy ass comment annotations that aren't even accurate half the time, and all the while trying to fix things with hot swaps?
It all sounds very good when Joe writes those weird little lewis carroll love letters about how magical erlang is, but I've worked on a system like that and I'll never touch erlang again except for small single-shot services. It's completely cancerous as a language ideology.
Not that go is all that much a panacea, but it's definitely the perfect fit for this sort of thing.
Hope this doesn't come across as too harsh, but what you're describing is a rabbit hellhole I've already crawled through.
Also, with projects this size, abstracting db details isn't wise. This kind of scale necessitates more precision in what schemas you choose and what configuration your dbms has. Crap like ecto will ultimately cost you in efficiency. Elixir can get away with it because beam works hard to do supervision thoroughly, but there are multiple performance penalties that beam imposes on itself by choosing abstraction instead of specialization, and again, this problem would demand a specialiZed approach to be efficient as it scales up.
It has to deal with lots of third party interfaces, websockets, webhooks, etc. Erlang is notoriously bad for modern web stuff, with elixir making the ecosystem more brittle and lower quality. If you're building a system that needs to do a lot of back-and-forth, go is a much more usable tool.
Have you ever tried to debug a giant erlang clusterfuck, calling out to a dozen different service gateways, varying tuple msging nonsense all over the place, jankedy ass comment annotations that aren't even accurate half the time, and all the while trying to fix things with hot swaps?
It all sounds very good when Joe writes those weird little lewis carroll love letters about how magical erlang is, but I've worked on a system like that and I'll never touch erlang again except for small single-shot services. It's completely cancerous as a language ideology.
Not that go is all that much a panacea, but it's definitely the perfect fit for this sort of thing.
Hope this doesn't come across as too harsh, but what you're describing is a rabbit hellhole I've already crawled through.
Also, with projects this size, abstracting db details isn't wise. This kind of scale necessitates more precision in what schemas you choose and what configuration your dbms has. Crap like ecto will ultimately cost you in efficiency. Elixir can get away with it because beam works hard to do supervision thoroughly, but there are multiple performance penalties that beam imposes on itself by choosing abstraction instead of specialization, and again, this problem would demand a specialiZed approach to be efficient as it scales up.