6 ms·

> It has similar aura than Lisp had before that with Erlang you can do stuff beyond "normal" languages. Like what ?

quaunaut 7y ago
The fact that the entire ecosystem is based around the actor model is one of the primary ones. It's allowed for code that isn't simply a library, but effectively an entire application, to be used as open source to be dumped into your system, because it has tools like Erlang Term Storage, Mnesia, and other devices to make it easy.
- hota_mazi 7y ago
  You're still not explaining why this allows to do things that can't be done in other languages. Probably because that claim makes no sense.
  - nathanappere 7y ago
    Reductions. How do you ensure in other languages (or in other VMs) that every actor will get the same cpu time and that none can block the others? That's a tricky problem to solve as a lib.
atupis 7y ago
I think Whatsapp served "at peak" like 450 million users with only 32 engineers.
- dmitriid 7y ago
  Whatsapp also had multiple patches to Erlang VM, backported FreeBSD drivers and code etc. etc. Do not assume you'll be able to build your own Whatsapp just because of Erlang.
  - fouc 7y ago
    The story of freebsd & erlang "needing" to be patched seems to be greatly exaggerated. Especially when it turns out that elixir/phoenix also achieved the same "2 million connections on single server" without needing those optimizations.
    - dmitriid 7y ago
      > The story of freebsd & erlang "needing" to be patched seems to be greatly exaggerated. The story is greatly underreported and all focus is only on "they run Whatsapp on Erlang with just ~50 engineers". Highscalability lists just some of the patches and optimisations they have here [1] and here [2] Here's an incomplete list of patches only. There's also tuning and optimisation: Erlang: Fixed head-of-line blocking in async file IO by patching BEAM, added round-robin scheduling for async file IO, added multiple instrumentation patches. Instrumented scheduler to get utilization information, statistics for message queues, number of sleeps, send rates, message counts, etc. Made lock counting work for larger async thread counts. Patched to dial down spin counts so the scheduler wouldn’t spin. BSD: Backported a TSE time counter. Backported igp network driver. More Mnesia (Erlang) patches discussed here: [3] Are you ready to do this for your Whatsapp? > elixir/phoenix also achieved the same "2 million connections on single server" without needing those optimizations. There's more needed to run a chat server than just "2 million empty connections". --- [1] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi... [2] http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-... [3] https://www.infoq.com/presentations/whatsapp-scalability/ https://www.infoq.com/presentations/whatsapp-scalability/
      - fouc 7y ago
        >Are you ready to do this for your Whatsapp? I don't need to thanks to the fact that a bunch of those patches are now part of Erlang.
        7y ago
rapsey 7y ago
Erlang's advantage is being able to build a featureful, secure, scalable and performant enough communication backend in very little time and effort. This is a niche in which it can not be beaten.
- 0xFACEFEED 7y ago
  Time/effort/security/performance, really? IIRC the reasons to consider Erlang is purely to do with building a fault tolerant highly distributed system.
  - rapsey 7y ago
    You are missing the forest for the trees.
  - vim-guru 7y ago
    This. And it's ability to be introspected in realtime. It has a REPL-experience very much like lisp's do
    - ailideex 7y ago
      Not sure what you mean by introspection in real time ... but if you mean runtime introspection this is not that much of a niche feature. If you mean remote debugging, again not that much of a niche feature. JVM and Javascript provides both.
  - dnautics 7y ago
    I would say that at least the elixir ecosystem puts a very high priority on making sane security very easy, especially Phoenix and nerves
- otabdeveloper4 7y ago
  > ...in very little time and effort. You have a very naive view of large-scale distributed systems. For companies that truly need them, "time" and "effort" are never a consideration. Furthermore, the challenges facing these companies in battling project delays and cost overruns are the 100% organizational and political, not technical.
