8 ms·

Comments in this thread are quite cringeworthy. People calling WhatsApp a simple application seem to fail to understand the cost of simplicity under such scale

by sidcool 11y ago

Comments in this thread are quite cringeworthy. People calling WhatsApp a simple application seem to fail to understand the cost of simplicity under such scale.

JupiterMoon 11y ago
I think the point is more that WhatsApp continues to do one thing and to do it well. Conceptually this is simple -- although yes the scale adds plenty of complexity. Other social type services/apps/whatever try to become all things to all people they therefore become complex conceptually as well as due to scale.
- snake117 11y ago
  I like the "startup feel" that WhatsApp retained; hire few people that can solve immediate problems and roll out necessary features. This alone takes a great deal of work, but admittedly much more manageable because you don't have to deal with unnecessary features that could potentially hinder your customers experience.
- hellbanner 11y ago
  Well, they do more than just "one thing" like text-messaging. They support voice chat, location sharing, group messaging, games (I read that the Threes game is a WhatsApp game in Eastern Asia) -- lots of features.
mpdehaan2 11y ago
It wasn't a great article from wired. I feel the language choice is probably the least contributing factor in terms of what's interesting at that scale. Yes, it's an eclectic choice, but I find systems/component architecture much more interesting than language and program architecture in scaling considerations. A bit more info here: http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-... With regard to fun challenges to solve, from that article: "Lots of problems related to scale as you might imagine. Problems with flapping connections, queues getting so long they delay high priority operations, flapping of timers, code that worked just fine at one traffic level breaking badly at higher traffic levels, high priority messages not getting serviced under high load, operations blocking other operations in unexpected ways, failures causing resources issues, and so on. These things just happen and have to be worked through no matter what system you are using."
- sidcool 11y ago
  I agree, Wired didn't cover the subject with the kind of detail programmers would expect.
  - forgetsusername 11y ago
    >with the kind of detail programmers would expect. Wired isn't writing articles for programmers. It's a pop-science magazine writing tech articles for the mainstream.
- austenallred 11y ago
  I posted this on /r/programming earlier, and there was a fantastic response from /u/MyTribeCalledQuest. It's here https://www.reddit.com/r/programming/comments/3l2spe/why_whatsapp_only_needs_50_engineers_for_its_900m/cv2x4xt https://www.reddit.com/r/programming/comments/3l2spe/why_wha... In its entirety: I can explain a bit more in depth than the author did. Erlang uses a model known as the actor model. This means that each part of your program is a completely independent entity like a mailbox, known as an actor. For one actor to communicate with another actor, it simply puts a message in the intended actor's mailbox. Since each actor is independent, this means that we can spawn as many actors as we want to read messages from a single mailbox, and do what is requested. In terms of what WhatsApp is doing, this means that they can have (potentially infinite) conversations going on between users all at the same time. If any part of their pipeline is working too slowly (there are more messages being put in the mailbox than taken out) they can just spawn additional actors to read mail (at any time they want, even programmatically). Additionally, as alluded to by the author, in Erlang you can do something known as "hot loading," which means spawning newer versions of actors (when the implementation changes) while still running the old actors so that there is never any loss of service. Haskell is similar to Erlang in its ability to scale. In fact, there is a library in Haskell known as HdpH-RS that enables fault-tolerant (the programmer does not have to worry about intermediate failure at all) distributed computing/memory (tested up to 1400 cores). The main reason for this is that Haskell is strictly-typed, meaning all types must be defined (or derivable) at compile time, and immutable, meaning that variables cannot change their values after they are defined. Due to all of this strictness, you never have to worry about errors found in languages like C such as segfaults, or improper use of a function since you can enforce usage with types. For instance a function that should only accept unit vectors would use a type UnitVector instead of Vector (Note that this approach is generally a bad idea in C/C++/Java etc). Essentially, if your program compiles, then it will run correctly (generally the only real errors you run into are logical ones -- the algorithm itself being incorrect). This makes it really easy to refactor code later on. The reason Facebook can handle urgent tasks so quickly is mostly due to Haskell's generics, which are like templates from C++ or generics in Java. The main difference however is that Haskell lets you create generic mixins for types known as type classes. This means that you can write extremely general code to handle almost anything in the high level. Then, whenever you need to handle something new, you just have to choose which mixins you want and just add them to your type by defining the interface. For example, I could make a Multipliable type class, I would require the programmer to only define the multiplication operator for his type, and then it would automatically create things like pow or sqr.
