Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Discord Scaled Elixir to 5M Concurrent Users

blog.discordapp.com

Post reply on HN
Print view View original

171–180 of 260 posts

Re: How Discord Scaled Elixir to 5M Concurrent Users

#171

Post by majidazimi »

toast0 wrote: post #165
majidazimi wrote: post #154

It seems awkward to me. What if Erlang/OTP team can not guarantee message serialization compatibility across a major release? How you are going to upgrade a cluster one node at a time? What if you want to communicate with other platforms? How you are going to modify distribution protocol on a running cluster without downtime? As soon as you introduce standard message format, then all nice features such as built-in di…

The erlang team has been through 20 major releases, I think I've run all of them since r13 or r14? Being able to upgrade your distributed system is important and they care about making it possible. Generally you upgrade one node at a time, until they're all upgraded and only then can you use new language features. Sometimes you find a build you like and stick with it until something comes up that causes you to upgrad…

> You're going to have the same questions with any other language too. Very few companies get to write clients, servers, and everything else in one language that never updates.

Then I don't see much difference between Go, Java, ... vs Erlang except they are simpler to learn plus finding Java, NodeJS, ... devs is much easier. What was the point of using Erlang? It was supposed to solve a problem for us, but we end up of solving the problem ourselves.

What I'm really trying to say is: integrating a mainstream language like Go, Java, C++, ... with a messaging layer like ZeroMQ (or something else) and adding some reliability features is going to be easier than introducing a totally new language (with a totally different paradigm) into the stack.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#172

Post by di4na »

cutler wrote: post #11
myth_drannon wrote: post #6

It's interesting how on StackOverflow Jobs Elixir knowledge is required more often than Erlang. http://www.reallyhyped.com/?keywords=erlang%2Celixir

Despite its appeal to HN geeks I doubt if Elixir will ever achieve mainstream adoption. Searching Indeed.co.uk's API by title, there are only 5 Elixir jobs in London, compared with 445 Python and 171 Ruby. I also attended a Silicon Roundabout jobs fair recently and was disappointed to find Elixir wasn't even listed in the literature.

Just saying but most companies that search elixir dev do not go in this website. They immediately go for the community. Faster, easier and you get more consistent results.

Difference between hiring "someone that knows it" and "a good dev interested by it"

Re: How Discord Scaled Elixir to 5M Concurrent Users

#173

Post by ericmj »

_asummers wrote: post #127
fbernier wrote: post #122

Earlier quoted context omitted.

Download count is a weak metric for evaluating the quality of a library. I don't think it's a good idea to skip the few minutes it takes to read parts of the documentation and critical parts of the code.

I agree completely. I never said that it should be used for evaluation or that you shouldn't read the code or docs. But then the question is... how do you find high quality libraries without something like download count? The issue is signaling good libraries, with poor discovery. I subscribe to many "libraries worth looking at" mailing lists, the awesome lists, etc. but that is still a pretty coarse net. Searching f…

Search on hex.pm is not great and can definitely be improved, but we are currently at the limit of postgres full text search afaik, unless there are some magic things to tweak. This means we need to switch to other technologies to improve the search which is a bigger task.

But regardless of how good search is it wouldn't find ryal_core when searching for "commerce" if that word or any similar is nowhere in the metadata. The description for the package ryal_core is "The core of Ryal." which doesn't do the search any favours.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#174

Post by tony612 »

sametmax wrote: post #167
janekm wrote: post #46

Earlier quoted context omitted.

I read it a little differently. The whole article is about how Erlang/Elixir fails at its core reason for existence (fast message passing between distributed processes) and all the complicated work-arounds they had to implement to avoid actually using this core feature of Erlang.

Me too. I mean, 5 millions is not that many users. It requires work, but it's not Google size by any mean. It's just a successful service. Give that the whole selling point of Erlang/Elixir is scalability at the price of the rest, the article is really telling me to avoid the tech.

It's 5M Concurrent Users. And Google-size services can't be built with just a language. It needs much more work to do.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#175

Post by majidazimi »

josevalim wrote: post #161
majidazimi wrote: post #156

Earlier quoted context omitted.

What difference does it make? Erlang/OTP distribution doesn't have pluggable architecture. Sooner or later you will reach a point that you have to modify it. Then you are diverging from the original branch which makes it even more difficult to maintain it. You have to merge your additions into every release (minor or major) and test it thoroughly. A better architecture for a distributed system has a strong composabil…

