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

171–180 of 333 posts

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

#171

Post by nneonneo »

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

The best part about this cycle is that developers can always point to some metric which shows improvement to justify their actions, resulting in an Escher-like loop where they think they’re always going up.

These cycles pop up all the time in development as priorities shift (or as developers find more excuses to “fix” what isn’t broken). Real world coding always involves compromise - leadership is recognizing which compromises to make without continually backpedaling.

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

#172

Post by aikah »

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…

What language(s) does Spotify use for the backend? not the website or the mobile clients, but the backend itself.

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

#173

Post by [deleted] »

notyourday wrote: post #111
pathseeker wrote: post #104

Earlier quoted context omitted.

Ordering messages and providing reliability does not require 1.7M lines of code.

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

[deleted]

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

#175

Post by cjamesd »

This is a bit cynical (and borderline paranoid) but what if the reason for the rewrite was to remove privacy-violating code that was becoming a greater and greater liability? Also, wonder if they needed to do this to make way for end-to-end encryption we've been hearing about?

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

#176

Post by dzonga »

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

the reason is they're high paid engineers without skin in the game. Fb is already making money, hence a lot of engineering efforts are not related to having fb make money, but to prove the engineer's worth.

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

#177

Post by ardit33 »

aikah wrote: post #172
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…

What language(s) does Spotify use for the backend? not the website or the mobile clients, but the backend itself.

Mostly Java.... some scala (some teams might use it), and potentially other languages. It built its own api lightweight java framework around 2014-2015 (called Apollo), which is actually pretty decent/nice to work with. There was a lot of protobuf usage early on, but most teams started transitioning to plain json.

So, each team runs its own servers, for the features it is developing/maintaining, and most of the api goes throw a common gateway, etc.. etc... don't want to give out more than this.

Some of the simple front end web pages (i.e. marketing websites, analytics) might even be on php/python/ruby. Some teams wanted to use javascript (Node), but those are not the critical main app, as java is pretty much required to be used for anything that affects the main app.

Also, if you are doing machine learning, then whatever it gets the job done (usually Python).

btw, I left few years ago, so things might have changed.... I know at least one team that wanted to use GO for some of their services....

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

#178

Post by monocasa »

myko wrote: post #137
monocasa wrote: post #7

Considering that they were shipping 18,000 classes in their iOS app back in 2015, a quarter the size of their 2019 app has to be still unreasonably massive. https://gist.github.com/quellish/473f513fbd1310233a8e

That's Facebook proper not the Messenger app

They used to at least be the same core.

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

#179

Post by monocasa »

LennyWhiteJr wrote: post #132
monocasa wrote: post #7

Considering that they were shipping 18,000 classes in their iOS app back in 2015, a quarter the size of their 2019 app has to be still unreasonably massive. https://gist.github.com/quellish/473f513fbd1310233a8e

The number of classes isn't necessarily indicative of the size or complexity of an app.

> The number of classes isn't necessarily indicative of the size

Size, not necessarily, but yes it was in the case (the person was looking at why the binary itself, not any of the assets was above 100 meg).

> or complexity of an app

I'm not sure how 18,000 classes isn't a guaranteed extremely complex app.

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

#180

Post by notJim »

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

It's great, because each approach has pros and cons, so as long as you primarily focus on the pros, it's a win every time.
Post reply on HN