Live data from Hacker News

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

engineering.fb.com

251–260 of 333 posts

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

#251
post #231
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…

This "chat app" is used by more than a billion people in the world.

Number of users has little correlation with number of lines of code.

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

#252
post #87

Earlier quoted context omitted.

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.

JS requires a runtime, so by definition there would have to be something (even if it’s just a bastardized gc-free version of JS itself).

Technically so do the native platform frameworks: they just come with the system.

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

#253

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…

A lot of it is driven by differing low end data plans. In some countries even the cheapest tariff has adequate data allowance, in other countries, data is an expensive add-on.

So it's entirely conceivable that in some places, someone with a limited income only has SMS bundled as a free service on their plan, with data either not enabled, or expensive pay-as-you-go. Therefore in that demographic SMS messaging will be the primary method.

In the UK, almost all tariffs come with a bundle of data, so SMS has all but died out (except for automated parcel delivery updates, and 2FA authentication et al.).

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

#254
post #142
post #120

Earlier quoted context omitted.

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat To be fair, this is part of the problem ^

It's an inner-platform effect, certainly, but not one FB asked for. If they were allowed by the app-stores to factor their app into separate "plugins" that were auto-installed when a friend used them in a chat, the way iMessage does, they'd probably do that. But they're not allowed to have their own seamless plugin ecosystem, so into the monolith everything goes.

Facebook and all the rest benefit from developing closed ecosystems that others can't benefit from. It's not a coincidence that their systems are systems-within-systems.

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

#255

Earlier quoted context omitted.

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 c…

To be fair, small fast messenger 2020 is "better" (aka more features / millisecond of cold start) than small fast messenger 2016. The cycle doesn't always go up monotonically, even if developers pretend it does. But it is possible to go "full-circle" through the loop and wind up in a better place than you started, and it's even possible for each stage of the loop to be truly justified given product needs.

indeed, it could be rational business needs. at a time when it's more expensive to hire devs, maybe it looks better to have a single codebase. at a time when performance is more valued, maybe it's better to rewrite in native.

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

#256

Too little and too late. I feel like they lost a whole generation of people.

I tried to use FB Messenger for a group thread for a ski trip, and I got a resounding "ok boomer".

off topic, but I absolutely hate the millennial put-down of 'ok boomer'. They use it for anyone who is older than them, regardless. I'm Gen-Z and being called a 'boomer' is offensive.

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

#257
post #219

Earlier quoted context omitted.

From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000." Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app. See also: this other comment - https://news.ycombinator.com/item?id=22468036

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.

> Since then, we’ve added payments, camera effects, Stories, GIFs, and even video chat capabilities

Simple: they added tons of crap nobody care. On this list, I only use video. Messenger is valuable because of the network effect, but feature wise 2003’s MSN was good enough.

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

#258

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?

There's no mention either way. The article talks about a single C library and C extensions. And it mentions using native OS functionality. Those could be used from javascript or any language.

Yeah, which is probably why it's in C, portable AND callable :)

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

#260

Earlier quoted context omitted.

Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?

“I was instrumental in making Messenger twice as fast?”

I've made a bunch of things twice as fast people forget almost immediately.
Post reply on HN