What do you mean by architecture here? If you mean the roles different nodes take and their topology, I actually doubt you can be decoupled from your architecture in a distributed system because they directly affect your design and capabilities. You can move away from fully meshed for topologies but how does this choice affect node ups and node downs? Rebalancing can affect how you store data in the cluster. How many…

I did also mention that for fast time to market it is indeed a good idea to use already available tools. By the way writing a distribution layer is not that difficult. Many companies/startups with scalable back-ends that are not using Erlang/OTP have already done it. The point is scalable software requires knowledge and Erlang/OTP is not going to magically solve it. But it seems many fans are trying to promote it such that it is a magic tool that is going to make a shit software become a hyper scalable one. Just look at the comments below that how people have gone crazy.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#176

Post by OOPMan »

k__ wrote: post #164
OOPMan wrote: post #163

5 million concurrent users is great and all, but it would be nice if Discord could work out how to use WebSockets without duplicating sent messages. This seems to happen a lot when you are switching between wireless networks (E.g. My home router has 2Ghz and 5Ghz wireless networks) or when you're on mobile (Seems to happen regularly, even if you're not moving around). It's terribly annoying though and makes using the…

Coming from IRC with netsplits and stuff, this seems like a first world problem to me hehe

You know there are discord bots for bridging between IRC and Discord?

Pretty funky :-)

Re: How Discord Scaled Elixir to 5M Concurrent Users

#178

Post by ramchip »

_asummers wrote: post #114
ramchip wrote: post #109

Earlier quoted context omitted.

I don't think that's the problem for metrics. Exometer is the go-to Erlang library, but its dependencies are a nightmare (e.g. https://github.com/Feuerlabs/exometer/issues/154 or https://github.com/Feuerlabs/exometer#dependency-management ), it's essentially unmaintained, and integrating it with Ecto or Phoenix is roll-your-own. I think there is very much a need for a more modern library that plays nicely with Hex.

We've had success with Elixometer, though the dependency pinning was a pain. All but two are fully on Hex now. https://gist.github.com/asummers/3479eb6e3914d9b9a24c9566468...

Thanks, I might have to use this soon :)

Re: How Discord Scaled Elixir to 5M Concurrent Users

#179

Post by vertex-four »

bigtunacan wrote: post #116
vertex-four wrote: post #99

Earlier quoted context omitted.

Elixir is just alternative (Ruby-ish) syntax for Erlang, as much as people have hyped it up - Erlang code can call Elixir code and vice versa with essentially no abstraction cost. In fact, the most popular web framework for Elixir is heavily built on Erlang code.

That was my point exactly. Before if you really needed the benefits of running on BEAM then you would have chosen Erlang. Now that subsection will fragment between Erlang and Elixir. Today Elixir developers still will lean heavily on the interaction of Erlang libraries until someone in Elixir-land needs something that isn't supported so then they will re-invent that particular wheel in Erlang and thus the cycle conti…

I wouldn't bank a career on a language anyway, so.

However, as Elixir is just another skin for Erlang, switching from Elixir to Erlang or LFE or whatever the next language for that runtime is will be simple - the issue is really BEAM and OTP, as few of the skills learned around them are cleanly transferrable to other runtimes and frameworks.

I suspect that Go will be around for a while by sheer force of inertia at this point - we're 5 years since 1.0 now and it still seems like there's new major projects being started in it every day.

Rust is... interesting, but I think it'll always have its niche. As much as people like to riff on the RIIR crowd, there's actually a somewhat decent ecosystem of reimplemented libraries and systems in Rust already, and now that Rust code is part of Firefox it seems unlikely that Mozilla will stop supporting it for a long time to come. It also seems to not be a zero-sum game - rather than stealing devs from C++, it's brought a lot of developers from "non-systems" languages into the "systems" space.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#180

Post by jhgg »

toast0 wrote: post #108
janekm wrote: post #46

Earlier quoted context omitted.

I read it a little differently. The whole article is about how Erlang/Elixir fails at its core reason for existence (fast message passing between distributed processes) and all the complicated work-arounds they had to implement to avoid actually using this core feature of Erlang.

Erlang's core reason for existence is to control telephone switches, which had two independent general purpose computers connected to the physical switch. So reliability, redundancy, recovery, and fault isolation were the core needs; that drove the design for isolated processes with message passing between them. Because Erlang was in the control plane, and only managing the signal path, not passing the signals itself…

>I don't think they've even needed to tweak the vm yet either, just their user space code.

We haven't really had to. Really only args we use are "+sbt db +zdbbl 32000 +K true" and increasing the default process limit.

Post reply on HN