I gave an Erlang talk many years ago where I used the Tandem architecture as a comparison point, and one of the attendees happened to have worked on them.
I really should chase down the other references for further reading.
RIP, Joe. You were one of a kind.
whoknowsidont 14 hours ago [-]
Erlang (and quite frankly Elixir) really has always seemed like it was, in some form, ahead of its time. I really hope it spikes in popularity.
Any day now...
pjmlp 9 hours ago [-]
I am happy enough to have its ideas infect .NET and Java systems, Akka and Orleans.
As I learned with Lisp, ML, Prolog, Smalltalk since the mid-80's, and safer systems languages as well, it is easier to eventually get some of the goodies, than trying to push for the whole thing.
Unfortunely that is how our industry works, until liabily becomes common, the lesser options will always win the market.
fzeindl 13 hours ago [-]
It won‘t but I don‘t get why. The thesis is genius, it even starts with an philosophy and an attempt to formalize software architecture.
Erlang was invented at Ericsson, used for certain phone switches, it was tremendously successful at what it was built to do, and still it‘s not used anymore in their newer switches.
Why?
djtango 13 hours ago [-]
Whatsapp (and IIRC Wechat) were built in Erlang. I think Discord is also Elixir/Rust
My take is that when the advantage to be gained is a superior architecture or set of abstractions that can be built by a small core of engineers then language choice can be an advantage. When the business needs to scale into the real world long tail of integrations, infrastructure, clients etc then throwing bodies at the problem can be an advantage and then ecosystem and talent pool outweigh original language gains.
Sharp tools are at their best in a smaller more focused team... But in software, building the right architecture can in some cases be all the difference
zer00eyz 7 hours ago [-]
You're talking about two products and two companies with (initially, and still core) well defined domains.
The languages, the architectural choices, that were made by these orgs early on were allowed to "stick". There was no move fast break things, there were no pivots, there wasn't a massive cycle of "market discovery", no figuring out "product market fit".
They could have built in PHP, or Ruby, Or brain fuck and been successful I suspect. Talent and a steady hand at the helm are playing the outsized roles here.
toast0 5 hours ago [-]
Nit: WhatsApp was built in PHP and then people started chatting in status messages. Pivoting to be a chat system may not have been a massive pivot, but it was still a pivot.
Chat was added by running ejabberd[1], and the rest of the services (registration, status, sync) remained in PHP for some time, MMS was added as a PHP service. Services migrated to Erlang over time.
[1] Need chat? Run ejabberd is a gateway drug to running Erlang. Happened lots of places, but some then rewrite chat in another language later.
nothrabannosir 7 hours ago [-]
> They could have built in PHP, or Ruby, Or brain fuck and been successful I suspect.
I’ve seen enough to doubt this. The less capable a tool the higher the overhead, until you reach that critical point where you spend more time managing overhead than adding features. It’s a self reinforcing cycle which makes it exponential , and it happens more quickly than people like to admit. You have to start hiring, and hiring is always a disappointment, you grow teams, communication overhead takes over, you inevitably model the product after the organization, you start making engineering choices based on realities of the hiring market, the realization sets in that “easier to hire for” is a double edged sword as talent pools differ not just in size but also quality, your organization and tech stack ossify, and suddenly you’re in the stink.
In fact I’ve never not seen this happen.
Case In point: You flippantly added brainfuck to your list there. But obviously not: clearly you can’t build WhatsApp in brainfuck and win the market. So here we are already: there is a limit. Why, then, should ruby or PHP be on the other side of that limit?
I doubt it.
AceJohnny2 9 hours ago [-]
> It won‘t but I don‘t get why.
Remember that Erlang was open-sourced as a last-ditch effort to save it, in 1998, after Ericsson internally switched to C++ and banned using Erlang on new products.
The sad fact is that the software industry as a whole relies heavily on mainstream languages, and not on educating your engineers to leverage the strengths of your specialty language. There's rationale to that, in that it costs a ton to maintain your own platform when you can just leverage a more public one. As a random example, why spend a ton to try and optimize your compiled language when you can... just use GCC (or clang nowadays). See: ongoing complaints about the performance of Go.
Erlang's silver lining is it found some measure of success outside of Ericsson, which led it to being unbanned there (and the banner to being "promoted sideways")
mamcx 3 hours ago [-]
> it costs a ton to maintain your own platform
Truly? And considering here the option is C++?
I truly asking, how much cost is this, have been measured?
I suspect is like the issue with fail to measure the whole thing and is just like "my guys that work in the platform also work making my apps and fixing my printer, so when they work in the platform I can`t print" kind of situation, instead of "I have a platform team (that could be like very small) and a apps team, and I ditch the printer in the bin" that I suspect is just reorg correctly the same amount of people.
fzeindl 6 hours ago [-]
> The sad fact is that the software industry as a whole relies heavily on mainstream languages, and not on educating your engineers to leverage the strengths of your specialty language.
That is an excellent remark.
tl 5 hours ago [-]
> The sad fact is that the software industry as a whole relies heavily on mainstream languages, and not on educating your engineers to leverage the strengths of your specialty language.
Except when the language is the workhorse of a proprietary product sold to your employer. SQL is the example that escaped into the open world, but see also MATLAB and Excel formulae/VBA.
mikaraento 5 hours ago [-]
IIRC it was never used for any voice/call switching. I think it was used in one (line of) ATM switch(es).
sudohalt 12 hours ago [-]
because the benefits aren't that much greater, and great features in languages like erlang and haskell end up (to some extent) in popular languages (which further reduces the need to adopt such languages)
fzeindl 7 hours ago [-]
I agree, but the main feature isn’t the language, but the BEAM VM.
As far as I know there‘s no other language which focussed from the get-go on parallel, distributed deployment, has processes as first class primitives, supports hot code swapping etc.
igouy 33 minutes ago [-]
Well afaik is an argument based on lack of evidence.
And why does from the get-go on parallel matter? Wouldn't it be OK if the initial focus was something else and then there was a change of focus?
> Wouldn't it be OK if the initial focus was something else and then there was a change of focus?
Retrofitting features into existing languages is rarely satisfying in my experience.
Sure, Python now has functional constructs, but variables are still mutable, so bizarre things can happen inside a map call.
In Erlang, immutability is baked into everything.
Message passing can be added as a library, but you don’t get the same impact as everything being a message. Does your random 3rd party library also use messages? Probably not.
Erlang is a very opinionated language and runtime with a small set of core concepts, and it is very predictable as a consequence.
Java or C++ have just about any feature you can think of, which is beneficial in some ways, but they’re also much more complex.
7kmph 8 hours ago [-]
It probably won’t, would kill too many businesses and jobs. And frankly many people don’t see its value
https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers...
I gave an Erlang talk many years ago where I used the Tandem architecture as a comparison point, and one of the attendees happened to have worked on them.
I really should chase down the other references for further reading.
RIP, Joe. You were one of a kind.
Any day now...
As I learned with Lisp, ML, Prolog, Smalltalk since the mid-80's, and safer systems languages as well, it is easier to eventually get some of the goodies, than trying to push for the whole thing.
Unfortunely that is how our industry works, until liabily becomes common, the lesser options will always win the market.
Erlang was invented at Ericsson, used for certain phone switches, it was tremendously successful at what it was built to do, and still it‘s not used anymore in their newer switches.
Why?
My take is that when the advantage to be gained is a superior architecture or set of abstractions that can be built by a small core of engineers then language choice can be an advantage. When the business needs to scale into the real world long tail of integrations, infrastructure, clients etc then throwing bodies at the problem can be an advantage and then ecosystem and talent pool outweigh original language gains.
Sharp tools are at their best in a smaller more focused team... But in software, building the right architecture can in some cases be all the difference
The languages, the architectural choices, that were made by these orgs early on were allowed to "stick". There was no move fast break things, there were no pivots, there wasn't a massive cycle of "market discovery", no figuring out "product market fit".
They could have built in PHP, or Ruby, Or brain fuck and been successful I suspect. Talent and a steady hand at the helm are playing the outsized roles here.
Chat was added by running ejabberd[1], and the rest of the services (registration, status, sync) remained in PHP for some time, MMS was added as a PHP service. Services migrated to Erlang over time.
[1] Need chat? Run ejabberd is a gateway drug to running Erlang. Happened lots of places, but some then rewrite chat in another language later.
I’ve seen enough to doubt this. The less capable a tool the higher the overhead, until you reach that critical point where you spend more time managing overhead than adding features. It’s a self reinforcing cycle which makes it exponential , and it happens more quickly than people like to admit. You have to start hiring, and hiring is always a disappointment, you grow teams, communication overhead takes over, you inevitably model the product after the organization, you start making engineering choices based on realities of the hiring market, the realization sets in that “easier to hire for” is a double edged sword as talent pools differ not just in size but also quality, your organization and tech stack ossify, and suddenly you’re in the stink.
In fact I’ve never not seen this happen.
Case In point: You flippantly added brainfuck to your list there. But obviously not: clearly you can’t build WhatsApp in brainfuck and win the market. So here we are already: there is a limit. Why, then, should ruby or PHP be on the other side of that limit?
I doubt it.
Remember that Erlang was open-sourced as a last-ditch effort to save it, in 1998, after Ericsson internally switched to C++ and banned using Erlang on new products.
The sad fact is that the software industry as a whole relies heavily on mainstream languages, and not on educating your engineers to leverage the strengths of your specialty language. There's rationale to that, in that it costs a ton to maintain your own platform when you can just leverage a more public one. As a random example, why spend a ton to try and optimize your compiled language when you can... just use GCC (or clang nowadays). See: ongoing complaints about the performance of Go.
Erlang's silver lining is it found some measure of success outside of Ericsson, which led it to being unbanned there (and the banner to being "promoted sideways")
Truly? And considering here the option is C++?
I truly asking, how much cost is this, have been measured?
I suspect is like the issue with fail to measure the whole thing and is just like "my guys that work in the platform also work making my apps and fixing my printer, so when they work in the platform I can`t print" kind of situation, instead of "I have a platform team (that could be like very small) and a apps team, and I ditch the printer in the bin" that I suspect is just reorg correctly the same amount of people.
That is an excellent remark.
Except when the language is the workhorse of a proprietary product sold to your employer. SQL is the example that escaped into the open world, but see also MATLAB and Excel formulae/VBA.
As far as I know there‘s no other language which focussed from the get-go on parallel, distributed deployment, has processes as first class primitives, supports hot code swapping etc.
And why does from the get-go on parallel matter? Wouldn't it be OK if the initial focus was something else and then there was a change of focus?
And processes as first class depends what you mean: https://live.exept.de/doc/online/english/overview/basicClass...
And hot code swapping: Smalltalk.
Retrofitting features into existing languages is rarely satisfying in my experience.
Sure, Python now has functional constructs, but variables are still mutable, so bizarre things can happen inside a map call.
In Erlang, immutability is baked into everything.
Message passing can be added as a library, but you don’t get the same impact as everything being a message. Does your random 3rd party library also use messages? Probably not.
Erlang is a very opinionated language and runtime with a small set of core concepts, and it is very predictable as a consequence.
Java or C++ have just about any feature you can think of, which is beneficial in some ways, but they’re also much more complex.