Live data from Hacker News

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

engineering.fb.com

191–200 of 333 posts

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

#191
post #109
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…

Honestly, a chat app that 1 billion+ use per month that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat, and works across all mobile platforms, with nine years of technical debt, that thousands of developers build simultaneously seems WAY more complicated to me than any of your examples. Messenger may not have "HN clout" bu…

If raw complexity was the fundamental issue, trimming it down to a quarter of the previous size wouldn't have been possible.

Some of the problems outlined, like having 40 different views of contacts, with unique code, seem like fairly clear organizational problems.

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

#192
post #176
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.

And to keep people in the game to operationally care.

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

#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.

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

#194
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…

I thought this comment was making the opposite point, that it was impressive that Messenger was now only 360K LoC.

I honestly think it is. Compliers, DBMS, a library such as NumPy— they're all complex, but Messenger, even considering the features removed, is a very full-featured application. We're not talking IRC here. It has activity status, payments, stories, photo filters, audio messages, location sharing, video-calling, etc. It's actually pretty impressive that that fits in 360K LoC IMO.

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

#195
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.

You should call Facebook and tell them to fire the Messenger org because you have a great 5 person team that can do it for them.

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

#196
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

More like: make app hideous and bloated; make app slightly smaller; crow about your harvest of low-hanging fruit

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

#197
post #145

Earlier quoted context omitted.

> It's a chat app that works very well even on the crappiest connections 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 ter…

> I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined. You never used ICQ over a spotty 3G connection, though, did you?

I have, with an OpenVPN-over-UDP tunnel as a workaround. If they included Wireguard (or better yet, just used encrypted UDP) it would still be smaller (and probably more reliable).

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

#198
post #87
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.

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).

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

#199
I feel like I had an aneurysm reading this. For 6 paragraphs the repeat that they shrunk the lines of code down, that the rewrote the whole thing and that it’s a massive undertaking and that a message app should be small. 6 paragraphs of that slightly reworded and I just gave up. I honestly think this was written by a bot.

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

#200
post #145

Earlier quoted context omitted.

> It's a chat app that works very well even on the crappiest connections 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 ter…

> I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined. You never used ICQ over a spotty 3G connection, though, did you?

Not a lot of 3G coverage back in 1996, honestly.
Post reply on HN