Does it? I routinely use Telegram, Line and Messenger. Messenger is without contest the one that gives the most trouble.
I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined.
That being said, I'm sure that a lot of progress have been made and that there's a lot going on behind Messenger in terms of security and scalability. I'd be curious to know what's hidden between the millions LOC.
You never used ICQ over a spotty 3G connection, though, did you?
$ tc qdisc change dev eth0 root netem loss 0.3% 25%
$ tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
That's a joke, right? On a crappy internet connection (e.g. using O2 as carrier on the train cologne-hamburg you get ~12s ping, 30kbps, >90% packets dropped, via edge) most chat apps stop working, but Facebook Messenger is (except for Riot.im and Discord) probably the one that works worst.
Telegram works better, even IRC via Quassel/Quasseldroid works significantly better, and especially WhatsApp works so well you don't even notice the connection issues.
Facebook Messenger doesn't even properly start on such crappy connections.
FB messenger exists and works on crappy connections. Google hangout exists and messes up on crappy connections. Telegram exists and messes up on crappy connections ( see the issues it has in Africa ). Signal exists and does not work well even on non-crappy connections. Whatsapp exists and sort of works on crappy connections. Matrix exists and sucks on crappy connections.
What we need is something that exists and works on crappy connections that has less LOC than FB messenger to demonstrate that it is possible to handle crappy connections and modern messaging in much fewer lines of code.
That's why your comment is nonsensical, if not downright contradictory noise.
> Ordering messages and providing reliability does not require 1.7M lines of code.
This has been demonstrated ad nauseum a priori with loads of toy chat apps that reconnect and retain state. It's not really a challenge. EVERYTHING else crammed into it, should be the reasoning for 1.7M lines of code, but as they demonstrated TO THEMSELVES AND EVERYONE, it wasn't (360k now)
Yes and they figured out what was needed after first writing a 1.7M line of code thing that worked. That's the process of reiteration and a process of initial LOC bloat before LOC stripping.
Without that process by thinking it has all been demonstrated ad nauseum a priori with loads of toy chat apps that reconnect and retain state you end up with deciding that if Friday was Feb 28th then Monday is certainly March 3rd because date/time handling is simple and end up being Robinhood, down for a day.
Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.
Also known as:
You can do dropbox with FTP.
If Friday is Feb 28th, then Monday is March 3rd. There's no need for those bloated date libraries.
> Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.
Certainly. It worked before the change. So it is given that 1.7m of "garbage" provided a working product.
How many lines of code it took Google to make Hangout not get confused by image uploads on crappy connections? Unknown, because it is still confused.
How many lines of code it took Signal not to delay messages when a recipient is on a crappy connection? Unknown, because it still does that.
If it having 1.7M lines of code indicates anything it is that creating a "simple app that provides simple functionality over a network well" is hard.
Look at the garbage generated by Google - text messages and images on Google hangout are not guaranteed to arrive in order ( or even be sent in order ) unless you are on a great network.