Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

engineering.fb.com

Post reply on HN
Print view View original

161–170 of 333 posts

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#161

Post by jianshen »

WhyNotHugo wrote: post #152

I don't know anyone who uses Messenger, yet, I've heard of people moving to specific countries where it's the de facto and you can't have a social life without it. I'm also aware of how iMessages and SMS are used in the US, yet this is very US-specific, and I don't believe any other country uses SMS. For Chinese people, WeChat is the standard, and what pretty much anyone uses. In Argentina and the Netherlands (and I…

Did you ever use AIM, ICQ, MSN, Y! Messenger? I'm quite certain that in a decade, there will be another batch of dominant messengers "reinventing the wheel" (IG & TikTok I'm looking at you). Real-time Communication is just such a crucial part of people's lives that people will never stop working on it, even if it feels like it's been solved.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#162

Post by notyourday »

ringzero wrote: post #148
notyourday wrote: post #111

Earlier quoted context omitted.

Code wins arguments. FB messenger beats everything, Whatsapp, Wire, Signal, WeChat, Telegram included, in the suckiest network connections.

Repeating a point without adding proof doesn't make your point more valid. When people say "code wins arguments", they're referring to using source code to prove something , not "it wins because it has more source code" (???).

People say "Code wins arguments" because written code that works demonstrates the winning argument against the code that is either not written or does not work.

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.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#163

Post by wodenokoto »

ardit33 wrote: post #146
aldanor wrote: post #85

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment: - NumPy is 360K lines mostly C - Postgres is around 2.1M of C - Go 1.13 is around 1.5M of Go code - Rust 1.37 is around 1.2M of Rust code iirc - core llvm is around 3M of C++ iirc ... A chat app is 1.7M. A chat app... Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've…

it seem you don't have experience on large scale apps... and the people that make these type of comments almost never have had to work on large applications..... Spotify had about 500k, lines of code in 2015, (not including external libraries). We did make it in a feature based architecture, where there was a main container app (and a major core playback library) and for every major feature they had their own sub-pro…

I would love to read more about why large apps are so big.

I currently work on a project that is much larger than I would expect it to be, both in terms of codebase and people, and while I don't know who to jank, I also don't understand why it has to be so big.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#164

Post by gagabity »

Keep seeing react native pop up in the comments, there has never been any indication that Messenger used any react native from fb feom all their presentations I have see . RN is used in the Marketplace tab on the Facebook App, the Ad manager app and a few other places.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#165

Post by Legogris »

SQLite wrote: post #93
kreetx wrote: post #84

Earlier quoted context omitted.

I just listened to the Changelog's (a podcast) episode with Richard Hipp, the author of SQLite -- I wonder if he had any part on this extension. But in any case, great to see SQLite thrive.

I did not. This is the first I've heard of it.

I have to ask, did they pay the 6k license fee yet?

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#166

Post by MikusR »

adonese wrote: post #117
MikusR wrote: post #51

Earlier quoted context omitted.

Or Telegram.

i use telegram web and it is awesome. Messenger web just sucks, i don't why actually, maybe it is because of the design. I have not checked the others (signal, wechat). tl;dr web clients are probably more performant than their electron counterpart

I mentioned Telegram because the desktop version does not use electron. It's a QT application and is small and fast.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#167

Post by jpeeler »

Wish they had gone into more details about the budgets. Unless a project is bug fix only for life, how can one set a binary size or lines of code upper limit? I've heard that the best developers delete more than they write, but in practice I don't think that happens very often.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#169

Post by paxys »

miki123211 wrote: post #82

Am I the only one who thinks 86mb for an app is about 86 times too much? Windows Messenger was about 900k. Sure, it only did text, but Skype wasn't that big either. I'd accept 20mb for stickers, givs and stuff but 80? And 300k lines of code? For a messaging app? It just seems... unreasonable to me.

Most of that is likely retina-friendly images/icons.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#170

Post by x0x0 »

reaperducer wrote: post #66
millstone wrote: post #12

From https://engineering.fb.com/data-infrastructure/messenger/ : Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used qui…

They make it sound like the clouds parted and a ray of sunshine struck the programmers at Facebook and they realized that they didn't have to ride the framework-go-round to hell. These are supposed to be the smartest people in SV, but from the outside, it strikes me more as a "No shit, Sherlock" moment.

I dunno -- you make it sound like it's a priori easy to figure out what is going to be better: one codebase ala react or multiple implementations per platform. Where the definition of better is some admixture of user experience, hardware requirements, maintenance costs, ease of hiring / training people for the necessary skills; and all these may shift over time.
Post reply on HN