4 ms·

I'm sure you could do it in an afternoon, right? Just like anyone on HN can make a "basic CRUD app" like Facebook in a weekend. I really dislike the arrogant a

by oskarth 11y ago

I'm sure you could do it in an afternoon, right? Just like anyone on HN can make a "basic CRUD app" like Facebook in a weekend. I really dislike the arrogant attitude behind these types of comments. Have you worked at WhatsApp? Do you have any idea what they spend their days doing, what their systems look like, what their requirements are like? WhatsApp have close to a billion users, 50 engineers and they manage to produce a near flawless experience. This is not trivial, no matter how many armchair critics claim otherwise. It used to be the case that people dismissed FB as just another CRUD app ("not even written in RoR, but in PHP, yuck" ~ 2005-2010), but given the tools they have been pushing the last few years people seem to have stopped dismissing them as casually. Perhaps in a few years people will stop dismissing WhatsApp as casually as well.

hellofunk 11y ago
Well said.
sidcool 11y ago
I second you. People throw in things like "Duh, it's a lame technology, duh, I am working on something far superior, duh, that 3 people will ever use, duh" Don't forget WhatsApp has applications on all platforms.
danieldk 11y ago
I believe that the line of reasoning of your parent still has merit. Erlang OTP was developed for telephony systems and has proven to be very reliable for distributed system. Messaging maps relatively nicely to Erlang OTP and as such Whatsapp are leveraging decades of research and work by Ericsson. Of course, this is how it should be: a good software infrastructure should save users time. Obviously, creating Whatsapp is nothing near a weekend project. But I think there founders should be commended especially for avoiding some classic mistakes: the NIH syndrome and going on a hiring spree once the investments started rolling in. Their managerial skills are at least as good as their engineering skills.
- gutnor 11y ago
  I think that indeed the important thing here. The article try to focus a bit too much on some intrinsic qualities of the language as if it was the silver bullet of scalability while the real lesson is that they used the right tool for the job. Not so long ago, maintaining hardware that could support 900M user would have required an IBM scale company. A single developer today can develop, deploy and maintain a medium scale ecommerce site using infrastructure like AWS, a myriad of OpenSource solutions, plenty of services to handle payments, ... yet he will probably be using the same language than 15 years ago when 20 times more developers were needed to achieve the same result.
  - GFischer 11y ago
    Indeed. It's amazing :) . All the infrastructure-as-a-service stuff REALLY cuts down the overhead. I'm building a product that only a few years ago would have required a VERY significant investment, but now is basically stacking and connecting lego blocks of services :) - sales-as-a-service isn't mature yet, but if we had it, it would even sell itself :) . Ok, it's probably a pain if one of the black boxes fails, and I do know enough about the underlying architecture behind the services I'm using - I could probably replicate (badly) most if not all of them given time and money, but why would I?
    - karmajunkie 11y ago
      > Ok, it's probably a pain if one of the black boxes fails, and I do know enough about the underlying architecture behind the services I'm using - I could probably replicate (badly) most if not all of them given time and money, but why would I? I don't think this is a possibility whose importance can be understated. In most of my apps running on IaaS/PaaS offerings like heroku, key pieces of the infrastructure tend to fail for short times (typically very inconvenient times) fairly frequently, on the order of once or twice a week. The relative cost of this is highly variable and business-dependent, but at best its mildly inconvenient and at worst can be crippling. Its definitely something that needs to be accounted for. That said, I've also been lead on apps that used the same pieces of server infrastructure that had far better uptime when I handle ops myself instead of delegating that to another provider. (Not to pick on the providers—they have a very difficult job to do in a cost-effective way, and I'm quite certain that they do it better at that scale than I would.) The choice of Erlang for WhatsApp was strategic if for no other reason that that it allows them to dispense with some of those choices. Many of the typical use-cases of Redis, for example, are easily supported by OTP.
marcosscriven 11y ago
I think the reality, as is often the case with two extremes, is somewhere in between. Is this a simple 'solved' problem that anyone could do? No. But is it a super-human feet that only a handful of people could achieve? IMO, no as well. I think people in the latter extreme like to believe this as it's something they can aspire to - to say otherwise is to devalue their vocation. In the former camp, I think it's people pushing back against this too far in the opposite direction.
s_baby 11y ago
>I'm sure you could do it in an afternoon, right? Just like anyone on HN can make a "basic CRUD app" like Facebook in a weekend. Maybe the backend. I couldn't write a Blackberry Java app though which was WhatsApp's initial value proposition.
pdpi 11y ago
This might be me being exceedingly charitable to the OP, but I see his point differently: There's a ton of work involved in making a platform like WhatsApp a polished user experience. There's then a ton more work involved in making it _solid_. In choosing Erlang, they chose a platform that trivialises a large part (though not all) of the latter, allowing them to focus on the former.
astazangasta 11y ago
Essentially, yes? I mean, are you suggesting these engineers are doing magic? That they wrote some new and amazing code that anyone could not write? That these 50 people are the only ones who could do this and somehow ended up at WhatsApp? Or are they just leveraging powerful systems efficiently?
elorant 11y ago
Have you worked at WhatsApp? Do you have any idea what they spend their days doing, what their systems look like, what their requirements are like? Do you? If yes, please enlighten us. Otherwise I don't see the point of your objection. No one said that it can be done in a weekend. All that the parent comment said is that the fundamentals of building WhatsApp are already solved. He/she didn't dismiss it. Just because something isn't rocket science doesn't mean it's not useful. As for Facebook, people used to dismiss it not because it was seemingly too easy to build but because they failed to see its usage. Long before it became a platform it was pretty much a waste of time. Obviously anything with more than a hundred MM users is difficult to maintain.
- rdtsc 11y ago
  Not "parent" but search for Erlang Factory talks they talk about it. Here is one from Rick Reed. He explains how the product works : https://www.youtube.com/watch?v=c12cYAUTXXs https://www.youtube.com/watch?v=c12cYAUTXXs
- felixgallo 11y ago
  I can personally guarantee to you from direct current experience that there is nothing particularly solved about running services for even 50 million users. Go watch this: https://www.youtube.com/watch?v=TneLO5TdW_M# https://www.youtube.com/watch?v=TneLO5TdW_M#
Angostura 11y ago
I'm not sure how you managed to translate "Its not surprising 50 engineers are enough" to "I could do it in an afternoon"
somehnreader 11y ago
Hang on, I _could_ write a (small) twitter or (early) fb clone in a weekend. Easily. That would probably scale to 10k tweets or feed entries. What I in _no_ way could do is rewrite fb or twitter at the scale these systems operate today with a billion users and even more posts and data points. I don't agree with the sentiment of the previous poster, but fb & twitter were initially basic CRUD apps.
- karmajunkie 11y ago
  I have to disagree. They were messaging brokers masquerading as or mistaken for CRUD apps, which directly led to many of their early scaling issues.
  - somehnreader 11y ago
    But you can just implement them(the early versions) on any old server with a nice database installed if you want to. And you can do that in a weekend. And yes of course you will want to take a step back and change almost everything about it if you want it to scale to more orders of magnitude.
Alupis 11y ago
Well, frankly, there are plenty of open source chat server implementations (usually following XMPP standards) which easily scale to 10's of thousands, sometimes 100's of thousands of users without any modifications (OpenFire, to name one). It wouldn't be that difficult for a group/team of people to scale that into a cluster of servers and support several hundred million users at once -- XMPP packets are small and this problem has been solved many times. From a technical standpoint, WhatsApp, the product, and the scale they operate at are nothing new.
- josinalvo 11y ago
  Interesting! When did a XMPP server run with hundreds of thousands of users? At gmail?
  - Alupis 11y ago
    Google Messenger, Facebook Messenger, MSN Messenger, AOL Messenger (AIM), etc... (note that both google and facebook use proprietary chat protocols now i believe)

by oskarth 11y ago

hellofunk 11y ago

Well said.

sidcool 11y ago

I second you. People throw in things like "Duh, it's a lame technology, duh, I am working on something far superior, duh, that 3 people will ever use, duh" Don't forget WhatsApp has applications on all platforms.

danieldk 11y ago

I believe that the line of reasoning of your parent still has merit. Erlang OTP was developed for telephony systems and has proven to be very reliable for distributed system. Messaging maps relatively nicely to Erlang OTP and as such Whatsapp are leveraging decades of research and work by Ericsson. Of course, this is how it should be: a good software infrastructure should save users time. Obviously, creating Whatsapp is nothing near a weekend project. But I think there founders should be commended especially for avoiding some classic mistakes: the NIH syndrome and going on a hiring spree once the investments started rolling in. Their managerial skills are at least as good as their engineering skills.

gutnor 11y ago
I think that indeed the important thing here. The article try to focus a bit too much on some intrinsic qualities of the language as if it was the silver bullet of scalability while the real lesson is that they used the right tool for the job. Not so long ago, maintaining hardware that could support 900M user would have required an IBM scale company. A single developer today can develop, deploy and maintain a medium scale ecommerce site using infrastructure like AWS, a myriad of OpenSource solutions, plenty of services to handle payments, ... yet he will probably be using the same language than 15 years ago when 20 times more developers were needed to achieve the same result.
- GFischer 11y ago
  Indeed. It's amazing :) . All the infrastructure-as-a-service stuff REALLY cuts down the overhead. I'm building a product that only a few years ago would have required a VERY significant investment, but now is basically stacking and connecting lego blocks of services :) - sales-as-a-service isn't mature yet, but if we had it, it would even sell itself :) . Ok, it's probably a pain if one of the black boxes fails, and I do know enough about the underlying architecture behind the services I'm using - I could probably replicate (badly) most if not all of them given time and money, but why would I?
  - karmajunkie 11y ago
    > Ok, it's probably a pain if one of the black boxes fails, and I do know enough about the underlying architecture behind the services I'm using - I could probably replicate (badly) most if not all of them given time and money, but why would I? I don't think this is a possibility whose importance can be understated. In most of my apps running on IaaS/PaaS offerings like heroku, key pieces of the infrastructure tend to fail for short times (typically very inconvenient times) fairly frequently, on the order of once or twice a week. The relative cost of this is highly variable and business-dependent, but at best its mildly inconvenient and at worst can be crippling. Its definitely something that needs to be accounted for. That said, I've also been lead on apps that used the same pieces of server infrastructure that had far better uptime when I handle ops myself instead of delegating that to another provider. (Not to pick on the providers—they have a very difficult job to do in a cost-effective way, and I'm quite certain that they do it better at that scale than I would.) The choice of Erlang for WhatsApp was strategic if for no other reason that that it allows them to dispense with some of those choices. Many of the typical use-cases of Redis, for example, are easily supported by OTP.

marcosscriven 11y ago

I think the reality, as is often the case with two extremes, is somewhere in between. Is this a simple 'solved' problem that anyone could do? No. But is it a super-human feet that only a handful of people could achieve? IMO, no as well. I think people in the latter extreme like to believe this as it's something they can aspire to - to say otherwise is to devalue their vocation. In the former camp, I think it's people pushing back against this too far in the opposite direction.

s_baby 11y ago

>I'm sure you could do it in an afternoon, right? Just like anyone on HN can make a "basic CRUD app" like Facebook in a weekend. Maybe the backend. I couldn't write a Blackberry Java app though which was WhatsApp's initial value proposition.

pdpi 11y ago

This might be me being exceedingly charitable to the OP, but I see his point differently: There's a ton of work involved in making a platform like WhatsApp a polished user experience. There's then a ton more work involved in making it _solid_. In choosing Erlang, they chose a platform that trivialises a large part (though not all) of the latter, allowing them to focus on the former.

astazangasta 11y ago

Essentially, yes? I mean, are you suggesting these engineers are doing magic? That they wrote some new and amazing code that anyone could not write? That these 50 people are the only ones who could do this and somehow ended up at WhatsApp? Or are they just leveraging powerful systems efficiently?

elorant 11y ago

Have you worked at WhatsApp? Do you have any idea what they spend their days doing, what their systems look like, what their requirements are like? Do you? If yes, please enlighten us. Otherwise I don't see the point of your objection. No one said that it can be done in a weekend. All that the parent comment said is that the fundamentals of building WhatsApp are already solved. He/she didn't dismiss it. Just because something isn't rocket science doesn't mean it's not useful. As for Facebook, people used to dismiss it not because it was seemingly too easy to build but because they failed to see its usage. Long before it became a platform it was pretty much a waste of time. Obviously anything with more than a hundred MM users is difficult to maintain.

rdtsc 11y ago
Not "parent" but search for Erlang Factory talks they talk about it. Here is one from Rick Reed. He explains how the product works : https://www.youtube.com/watch?v=c12cYAUTXXs https://www.youtube.com/watch?v=c12cYAUTXXs
felixgallo 11y ago
I can personally guarantee to you from direct current experience that there is nothing particularly solved about running services for even 50 million users. Go watch this: https://www.youtube.com/watch?v=TneLO5TdW_M# https://www.youtube.com/watch?v=TneLO5TdW_M#

Angostura 11y ago

I'm not sure how you managed to translate "Its not surprising 50 engineers are enough" to "I could do it in an afternoon"

somehnreader 11y ago

Hang on, I _could_ write a (small) twitter or (early) fb clone in a weekend. Easily. That would probably scale to 10k tweets or feed entries. What I in _no_ way could do is rewrite fb or twitter at the scale these systems operate today with a billion users and even more posts and data points. I don't agree with the sentiment of the previous poster, but fb & twitter were initially basic CRUD apps.

karmajunkie 11y ago
I have to disagree. They were messaging brokers masquerading as or mistaken for CRUD apps, which directly led to many of their early scaling issues.
- somehnreader 11y ago
  But you can just implement them(the early versions) on any old server with a nice database installed if you want to. And you can do that in a weekend. And yes of course you will want to take a step back and change almost everything about it if you want it to scale to more orders of magnitude.

Alupis 11y ago

Well, frankly, there are plenty of open source chat server implementations (usually following XMPP standards) which easily scale to 10's of thousands, sometimes 100's of thousands of users without any modifications (OpenFire, to name one). It wouldn't be that difficult for a group/team of people to scale that into a cluster of servers and support several hundred million users at once -- XMPP packets are small and this problem has been solved many times. From a technical standpoint, WhatsApp, the product, and the scale they operate at are nothing new.

josinalvo 11y ago
Interesting! When did a XMPP server run with hundreds of thousands of users? At gmail?
- Alupis 11y ago
  Google Messenger, Facebook Messenger, MSN Messenger, AOL Messenger (AIM), etc... (note that both google and facebook use proprietary chat protocols now i believe)