It looks like polls aren't yet implemented in the rewrite?
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
101–110 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#102Was the previous one React Native? Seeing the talk about UI abstraction layers and given that this is Facebook
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#103The 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
Perfect :)
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#104So, 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's a chat app that works very well even on the crappiest connections. If it having 1.7M lines of code indicates anything it is that creating a "simple app that provides simple functionality over a network well" is hard . Look at the garbage generated by Google - text messages and images on Google hangout are not guaranteed to arrive in order ( or even be sent in order ) unless you are on a great network.
Ordering messages and providing reliability does not require 1.7M lines of code.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#105From: 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.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#106Earlier quoted context omitted.
Is this incompetence or aggressive data mining? I fail to see how a texting client is that complicated...
I think they went through a period (or still are, I honestly moved over to messenger lite a couple months into it) where they were seemingly intent on making messenger the WeChat of the west. It got real chunky real quick. It was around the same time everyone was excited about conversational ui and Microsoft announced their bot framework. It may have been slow and bulky before that, but that's when I started to notic…
They were trying to make it the WeChat of the non china east and africa, not the west. And they've been pretty successful at that, "messenger" is almost synonymous with "Internet" in some parts.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#107So, 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's a chat app that works very well even on the crappiest connections. If it having 1.7M lines of code indicates anything it is that creating a "simple app that provides simple functionality over a network well" is hard . Look at the garbage generated by Google - text messages and images on Google hangout are not guaranteed to arrive in order ( or even be sent in order ) unless you are on a great network.
> 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 terms of security and scalability. I'd be curious to know what's hidden between the millions LOC.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#108Not sure how much impact this will have, most of the people I know and have discussed this with fall into two camps: people who use FB a lot an will put up with a bad mobile client, and people who don't want FB on their phone, ever. I have to go years back to think of someone who told me they just couldn't take the bad UX of the clients so they deleted it.
Well hello. I've stopped using Snapchat and started using Instagram for stories because the experience, while still not great, is about twice as good.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#109So, 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" but the devs who work on it are having some of the greatest software impact in the world.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#110Sounds neat, but I’ll continue to use “request desktop website” on mobile safari in a vain attempt to prevent running whatever else this app does besides chat.