toast0 7y ago
You can absolutely do anything you can do in Erlang in another language. Some tasks will be easier, or harder, however. In my mind, Erlang excels in a few ways: Less often remarked, binary parsing in Erlang is rather nice. Parsing out an IPv4 packet looks like this: <<4:4, IHL:4, _DSCP:6, _ECN:2, _TotalLength:16, _Id:16, 0:1, _DF:1, MF:1, FragmentOffset:13, _TTL:8, Protocol:8, _IPChksum:16, SrcIP:4/binary, DestIP:4/binary, IPRest/binary>> = Payload, OptsSize = (IHL - 5) * 4, <<_IPOptions:OptsSize/binary, IPPayload/binary>> = IPRest, And then you've got everything. As long as formats are reasonably documented, it's easy to parse them. Sometimes, you can even parse a size and use the size in the same match. More often remarked; because of the language constraints, most notably a lack of shared memory between processes and immutable variables, most programming ideas end up expressed in a way that's amenable to massive concurrency, while being comprehensible. Most Actors have easy to understand behavior --- they may accept messages, leading to them sending messages and changing their internal state. From there, you may need to puzzle out the overall system behavior, but often times, getting each individual Actor's behavior correct, leads to correct (if hard to verify) system behavior. Hot loading code reduces deployment time, which increases developer productivity. When you've got a million users connected to a machine, it takes a lot of time to move them to other machines so you can do a traditional stop / start cycle; hot loading means you can fix things in seconds (and, of course, it means you can break things in seconds too). You can, of course, hotload in C, and probably other languages, but very few people do it. It's comparable to pushing PHP files though. And, of course, the most important thing is ejabberd is in Erlang, and it looks like it has what we need for a chat server, and I heard some other people scaled it really far. ;)
- samvher 7y ago
  To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
  - fouc 7y ago
    Why would they avoid that? (hopefully it's not just because of the ease of containerization/docker that is leading to reduced hot loading)

The fact that the entire ecosystem is based around the actor model is one of the primary ones. It's allowed for code that isn't simply a library, but effectively an entire application, to be used as open source to be dumped into your system, because it has tools like Erlang Term Storage, Mnesia, and other devices to make it easy.

hota_mazi 7y ago
You're still not explaining why this allows to do things that can't be done in other languages. Probably because that claim makes no sense.
- nathanappere 7y ago
  Reductions. How do you ensure in other languages (or in other VMs) that every actor will get the same cpu time and that none can block the others? That's a tricky problem to solve as a lib.

atupis 7y ago

I think Whatsapp served "at peak" like 450 million users with only 32 engineers.

dmitriid 7y ago
Whatsapp also had multiple patches to Erlang VM, backported FreeBSD drivers and code etc. etc. Do not assume you'll be able to build your own Whatsapp just because of Erlang.
- fouc 7y ago
  The story of freebsd & erlang "needing" to be patched seems to be greatly exaggerated. Especially when it turns out that elixir/phoenix also achieved the same "2 million connections on single server" without needing those optimizations.
  - dmitriid 7y ago
    > The story of freebsd & erlang "needing" to be patched seems to be greatly exaggerated. The story is greatly underreported and all focus is only on "they run Whatsapp on Erlang with just ~50 engineers". Highscalability lists just some of the patches and optimisations they have here [1] and here [2] Here's an incomplete list of patches only. There's also tuning and optimisation: Erlang: Fixed head-of-line blocking in async file IO by patching BEAM, added round-robin scheduling for async file IO, added multiple instrumentation patches. Instrumented scheduler to get utilization information, statistics for message queues, number of sleeps, send rates, message counts, etc. Made lock counting work for larger async thread counts. Patched to dial down spin counts so the scheduler wouldn’t spin. BSD: Backported a TSE time counter. Backported igp network driver. More Mnesia (Erlang) patches discussed here: [3] Are you ready to do this for your Whatsapp? > elixir/phoenix also achieved the same "2 million connections on single server" without needing those optimizations. There's more needed to run a chat server than just "2 million empty connections". --- [1] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi... [2] http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-... [3] https://www.infoq.com/presentations/whatsapp-scalability/ https://www.infoq.com/presentations/whatsapp-scalability/
    - fouc 7y ago
      >Are you ready to do this for your Whatsapp? I don't need to thanks to the fact that a bunch of those patches are now part of Erlang.
      - 7y ago

rapsey 7y ago

Erlang's advantage is being able to build a featureful, secure, scalable and performant enough communication backend in very little time and effort. This is a niche in which it can not be beaten.

0xFACEFEED 7y ago
Time/effort/security/performance, really? IIRC the reasons to consider Erlang is purely to do with building a fault tolerant highly distributed system.
- rapsey 7y ago
  You are missing the forest for the trees.
- vim-guru 7y ago
  This. And it's ability to be introspected in realtime. It has a REPL-experience very much like lisp's do
  - ailideex 7y ago
    Not sure what you mean by introspection in real time ... but if you mean runtime introspection this is not that much of a niche feature. If you mean remote debugging, again not that much of a niche feature. JVM and Javascript provides both.
- dnautics 7y ago
  I would say that at least the elixir ecosystem puts a very high priority on making sane security very easy, especially Phoenix and nerves
otabdeveloper4 7y ago
> ...in very little time and effort. You have a very naive view of large-scale distributed systems. For companies that truly need them, "time" and "effort" are never a consideration. Furthermore, the challenges facing these companies in battling project delays and cost overruns are the 100% organizational and political, not technical.

toast0 7y ago

You can absolutely do anything you can do in Erlang in another language. Some tasks will be easier, or harder, however. In my mind, Erlang excels in a few ways: Less often remarked, binary parsing in Erlang is rather nice. Parsing out an IPv4 packet looks like this: <<4:4, IHL:4, _DSCP:6, _ECN:2, _TotalLength:16, _Id:16, 0:1, _DF:1, MF:1, FragmentOffset:13, _TTL:8, Protocol:8, _IPChksum:16, SrcIP:4/binary, DestIP:4/binary, IPRest/binary>> = Payload, OptsSize = (IHL - 5) * 4, <<_IPOptions:OptsSize/binary, IPPayload/binary>> = IPRest, And then you've got everything. As long as formats are reasonably documented, it's easy to parse them. Sometimes, you can even parse a size and use the size in the same match. More often remarked; because of the language constraints, most notably a lack of shared memory between processes and immutable variables, most programming ideas end up expressed in a way that's amenable to massive concurrency, while being comprehensible. Most Actors have easy to understand behavior --- they may accept messages, leading to them sending messages and changing their internal state. From there, you may need to puzzle out the overall system behavior, but often times, getting each individual Actor's behavior correct, leads to correct (if hard to verify) system behavior. Hot loading code reduces deployment time, which increases developer productivity. When you've got a million users connected to a machine, it takes a lot of time to move them to other machines so you can do a traditional stop / start cycle; hot loading means you can fix things in seconds (and, of course, it means you can break things in seconds too). You can, of course, hotload in C, and probably other languages, but very few people do it. It's comparable to pushing PHP files though. And, of course, the most important thing is ejabberd is in Erlang, and it looks like it has what we need for a chat server, and I heard some other people scaled it really far. ;)

samvher 7y ago
To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
- fouc 7y ago
  Why would they avoid that? (hopefully it's not just because of the ease of containerization/docker that is leading to reduced hot loading)