Live data from Hacker News

How Discord Scaled Elixir to 5M Concurrent Users

blog.discordapp.com

181–190 of 260 posts

Re: How Discord Scaled Elixir to 5M Concurrent Users

#181

Earlier quoted context omitted.

Distributed Erlang compatibility is guaranteed for not just one, but two major versions. You can do a standard rolling upgrade and the newer nodes will talk to older nodes just fine. http://erlang.org/pipermail/erlang-questions/2011-June/05946... Foreign nodes in C, Java, Python, etc. can also join an Erlang cluster: http://erlang.org/doc/tutorial/cnode.html http://erlang.org/doc/apps/jinterface/jinterface_users_guid…

It's great that they support C and JVM stack. But for other major platforms such as NodeJS, Go, ... we still need to approach the goal with some C extensions integrated in both platforms. Erlang/OTP distribution/clustering is really not designed for heterogeneous environment which is fine, since it is used in telecom industry with nice commercial support contracts backed by Ericsson. However I don't consider it as an…

Erlang is what you would use to implement a single service (which may run on a cluster of multiple nodes). It's not a generic messaging layer to use between services, you can use RabbitMQ or ZeroMQ or whatever you like for that.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#182

I do not see there any Elixir specific, it is all basically Erlang/Erlang VM/OTP stuff. When you using Erlang, you think in terms of actors/processes and message passing, and this is (IMHO) a natural way of thinking about distributed systems. So this article is a perfect example how simple solutions can solve scalability issues if you're using right platform for that.

You're right. Elixir doesn't pretend to do anything except make using the wonderful erlang VM/OTP stuff easier. The VM is an absolute marvel of engineering, and it's insane to me that it doesn't have more adoption yet in big tech companies. My best theory is that engineers in top engineering companies are actually not the best engineers but simply career engineers that learn one skill (python/java/C++) and then expla…

Coordination problems get more difficult in larger teams/companies. Getting everyone to use a particular non-standard language is a coordination problem. Thus large companies are unlikely to experiment with languages.

It makes sense too - say it's 10x easier to write something in language X than Y. If there's only 10 other people that might interact with the thing / have to read the sources, that's a great tradeoff. If there's a thousand other people that might have to at some point understand how some part of your code works, suddenly all of them have to learn the new language X.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#183

Earlier quoted context omitted.

People tend to forget that scalability is not a binary property. You always scale up to some users, up to some architecture, up to some amount of nodes. There is no system that will scale to infinity without requiring developer intervention once business needs and application patterns start to settle in. Distributed Erlang/Elixir has known limitations . For example, the network is fully meshed, which gives you about…

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…

Good luck writing something on your own that scales better.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#184
post #19

This writeup make me even more convinced of Elixir becoming one of the large players when it comes to hugely scaling applications. If there is one thing I truly love about Elixir, it is the easiness of getting started, while standing on the shoulders of a giant that is the Erlang VM. You can start by building a simple, not very demanding application with it, yet once you hit a large scale, there is plenty of battle-p…

Truly the strenght of elixir comes for Erlang. I wonder if Scala is also as good as erlang for creating robust and fail proof distributed systems?

Re: How Discord Scaled Elixir to 5M Concurrent Users

#185
post #20

I know that the JVM is a modern marvel of software engineering, so I'm always surprised when my Erlang apps consume less than 10MB of RAM, start up nearly instantaneously, respond to HTTP requests in less than 10ms and run forever, while my Java apps take 2 minutes to start up, have several hundred millisecond HTTP response latency and horde memory. Granted, it's more an issue with Spring than with Java, and Parallel…

> I know that the JVM is a modern marvel of software engineering, so I'm always surprised when my Erlang apps consume less than 10MB of RAM, start up nearly instantaneously, respond to HTTP requests in less than 10ms and run forever, while my Java apps take 2 minutes to start up, have several hundred millisecond HTTP response latency and horde memory.

That's not the platform's problem, you're doing something wrong. I run my web services on Spray[1] and they start in maybe 10s, average HTTP request latency is 4ms, and they run forever at ~100-200MB RAM. That's without putting any effort into tuning.

[1] now replaced by akka-http but I haven't ported yet, and it works

Re: How Discord Scaled Elixir to 5M Concurrent Users

#187
post #170
post #38

Earlier quoted context omitted.

> I see a bright future for Elixir, and a breath of fresh air for Erlang. Is Erlang really that much of a barrier? Erlang was a touch odd, but I didn't find the language itself that mind-bending. Wrapping my head around the proper way to structure things and the proper use of the OTP libraries was much more time-consuming. That level of architectural thought doesn't magically go away because you changed the language.…

The problem is not and has never been the syntax. It is the tooling. No build tool. No way to generate a new project. Do it yourself docs. No templating system. Macros ala C. No package manager. Building releases was a dark art. It is now getting better. But it was a really steep curve to adoption.

Aside from macros, pretty much all of these have been covered by build tools for a few years now.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#188
post #141

Earlier quoted context omitted.

The true evil approach is to send the socket around, not the message, so that there is no copying required no matter what ;)

Wah. Easy there, Satan :-) That is cool trick though. So it's basically sending the port itself around and changing its ownership, with something like port_connect(Port,NewOwner)? And btw, thank you for writing https://www.erlang-in-anger.com and http://learnyousomeerlang.com !

The trick is more commonly used when writing to sockets. A socket owner is required for reading, not for writing.

The trick then is that when you need to write lots of data to a socket to just send a copy of it to the writer so they can dump all their data for cheap, but without changing ownership (which is costly).

Also recently I've gotten http://propertesting.com/ out, you might enjoy it :)

Re: How Discord Scaled Elixir to 5M Concurrent Users

#189

Just as an aside how would people build something like this if they were to use say Python and try to scale to these sort of user levels? Has anyone succeeded? I'd say it would be quite a struggle without some seriously clever work!

Yeah pretty much impossible with python.

Re: How Discord Scaled Elixir to 5M Concurrent Users

#190
post #170
post #38

Earlier quoted context omitted.

> I see a bright future for Elixir, and a breath of fresh air for Erlang. Is Erlang really that much of a barrier? Erlang was a touch odd, but I didn't find the language itself that mind-bending. Wrapping my head around the proper way to structure things and the proper use of the OTP libraries was much more time-consuming. That level of architectural thought doesn't magically go away because you changed the language.…

The problem is not and has never been the syntax. It is the tooling. No build tool. No way to generate a new project. Do it yourself docs. No templating system. Macros ala C. No package manager. Building releases was a dark art. It is now getting better. But it was a really steep curve to adoption.

Huh? rebar, and now rebar3, have existed for a long while. rebar 2.0 was released in 2012.
Post reply on HN