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?
Ask HN: Erlang and the telecom market
41–50 of 59 posts
Re: Ask HN: Erlang and the telecom market
#42The 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.
Re: Ask HN: Erlang and the telecom market
#43Earlier 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…
Think hyperscaler-style SDN, but largely on-premises.
Re: Ask HN: Erlang and the telecom market
#44Quoted post unavailable.
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.
Re: Ask HN: Erlang and the telecom market
#45Also, Elixir subsystems in Erlang are common, so projecting ones preferences onto an employer may earn less utility or more ire.
Best of luck =)
Re: Ask HN: Erlang and the telecom market
#46This 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…
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
#47Earlier 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.
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
#48I 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
#49Earlier 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.
Re: Ask HN: Erlang and the telecom market
#50The 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…