Live data from Hacker News

Ask HN: Erlang and the telecom market

news.ycombinator.com

41–50 of 59 posts

Re: Ask HN: Erlang and the telecom market

#41
post #12

The generalist view is that nobody is using Erlang for modern telco workloads anymore. (yes, there are exceptions. Bear with me) I learned Erlang when we were programming Ericsson voice switches some twenty years ago, and even though Nokia also adopted OTP and did some pretty amazing things with it (including a Hadoop analogue that used Erlang to coordinate Python workers across nodes), I have only come across Erlang…

I used to experiment a bunch with GPU passthrough to VMs and also found that CPU pinning was required to avoid stutters. I always found it unfortunate as pinning works directly against what one tries to achieve with virtualization (i.e. sharing of resources). I had never considered telecom suffering from the same issue. Do you know if there's been any work to improve scheduling to mitigate this requirement?

There are other issues at play, such as the need for SR-IOV support and sometimes direct mapping of PCI lanes to some workloads. There is only so much virtualization can do when you're letting millions of sessions through.

Re: Ask HN: Erlang and the telecom market

#42
post #12

The generalist view is that nobody is using Erlang for modern telco workloads anymore. (yes, there are exceptions. Bear with me) I learned Erlang when we were programming Ericsson voice switches some twenty years ago, and even though Nokia also adopted OTP and did some pretty amazing things with it (including a Hadoop analogue that used Erlang to coordinate Python workers across nodes), I have only come across Erlang…

Are there any good reading on modern work being done in telecom networks. I enjoyed this comment and have had a passing interest in the industry, but have been unable to understand modern networks so far.

You can try digging into modern 5G stacks. Search for VNF/CNF, be wary of the fact that it is a much deeper industry acronym-wise (heck, we have 4 and 5 letter acronyms that are not jokes), and hang on to your hat...

Re: Ask HN: Erlang and the telecom market

#43

Earlier quoted context omitted.

Are you saying BEAM introduces too much latency and/or jitter for telco workloads? This surprises me. I would have thought that if anything BEAM should be pretty efficient for network I/O. Also what would be the causes of unacceptable jitter? The runtime itself is designed to avoid things like long gc pauses - is it that you end up having to migrate elixir processes between BEAM scheduler cores?

I don't think latency and jitter are big issues. If you're imagining VOIP packets flowing through the Erlang app, it's more likely that they are routed by hardware at a lower level. The Erlang app controls the lower level switches. I don't know about Ericsson switches in particular, but I've worked on telecom stuff (not programmed in Erlang, unfortunately) and that's how it worked. The low level routing was done by F…

You'd be surprised exactly how much functionality is written in vanilla C and pushed down the stack to raw packet handling. There is hardware acceleration in NICs, but voice is actually a tiny, almost insignificant amount of the workloads involved in some parts of the world.

Think hyperscaler-style SDN, but largely on-premises.

Re: Ask HN: Erlang and the telecom market

#44
post #25

Quoted post unavailable.

> Elixir is not Erlang [..] its variables are mutable etc.

It is factually untrue that Elixir's variables are mutable. What you're likely confused about is "variable shadowing" and in functional languages where values are immutable (and they are immutable in Elixir as well as Erlang) it's a very common pattern.

https://en.wikipedia.org/wiki/Variable_shadowing

Re: Ask HN: Erlang and the telecom market

#46
post #13

This is the problem I have with Erlang developers. They only want to work on Erlang. Pragmatism be damned. It is never about the product or the company. It is only about which of the remaining 20 Erlang expert personalities in the world do they get to work alongside with. If there needs to be a special library, all other existing ones are garbage unless written by one of the 20 above, so they will just write their ow…

> If your company decides to pivot away from Erlang to another more accessible language, say Go, you are likely to lose them all.

I was sympathizing until that final sentence. I'm not an Erlang programmer, but from what I know about both Erlang and Go, that seems like a terrible jump to make. Of course it depends on other circumstances in this hypothetical as well, but I probably would at least take this as an opportunity to reevaluate my current working situation as well.

Re: Ask HN: Erlang and the telecom market

#47

Earlier quoted context omitted.

"Yes, we are going to make your job six times less efficient and substantially more difficult, while simultaneously removing your main incentive for working here. No, you will not receive a raise or any other form of olive branch from us, management, in exchange for the fact that we have measurably reduced your quality of life. No, we are not negotiating this." If any job I ever had did this, technical or otherwise,…

I think this comment actually unintentionally is reinforcing his point. Other programming languages than Erlang exist for a reason, they're not just fun toy languages for low IQ folks. There are tons of reasons why Erlang may not be a good fit for some project, and one of these other lesser languages would be a better fit, and he doesn't want to work with people who wouldn't even consider something like that.

> There are tons of reasons why Erlang may not be a good fit for some project, and one of these other lesser languages would be a better fit

But that's not what they said. The statement was literally "to pivot away from erlang". Imagine you are working with, say, python (which I don't really like but it's a popular example) and were forced to switch to Visual Basic.

Re: Ask HN: Erlang and the telecom market

#48
I wouldn't be too quick to be down on Elixir. The entire BEAM ecosystem (Erlang, Elixir, Gleam, Luerl, LFE etc) are great! I think one could potentially sneak some Erlang into an Elixir job by building common libraries you want to share with other programming languages across the BEAM.

I don't get the hate for Erlang, either. It's a fun language with a community very willing to help folks out.

Re: Ask HN: Erlang and the telecom market

#49

Earlier quoted context omitted.

"Yes, we are going to make your job six times less efficient and substantially more difficult, while simultaneously removing your main incentive for working here. No, you will not receive a raise or any other form of olive branch from us, management, in exchange for the fact that we have measurably reduced your quality of life. No, we are not negotiating this." If any job I ever had did this, technical or otherwise,…

I think this comment actually unintentionally is reinforcing his point. Other programming languages than Erlang exist for a reason, they're not just fun toy languages for low IQ folks. There are tons of reasons why Erlang may not be a good fit for some project, and one of these other lesser languages would be a better fit, and he doesn't want to work with people who wouldn't even consider something like that.

I don't even like Erlang. I'm just pointing out that removing the main incentive for being there for an employee without giving them something in return is naturally going to cause them to bail. You don't spit in a person's face and expect them to be happy about it.

Re: Ask HN: Erlang and the telecom market

#50
post #12

The generalist view is that nobody is using Erlang for modern telco workloads anymore. (yes, there are exceptions. Bear with me) I learned Erlang when we were programming Ericsson voice switches some twenty years ago, and even though Nokia also adopted OTP and did some pretty amazing things with it (including a Hadoop analogue that used Erlang to coordinate Python workers across nodes), I have only come across Erlang…

Thank you for your input, I was thinking that with all the 5g decoupling,network functions and messages passing Erlang would go stronger and need more workforce
Post reply on HN