deleted 11y ago
[deleted]
ianstallings 11y ago
In fairness, a lot of us have built systems that are just as complex, if not more. This is par for the course these days. The article seems to imply that they're doing something special, and that Erlang has something to do with it. It's no surprise to me that people are skeptical of such claims.
nilkn 11y ago
Isn't the fact that they've actually done it with so few people fairly concrete evidence that it's not incredibly complex?
- digitalzombie 11y ago
  That's not evidence that's speculation. They could be using really good tools. Or each of those 50 programmers are 10x more productive than regular programmer (I don't believe in this imo).
  - nilkn 11y ago
    The evidence in this case is the fact that they built the company and product with 50 developers. Whether that evidence implies anything about the product's complexity is the speculative part. If the explanation is that every single programmer at WhatsApp is 10x more productive than programmers at similar top companies, then my first question is how did WhatsApp manage to hire such people but Google, Facebook, etc., did not?
    - jasonwatkinspdx 11y ago
      Would you rather be one of 25,000 engineers at google, or one of 50 at whatsapp? A ton of people would chose the latter just to be in a more important core role. And if we use the acquisition price as a proxy for current market value, the per engineer capita is 20 times better at WhatsApp. I don't have any inside info, but I'm betting any of those engineers that had options are very very happy with their current job.
      - nilkn 11y ago
        That's very handwavy and not rigorous. > A ton of people would chose the latter just to be in a more important core role. Yeah, and a ton of people would choose the former just to be in a bigger company with more perks or because they want to work on something other than an IM app. Who knows? This isn't nearly strong enough to form a conclusion either way. > the per engineer capita is 20 times better at WhatsApp Perhaps, but why? You can't say that they got better talent just because they were a startup, because then I can point out all the other startups that don't have such talent. > I'm betting any of those engineers that had options are very very happy with their current job. I'm sure they are. I'm also sure they're not oracles who can predict the future. So they couldn't have known when joining that WhatsApp would be acquired for such a spectacular amount. So why WhatsApp over all the other startups? What did WhatsApp do to attract such world-class talent? I'm looking for a real, concrete answer that couldn't equally be applied to every other startup out there. The alternative explanation, of course, is that WhatsApp just isn't as complex as some here are proposing it to be. Then we don't have the mystery of how they beat every other company in the world at hiring the greatest unknown talent. Rather, they simply timed the market perfectly, probably partially through luck.
smcl 11y ago
I don't think anyone commenting along these lines on HN is that ignorant. Everyone on here understands that anything executed at the WhatsApp/FB/Instagram sort of scale is going to present all sorts of tough problems and require software engineering know-how in spades. However of all the various applications you could conceivably scale to hundreds of millions of users this is one of the simplest. I do not think acknowledging that is cringeworthy at all.
- lotso 11y ago
  >However of all the various applications you could conceivably scale to hundreds of millions of users this is one of the simplest. I do not think acknowledging that is cringeworthy at all. What other apps besides social networking and communication apps even get to hundreds of millions of user?
  - gallamine 11y ago
    I guess "users" is a confusing concept, but a service like Cloudflare would be an example of a more complex application serving that scale of people.
    - tedunangst 11y ago
      Is cloudflare more complex or less? If I'm connecting through a CF proxy in North America and someone else is connecting through Europe, there's not really any state that needs to be synchronized between us. If I send a message to somebody in Europe, that obviously does need to be synced.
      - simcop2387 11y ago
        Actually there is state that might need to be synchronized between the two locations. The cached state of the page or other resources there. CF doesn't just do a blind proxy to the host, along with that it does a number of checks for common attacks and other misbehaving clients.

by sidcool 11y ago

Comments in this thread are quite cringeworthy. People calling WhatsApp a simple application seem to fail to understand the cost of simplicity under such scale.

JupiterMoon 11y ago

I think the point is more that WhatsApp continues to do one thing and to do it well. Conceptually this is simple -- although yes the scale adds plenty of complexity. Other social type services/apps/whatever try to become all things to all people they therefore become complex conceptually as well as due to scale.

snake117 11y ago
I like the "startup feel" that WhatsApp retained; hire few people that can solve immediate problems and roll out necessary features. This alone takes a great deal of work, but admittedly much more manageable because you don't have to deal with unnecessary features that could potentially hinder your customers experience.
hellbanner 11y ago
Well, they do more than just "one thing" like text-messaging. They support voice chat, location sharing, group messaging, games (I read that the Threes game is a WhatsApp game in Eastern Asia) -- lots of features.

mpdehaan2 11y ago

It wasn't a great article from wired. I feel the language choice is probably the least contributing factor in terms of what's interesting at that scale. Yes, it's an eclectic choice, but I find systems/component architecture much more interesting than language and program architecture in scaling considerations. A bit more info here: http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-... With regard to fun challenges to solve, from that article: "Lots of problems related to scale as you might imagine. Problems with flapping connections, queues getting so long they delay high priority operations, flapping of timers, code that worked just fine at one traffic level breaking badly at higher traffic levels, high priority messages not getting serviced under high load, operations blocking other operations in unexpected ways, failures causing resources issues, and so on. These things just happen and have to be worked through no matter what system you are using."

sidcool 11y ago
I agree, Wired didn't cover the subject with the kind of detail programmers would expect.
- forgetsusername 11y ago
  >with the kind of detail programmers would expect. Wired isn't writing articles for programmers. It's a pop-science magazine writing tech articles for the mainstream.
austenallred 11y ago
I posted this on /r/programming earlier, and there was a fantastic response from /u/MyTribeCalledQuest. It's here https://www.reddit.com/r/programming/comments/3l2spe/why_whatsapp_only_needs_50_engineers_for_its_900m/cv2x4xt https://www.reddit.com/r/programming/comments/3l2spe/why_wha... In its entirety: I can explain a bit more in depth than the author did. Erlang uses a model known as the actor model. This means that each part of your program is a completely independent entity like a mailbox, known as an actor. For one actor to communicate with another actor, it simply puts a message in the intended actor's mailbox. Since each actor is independent, this means that we can spawn as many actors as we want to read messages from a single mailbox, and do what is requested. In terms of what WhatsApp is doing, this means that they can have (potentially infinite) conversations going on between users all at the same time. If any part of their pipeline is working too slowly (there are more messages being put in the mailbox than taken out) they can just spawn additional actors to read mail (at any time they want, even programmatically). Additionally, as alluded to by the author, in Erlang you can do something known as "hot loading," which means spawning newer versions of actors (when the implementation changes) while still running the old actors so that there is never any loss of service. Haskell is similar to Erlang in its ability to scale. In fact, there is a library in Haskell known as HdpH-RS that enables fault-tolerant (the programmer does not have to worry about intermediate failure at all) distributed computing/memory (tested up to 1400 cores). The main reason for this is that Haskell is strictly-typed, meaning all types must be defined (or derivable) at compile time, and immutable, meaning that variables cannot change their values after they are defined. Due to all of this strictness, you never have to worry about errors found in languages like C such as segfaults, or improper use of a function since you can enforce usage with types. For instance a function that should only accept unit vectors would use a type UnitVector instead of Vector (Note that this approach is generally a bad idea in C/C++/Java etc). Essentially, if your program compiles, then it will run correctly (generally the only real errors you run into are logical ones -- the algorithm itself being incorrect). This makes it really easy to refactor code later on. The reason Facebook can handle urgent tasks so quickly is mostly due to Haskell's generics, which are like templates from C++ or generics in Java. The main difference however is that Haskell lets you create generic mixins for types known as type classes. This means that you can write extremely general code to handle almost anything in the high level. Then, whenever you need to handle something new, you just have to choose which mixins you want and just add them to your type by defining the interface. For example, I could make a Multipliable type class, I would require the programmer to only define the multiplication operator for his type, and then it would automatically create things like pow or sqr.

deleted 11y ago

[deleted]

ianstallings 11y ago

In fairness, a lot of us have built systems that are just as complex, if not more. This is par for the course these days. The article seems to imply that they're doing something special, and that Erlang has something to do with it. It's no surprise to me that people are skeptical of such claims.

nilkn 11y ago

Isn't the fact that they've actually done it with so few people fairly concrete evidence that it's not incredibly complex?

digitalzombie 11y ago
That's not evidence that's speculation. They could be using really good tools. Or each of those 50 programmers are 10x more productive than regular programmer (I don't believe in this imo).
- nilkn 11y ago
  The evidence in this case is the fact that they built the company and product with 50 developers. Whether that evidence implies anything about the product's complexity is the speculative part. If the explanation is that every single programmer at WhatsApp is 10x more productive than programmers at similar top companies, then my first question is how did WhatsApp manage to hire such people but Google, Facebook, etc., did not?
  - jasonwatkinspdx 11y ago
    Would you rather be one of 25,000 engineers at google, or one of 50 at whatsapp? A ton of people would chose the latter just to be in a more important core role. And if we use the acquisition price as a proxy for current market value, the per engineer capita is 20 times better at WhatsApp. I don't have any inside info, but I'm betting any of those engineers that had options are very very happy with their current job.
    - nilkn 11y ago
      That's very handwavy and not rigorous. > A ton of people would chose the latter just to be in a more important core role. Yeah, and a ton of people would choose the former just to be in a bigger company with more perks or because they want to work on something other than an IM app. Who knows? This isn't nearly strong enough to form a conclusion either way. > the per engineer capita is 20 times better at WhatsApp Perhaps, but why? You can't say that they got better talent just because they were a startup, because then I can point out all the other startups that don't have such talent. > I'm betting any of those engineers that had options are very very happy with their current job. I'm sure they are. I'm also sure they're not oracles who can predict the future. So they couldn't have known when joining that WhatsApp would be acquired for such a spectacular amount. So why WhatsApp over all the other startups? What did WhatsApp do to attract such world-class talent? I'm looking for a real, concrete answer that couldn't equally be applied to every other startup out there. The alternative explanation, of course, is that WhatsApp just isn't as complex as some here are proposing it to be. Then we don't have the mystery of how they beat every other company in the world at hiring the greatest unknown talent. Rather, they simply timed the market perfectly, probably partially through luck.

smcl 11y ago

I don't think anyone commenting along these lines on HN is that ignorant. Everyone on here understands that anything executed at the WhatsApp/FB/Instagram sort of scale is going to present all sorts of tough problems and require software engineering know-how in spades. However of all the various applications you could conceivably scale to hundreds of millions of users this is one of the simplest. I do not think acknowledging that is cringeworthy at all.

lotso 11y ago
>However of all the various applications you could conceivably scale to hundreds of millions of users this is one of the simplest. I do not think acknowledging that is cringeworthy at all. What other apps besides social networking and communication apps even get to hundreds of millions of user?
- gallamine 11y ago
  I guess "users" is a confusing concept, but a service like Cloudflare would be an example of a more complex application serving that scale of people.
  - tedunangst 11y ago
    Is cloudflare more complex or less? If I'm connecting through a CF proxy in North America and someone else is connecting through Europe, there's not really any state that needs to be synchronized between us. If I send a message to somebody in Europe, that obviously does need to be synced.
    - simcop2387 11y ago
      Actually there is state that might need to be synchronized between the two locations. The cached state of the page or other resources there. CF doesn't just do a blind proxy to the host, along with that it does a number of checks for common attacks and other misbehaving clients.