5 ms·

Is Erlang about to be the next big thing due to companies unable to use Huawei and instead going with Ericsson for 5G deployment?

by j_m_b 6y ago

s3cur3 6y ago
The Erlang ecosystem (including my personal favorite BEAM language, Elixir) has been kind of a secret weapon for a lot of companies for years. There are a handful of freelancers in the community who have had the experience of going to work for a company doing Erlang/Elixir, only to be told they can never reveal the company’s identity because they consider the language a competitive advantage. One big corp went so far as to say they use Java in all their public-facing info (including hiring).
- apta 6y ago
  What does Erlang offer that the JVM or .NET don't?
  - yawaramin 6y ago
    Check out the OP.
  - dnautics 6y ago
    The concept of failure domains is baked into the runtime, and not an afterthought.
  - smabie 6y ago
    While there is actor support through Akka and Akka.net on the JVM and .NET, neither of them support preemption like the BEAM does. Preemption of blocking actors is a game-changer in terms of how you write and structure concurrent code. I wrote a BitTorrent client in Scala using Akka and found myself desperately wishing that I could write actors in a blocking style. The amount of extra complexity and book-keeping required to write purely non-blocking actors is truly staggering. Let me give you an example. I have an actor that asks for two objects from a DbActor, and then sends them to the AdderActor to get the sum. Without preemption, I have to do the following. 1. Send a message to get object A and object B. Return. 2. Wait for an object. 3. When I get the object, figure out if it is object A or B (or maybe it's something else entirely). Update internal state so that I know I need one more object. Return. 4. Wait for an object 5. Get the object, figure out if it is object A or B (or something else). Update internal state so I know that I have both objects. Send the two objects and my Add message to the AdderActor. Return. 6. Wait for the result. 7. Now that I've gotten the result, update internal state saying that I've completed my A+B operation. Either store the result of A+B or whatever. This method requires a lot of internal booking and a lot of mutable hash tables in order to keep track of all the various stuff this actor is in the process of doing. If I'm trying to calculate A+B and C+D, I need to know how far along I am in each computation. This is a buggy and annoying process that creates a ton of complexity. Let's look at how we could do it in Erlang: 1. Send a message saying we want object A. 2. Don't return, and instead block until we get A. Now we ask for B. 3. Block until we get B. Now send the A+B message. 4. Block until we get it. Do something. Return. See how much easier this is? Because we can block, our code actually can be structured to look like normal, non-concurrent code. It can be executed in a sequential fashion, even though the actual computation is happening somewhere else. With Akka and Akka.net, we can't do that. We have to return as quickly as possible, or else we are going to lock up the entire system. This means that all of the implicit state that a normal program has (like current line being executed), must be stored explicitly by our program. It sucks, but hopefully the JVM will get preemption sometime soon. The actor model doesn't really work with out it. And even though it doesn't work without it, it's still better than threads and mutexes.
    - apta 6y ago
      As you point out, the JVM is getting preemption by means of Loom. .NET already has coroutines (async/await) so it should already do what you stated.
      - smabie 6y ago
        I'm not super familiar with .NET, but if it supports preemption, they why this? https://getakka.net/articles/concepts/actor-systems.html#blocking-needs-careful-management https://getakka.net/articles/concepts/actor-systems.html#blo... Coroutines in general are a form of cooperative multi-tasking (they must explicitly yield), but I might missing something about .NET's implementation.
        apta 6y ago
        It is specific to blocking APIs, as per the page: > Examples are legacy RDBMS drivers or messaging APIs, and the underlying reason is typically that (network) I/O occurs under the covers The issue with async/await is that APIs need to be extended with their async counterparts. If they don't, then you have to be sure not to invoke blocking calls. Java won't have this issue as the runtime will take care of preemption.
    - sbalea 6y ago
      In Scala/Akka, you could use the ask operator and compose the resulting Futures, something like this: for { a <- aProviderActor ? gimmeA b <- bProviderActor ? gimmeB aPlusB <- adderActor ? (add, a, b) } yield aPlusB
      - smabie 6y ago
        Yeah, but you're blocking the thread. It's very very easy for you to deadlock the entire system writing code like this.
- enraged_camel 6y ago
  I'll just come out and say that this is true for us at PriceTable. :) I've used Rails, Node.js and .NET before this, and none of them came close to Elixir in terms of developer productivity, not to mention system stability.
- gjvc 6y ago
  http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html still holds true.
  - bobbyz 6y ago
    Does it though? StackOverflow's predecessor was created one year after this was written, meaning it was likely written in an environment without SO. Easily finding the solution to your every problem is the ultimate programming language feature.
- ativzzz 6y ago
  How much of this actually has to do with using the language? Unless the companies are solving very specific technical problems that Erlang/Elixir are designed to solve, what really matters is productive software devs and managers, and that is more defined by expertise and domain knowledge in a particular language than the language itself (within reason: you're not going to choose C over Ruby for a web app backend). How much of this is due to (the minority of) devs that can code Erlang/Elixir being more experienced/productive regardless of the language? Or just having good tech management?
- andrewflnr 6y ago
  I've heard this before, and despite my cautiously being on the Elixir bandwagon, this story triggers my BS sensor. Assuming their competitors are already invested in another language, it will be expensive for them to switch, and the company using Erlang/Elixir gets good press from using a hipster language. Can someone point to specific people that said they were barred from revealing their BEAM-using employer?
jlouis 6y ago
Arguably, it already is all over the place in telecommunication. But indeed, Huawei being somewhat limited could push more people to buy Ericsson equipment, where a large part of it uses Erlang. It is strong in the area because you have the perfect storm of large complex protocols bundled with the need for very high reliability and robustness of systems. Few languages does that particular mix as well as Erlang.
- jmiskovic 6y ago
  I've spent two years with them and didn't see Erlang anywhere. It was occasionally mentioned as obscure thing you are forced to do in some other department, while rest considered themselves lucky to be using C++. There were also teams doing Java, Python, JS, Matlab, roughly in that order of popularity.
danfritz 6y ago
Its already the biggest thing ever, but nobody knows it. 90% of the Internet nodes is controlled by erlang code [1] Edit: it's indeed controlled nodes and not code [1] https://thenewstack.io/why-erlang-joe-armstrongs-legacy-of-fault-tolerant-computing/ https://thenewstack.io/why-erlang-joe-armstrongs-legacy-of-f...
- WJW 6y ago
  If you use "passes through" as a standard, surely C would be the biggest thing ever since Linux+BSD+Windows make up way more than 99% of operating systems and those are all written in C.
  - danfritz 6y ago
    Ha yes fair point! I mainly wanted to indicate that it's used more than people think. It's the backbone of telecom
    - bobbyz 6y ago
      Erlang: Cobol/Telecom: Banks/Internet: Money
  - ori_b 6y ago
    C is definitely bigger than people assume.
  - pjmlp 6y ago
    Windows has also a good part of C++ and we all know Microsoft's stance on keeping C compilers around.
- ramchip 6y ago
  It’s not exactly what the quote says - 90% of the traffic goes through nodes _controlled by Erlang_. See: https://news.ycombinator.com/item?id=17218190 https://news.ycombinator.com/item?id=17218190
  - 6y ago
gregors 6y ago
I highly suggest looking at Elixir. It makes things much better in my opinion. Some takes from one of the inventors of Erlang on Elixir https://joearms.github.io/published/2013-05-31-a-week-with-elixir.html https://joearms.github.io/published/2013-05-31-a-week-with-e... tl;dr "It didn't take long, but pretty soon my gut feeling kicked in. This is good shit"
- danfritz 6y ago
  Elixir is the only language that really blew my mind in its capabilities while still using a readable and fairly easy syntax. Everything is just thinking in terms of message passing between lightweight processes
brink 6y ago
My latest project is in Elixir after going through Rust and Python as candidates. Erlang / Elixir isn't the best candidate for _everything_, but I will be using it in the future for just about everything I can because of how much I like it.
dnautics 6y ago
I don't think ericsson really uses erlang that much internally.
- mononcqc 6y ago
  They do. It’s part of control planes for their next 5G stacks.
swinglock 6y ago
I don't see why it would matter. You're not going to see more or less Erlang anywhere, not even at Ericsson, due to Ericsson getting more or less business. The software will be written regardless as long as there's some business and you're not going to notice outside Ericsson either way. Besides, Huawei is free to use Erlang too. It stopped being Ericsson proprietary a long time ago.

Is Erlang about to be the next big thing due to companies unable to use Huawei and instead going with Ericsson for 5G deployment?

by j_m_b 6y ago

Is Erlang about to be the next big thing due to companies unable to use Huawei and instead going with Ericsson for 5G deployment?

s3cur3 6y ago

The Erlang ecosystem (including my personal favorite BEAM language, Elixir) has been kind of a secret weapon for a lot of companies for years. There are a handful of freelancers in the community who have had the experience of going to work for a company doing Erlang/Elixir, only to be told they can never reveal the company’s identity because they consider the language a competitive advantage. One big corp went so far as to say they use Java in all their public-facing info (including hiring).

apta 6y ago
What does Erlang offer that the JVM or .NET don't?
- yawaramin 6y ago
  Check out the OP.
- dnautics 6y ago
  The concept of failure domains is baked into the runtime, and not an afterthought.
- smabie 6y ago
  While there is actor support through Akka and Akka.net on the JVM and .NET, neither of them support preemption like the BEAM does. Preemption of blocking actors is a game-changer in terms of how you write and structure concurrent code. I wrote a BitTorrent client in Scala using Akka and found myself desperately wishing that I could write actors in a blocking style. The amount of extra complexity and book-keeping required to write purely non-blocking actors is truly staggering. Let me give you an example. I have an actor that asks for two objects from a DbActor, and then sends them to the AdderActor to get the sum. Without preemption, I have to do the following. 1. Send a message to get object A and object B. Return. 2. Wait for an object. 3. When I get the object, figure out if it is object A or B (or maybe it's something else entirely). Update internal state so that I know I need one more object. Return. 4. Wait for an object 5. Get the object, figure out if it is object A or B (or something else). Update internal state so I know that I have both objects. Send the two objects and my Add message to the AdderActor. Return. 6. Wait for the result. 7. Now that I've gotten the result, update internal state saying that I've completed my A+B operation. Either store the result of A+B or whatever. This method requires a lot of internal booking and a lot of mutable hash tables in order to keep track of all the various stuff this actor is in the process of doing. If I'm trying to calculate A+B and C+D, I need to know how far along I am in each computation. This is a buggy and annoying process that creates a ton of complexity. Let's look at how we could do it in Erlang: 1. Send a message saying we want object A. 2. Don't return, and instead block until we get A. Now we ask for B. 3. Block until we get B. Now send the A+B message. 4. Block until we get it. Do something. Return. See how much easier this is? Because we can block, our code actually can be structured to look like normal, non-concurrent code. It can be executed in a sequential fashion, even though the actual computation is happening somewhere else. With Akka and Akka.net, we can't do that. We have to return as quickly as possible, or else we are going to lock up the entire system. This means that all of the implicit state that a normal program has (like current line being executed), must be stored explicitly by our program. It sucks, but hopefully the JVM will get preemption sometime soon. The actor model doesn't really work with out it. And even though it doesn't work without it, it's still better than threads and mutexes.
  - apta 6y ago
    As you point out, the JVM is getting preemption by means of Loom. .NET already has coroutines (async/await) so it should already do what you stated.
    - smabie 6y ago
      I'm not super familiar with .NET, but if it supports preemption, they why this? https://getakka.net/articles/concepts/actor-systems.html#blocking-needs-careful-management https://getakka.net/articles/concepts/actor-systems.html#blo... Coroutines in general are a form of cooperative multi-tasking (they must explicitly yield), but I might missing something about .NET's implementation.
      - apta 6y ago
        It is specific to blocking APIs, as per the page: > Examples are legacy RDBMS drivers or messaging APIs, and the underlying reason is typically that (network) I/O occurs under the covers The issue with async/await is that APIs need to be extended with their async counterparts. If they don't, then you have to be sure not to invoke blocking calls. Java won't have this issue as the runtime will take care of preemption.
  - sbalea 6y ago
    In Scala/Akka, you could use the ask operator and compose the resulting Futures, something like this: for { a <- aProviderActor ? gimmeA b <- bProviderActor ? gimmeB aPlusB <- adderActor ? (add, a, b) } yield aPlusB
    - smabie 6y ago
      Yeah, but you're blocking the thread. It's very very easy for you to deadlock the entire system writing code like this.
enraged_camel 6y ago
I'll just come out and say that this is true for us at PriceTable. :) I've used Rails, Node.js and .NET before this, and none of them came close to Elixir in terms of developer productivity, not to mention system stability.
gjvc 6y ago
http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html still holds true.
- bobbyz 6y ago
  Does it though? StackOverflow's predecessor was created one year after this was written, meaning it was likely written in an environment without SO. Easily finding the solution to your every problem is the ultimate programming language feature.
ativzzz 6y ago
How much of this actually has to do with using the language? Unless the companies are solving very specific technical problems that Erlang/Elixir are designed to solve, what really matters is productive software devs and managers, and that is more defined by expertise and domain knowledge in a particular language than the language itself (within reason: you're not going to choose C over Ruby for a web app backend). How much of this is due to (the minority of) devs that can code Erlang/Elixir being more experienced/productive regardless of the language? Or just having good tech management?
andrewflnr 6y ago
I've heard this before, and despite my cautiously being on the Elixir bandwagon, this story triggers my BS sensor. Assuming their competitors are already invested in another language, it will be expensive for them to switch, and the company using Erlang/Elixir gets good press from using a hipster language. Can someone point to specific people that said they were barred from revealing their BEAM-using employer?

jlouis 6y ago

Arguably, it already is all over the place in telecommunication. But indeed, Huawei being somewhat limited could push more people to buy Ericsson equipment, where a large part of it uses Erlang. It is strong in the area because you have the perfect storm of large complex protocols bundled with the need for very high reliability and robustness of systems. Few languages does that particular mix as well as Erlang.

jmiskovic 6y ago
I've spent two years with them and didn't see Erlang anywhere. It was occasionally mentioned as obscure thing you are forced to do in some other department, while rest considered themselves lucky to be using C++. There were also teams doing Java, Python, JS, Matlab, roughly in that order of popularity.

danfritz 6y ago

Its already the biggest thing ever, but nobody knows it. 90% of the Internet nodes is controlled by erlang code [1] Edit: it's indeed controlled nodes and not code [1] https://thenewstack.io/why-erlang-joe-armstrongs-legacy-of-fault-tolerant-computing/ https://thenewstack.io/why-erlang-joe-armstrongs-legacy-of-f...

WJW 6y ago
If you use "passes through" as a standard, surely C would be the biggest thing ever since Linux+BSD+Windows make up way more than 99% of operating systems and those are all written in C.
- danfritz 6y ago
  Ha yes fair point! I mainly wanted to indicate that it's used more than people think. It's the backbone of telecom
  - bobbyz 6y ago
    Erlang: Cobol/Telecom: Banks/Internet: Money
- ori_b 6y ago
  C is definitely bigger than people assume.
- pjmlp 6y ago
  Windows has also a good part of C++ and we all know Microsoft's stance on keeping C compilers around.
ramchip 6y ago
It’s not exactly what the quote says - 90% of the traffic goes through nodes _controlled by Erlang_. See: https://news.ycombinator.com/item?id=17218190 https://news.ycombinator.com/item?id=17218190
- 6y ago

gregors 6y ago

I highly suggest looking at Elixir. It makes things much better in my opinion. Some takes from one of the inventors of Erlang on Elixir https://joearms.github.io/published/2013-05-31-a-week-with-elixir.html https://joearms.github.io/published/2013-05-31-a-week-with-e... tl;dr "It didn't take long, but pretty soon my gut feeling kicked in. This is good shit"

danfritz 6y ago
Elixir is the only language that really blew my mind in its capabilities while still using a readable and fairly easy syntax. Everything is just thinking in terms of message passing between lightweight processes

brink 6y ago

My latest project is in Elixir after going through Rust and Python as candidates. Erlang / Elixir isn't the best candidate for _everything_, but I will be using it in the future for just about everything I can because of how much I like it.

dnautics 6y ago

I don't think ericsson really uses erlang that much internally.

mononcqc 6y ago
They do. It’s part of control planes for their next 5G stacks.

swinglock 6y ago

I don't see why it would matter. You're not going to see more or less Erlang anywhere, not even at Ericsson, due to Ericsson getting more or less business. The software will be written regardless as long as there's some business and you're not going to notice outside Ericsson either way. Besides, Huawei is free to use Erlang too. It stopped being Ericsson proprietary a long time ago.