3 ms·

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

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 1y 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.
- nothrabannosir 1y 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.
- toast0 1y 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.

zer00eyz 1y 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.

nothrabannosir 1y 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.
toast0 1y 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.