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

271–280 of 333 posts

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

#271

Post by dackroyd99 »

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…

Turns out there's the same amount of code in the Spotify app as there is in the product I work on...

True though, if you want more features you need more code. Sure, loads of people on HN could build a 'chat app' in a lot less but if they kept it going for ten years (same age as our product) and kept on adding new features the lines would start to add up...

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

#272

Post by thu2111 »

imron wrote: post #227
eyegor wrote: post #193

I'm truly shocked how many resources are dedicated to maintaining a chat app that essentially just talks to an api. Seems like you could easily build and maintain a simple chat system with <5 developers. You wouldn't have shiny new features, but it would by coincidence be faster and simpler. Networked chat is a standard project in university.

> Seems like you could easily build and maintain a simple chat system with Yes you could. Note however 'simple chat system'. To build a global messaging app used by hundreds of millions of people is a whole different ball game. By comparison, before acquisition by Facebook, Whatsapp had a team of ~50 people, and that was considered lean. Based on that, it would seem you're about an order of magnitude off.

True but, be aware that those 50 people did everything including the servers, the operations, the BI, oh and also maintained clients for like 8 different mobile platforms including ultra constrained ones like j2me and blackberry. If you look just at the iOS client, 5 people at WhatsApp on it would probably be a bit too high.

The issue here is only partly inherent complexity of the feature set. The real problem Facebook had is one I don't see discussed in either the blog post or this thread, which was organizational. The way they structured their mobile apps was as a huge shared codebase with many disparate teams just checking code into it whenever they wanted. To the extent there was any architectural planning at all it came from some small shared library teams who were in no position, managerially, to enforce their will on the others. The blog post makes clear that a huge portion of their problem was multiple teams inventing their own ways of doing things and creating stuff that want necessary, along with a lot of pointless duplication because there was so little coordination and thus so little code reuse.

The new app doesn't sound like anything special design wise, and that's the point: for the first time they've done things more conventionally. They now have someone who can dictate to every feature team "thou shalt use sqlite with these schemas" and other rules.

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

#273

Post by adev_ »

kreetx wrote: post #87
freepor wrote: post #80

Earlier quoted context omitted.

React Native (or any framework) isn’t good when you can literally afford billions of dollars of R&D given the financial value of the app. Just like the Mars rovers don’t run Python but it is a great language for a experimental SaaS app testing a new market, RN is great for a team of 3 engineers to get a multi platform app shipped, but not a great choice for an app worth ~$100 billion to its parent company.

Interestingly, there was news on some satellite running javascript. But I wonder if the core was running something else, and peripherals were run with js -- and simply restarted when they died, Erlang style.

> Interestingly, there was news on some satellite running javascript.

It does not mean it runs JS for anything critical, and very likely it does not.

My car entertainment system (GUI) run JS, and I'm fine with it. I would not if it would run on the emergency breaking system...

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

#274

Post by otabdeveloper4 »

jeswin wrote: post #224
ardit33 wrote: post #146

Earlier quoted context omitted.

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…

Thank you for saying this. The overwhelming majority of comments on this thread are pedestrian - as if FBs engineers have been making decisions out of naivety, incompetence or self interest.

> as if FBs engineers have been making decisions out of naivety,

No.

> incompetence

Yes.

> or self interest

Yes.

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

#275

Post by otabdeveloper4 »

wodenokoto wrote: post #163
ardit33 wrote: post #146

Earlier quoted context omitted.

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.

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

Because nobody ever got promoted for not hiring people or for not writing code.

The problem is 10x as bad when you're an "IT company", i.e., writing code is your primary product.

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

#276

Post by ss3000 »

wodenokoto wrote: post #163
ardit33 wrote: post #146

Earlier quoted context omitted.

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.

Part of it also comes from the tendency of large orgs to ship their org structure.

It can oftentimes be worthwhile to have individual teams each fully "own" a piece of the product, and that also comes with the autonomy to choose to duplicate stuff that other teams might have already built rather than working with them and tweaking it to match their own specific new requirement.

This significantly reduces communication & coordination overhead for delivering new features, at the expense of consistency and code reuse, which can often be a worthwhile tradeoff at scale.

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

#278

Post by danabramov »

philips4350 wrote: post #250
hvidgaard wrote: post #246

Earlier quoted context omitted.

How in the name of everything did they manage to write 1.7M lines of code for a messenger app? That is an astonishingly large code base! We're talking about an instant messenger app with heaps of features, having a LoC footprint 3.5% of the size of modern Windows.

I wonder if react native library code and all the other code related to it like the js engine is included in that metrics.

There was no React Native in the Messenger app before the rewrite.

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

#279

Post by danabramov »

Illniyar wrote: post #237
butz wrote: post #76

The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2

As far as I know messenger was never written in a cross-platform way, neither RN or otherwise. Is there anywhere that suggets it was ever non native?

It was fully native.

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

#280

Post by danabramov »

tomduncalf wrote: post #73
reggieband wrote: post #17

From: https://engineering.fb.com/data-infrastructure/messenger/ > We accomplished this by using the native OS wherever possible Does this mean this application does not use React Native?

React Native isn't necessarily a great fit for something that is intended to be "a simple, lightweight utility" - there is a reasonable start up overhead, for example, with RN, and it also involves bundling quite a few libraries and dependencies. That doesn't mean React Native is not a good fit for any kind of application - for many kinds of apps, start up time and app size are a much smaller issue - but seems Facebo…

To be clear, Messenger wasn’t being rewritten from React Native. It was a fully native app before, too.
Post reply on HN