The inside story of Threads

Agreed. There are a lot of really smart engineers at these companies. No doubt about it! They often have to pioneer solutions to challenging problems, which have downstream benefits for everyone else.

I do wonder though if we will look back on this period in history and regret the economic and cultural incentives which have co-opted so many smart people into the service of ... advertising.

I have a totally opposite view. FB at least is an "easy" problem in that it's a free product that's mostly casual use. The end result I see is that FB is massively inconsistent, you can literally see different parts of the FB system having a different view on a moderately heavily commented post. Comments will pop in and out of existence on a given device, and different people will have wildly different views for up to a few minutes. If accuracy mattered FB would be just awful.

I wonder if there were also people motivated by their hatred of what happened post Twitter. I recall that Meta hired a bunch of ex-Twitter people. Some probably had an axe to grind.

Whatever they did Twitter folks or not, it was an extremely slick launch. Any Threads people reading this should pat themselves on the back.

On a side note: It was also fun watching Musk fuming that week when the Threads numbers came in. :D

lol. i have respect for these skilled engineers. but let's not pretend making posts show up on a feed is as difficult as curing cancer.

half the time my app screen freezes or there's an issue with posts showing. it was good at the start and that's how fb gained users, but at this point people put up with the poor UX because of friction.

Isn't instagram using more or less the same tech stacks they were using before the acquisition?

See their friends updates instantly? Is this a joke? You do realize real-time reverse chronological feeds are long dead right? meta optimizes for the "algo", which is to shove ads and influencers and trending nonsense in front of your face.

To be fair, users did have to install an app and go through the onboarding to be counted. That is a big ask for most users! That wasn't the case for Google+ where they straight up just considered all Google accounts to be Google+ accounts suddenly. And that was on the web where you don't have to install anything.

But I don't disagree, saying they got a lot of signups doesn't mean it's a home run success. Myself and most of the people I follow on IG signed up within the first few days, made a post that said something along the lines of "what's a Threads" and then haven't posted since then.

If my app uses Google login, an I not allowed to count those users because I simplified their sign up flow too much? Your stance on this basically makes no sense.

With SwiftUI and Kotlin Jetpack Compose you can write architecturally and syntactically similar code across the two platforms. Essentially the same compact classes with the differences just being view property differences and OS API discrepancies (location, etc). So it's become a lot easier to manage separate development while keeping design direction and architecture on the same page. This is more so the case for apps with simple aesthetics and simple user interactions like Threads. It's not necessarily a sign that they are dropping support for React Native.

I don’t think they’ve ever really built entire apps in React Native outside of maybe messenger? Usually a few screens are implemented in it and the rest native. Or maybe features are prototyped in it and later rewritten.

They actually did another article with some good history on the iOS app for Facebook: https://engineering.fb.com/2023/02/06/ios/facebook-ios-app-a...

It means you get many more promotion points for creating a new framework and shipping it in a new product.

Also, generally internal tools are exceedingly poorly documented and supported so it seems easier to write your things from scratch.

Geez what an oversight

Also some more details here, interviewing two team members:

https://newsletter.pragmaticengineer.com/p/building-the-thre...

I'm baffled by the amount of interest in Threads, but I guess some of the technical stuff is novel? I don't know a single person who uses it.

The only lesson to learn from this is that given exceptional resources and a long list of talent any stack can be made to scale.

That doesn't help most projects in the world.

(I use django in production myself, nothing against it)

It's probably worth noting Meta made their own JIT'd version of CPython just for Instagram/Threads. Maybe mastodon devs can use their interpreter, but Meta's human/compute resources are magnitudes more than mastodon, the lessons from Meta might not be very applicable.

https://github.com/facebookincubator/cinder

I don't use Python or Django anymore but I'm always happy to hear about it and kinda surprised to learn it's still being chosen today for massive-scale social media sites. To me, Django was my go-to for cranking out a usable MVP in the shortest time possible. It made it so easy, I could define a DB schema and it would generate these forms with validation built in. I kinda miss those days.

There are a lot of things that goes on in production to scale any service to handle that level of requests. But Django as a web framework is good at what it does. It comes in with most things that one needs to put web apps in production.

We recently open-sourced an LLM apps platform (https://github.com/trypromptly/LLMStack) that is entirely built with django as backend (drf for APIs, channels for websockets and reactjs for frontend).

Mastodon has such a different system architecture—at a business level—that I think many of the scaling challenges are entirely different. While my experience with Mastodon is as a (very satisfied) user, in general scaling challenges are as much figuring out how to scale the interactions between systems as they are scaling the individual systems themselves. That gets incredibly more difficult when those individual systems are spread out among various organizations with different priorities, philosophies, technical abilities, and resources.

This is largely due to Meta maintaining an internal performance-oriented production version of CPython: https://github.com/facebookincubator/cinder .

Python/Django (and most other frameworks) isn't the problem with scaling. It's following the 12-factor app rules.

Python is known to be pretty wasteful in terms of compute performance, but is the compute grunt of a given node a big deal in these kinds of networks? I assumed it is a big communication problem. Python shouldn’t hurt there, right? It isn’t like a Python-generated packet goes through the network more slowly.

> t would be possible for Mastodon to learn from this so that they too can scale to 200 million users.

I mean possibly, if it was designed to be a centralised bohemoth with a staff of 600 to look after it.

Its decentralised by design, much like the web used to be.

So did they setup a separate backend for threads or did they just extend the current instagram backend to support text posts?

These systems should not scale. Giving everyone free broadcast capability is a sign of mentally bankruptcy.

Its like giving every neuron in your head broadcast capability. What happens when they all fire at the same time? Or like giving everyone in the world a radio transmitter that can broadcast on any frequency. What happens when they all transmit on the same frequency at the same time?

These idiots are scaling things because its become possible technically. There is no other logic to whats going on. And its producing/enabling massive amounts of useless noise. The UN report on the Attention Economy says 0.5% of content on the net is actually consumed by anyone.

The best way to stay in the loop on federated social media trends is to join a fediverse instance.

It gets discussed a lot there.

Anecdotally, there was a lot of discussion within the fediverse when threads was announced and the general sentiment that a lot of people had, was that instances should immediately defederate from threads to avoid eternal september.

Personally, I argued for staying federated with them because I think that would lead to a healthier fediverse. What I envision is:

1. Most normal individuals will be on a corporate-backed, ad-supported instance like threads.

2. Companies and governments will be on custom-domain instances managed by a fediverse service provider who they pay directly, both for branding and in order to avoid being beholden to the poor customer service of the corporate-backed instances.

3. Some tech-savvy individuals will be on small or self-hosted independent instances that provide a differentiated experience in some way. (This is most of the current fediverse)

This is basically how email works now and so it seems like the most likely end-state.

How so? Aside from the name change X was exactly the same experience that Twitter had been giving for a decade or more.

Mastodon stats: https://fediverse.observer/stats

I haven't found public stats for any of the others.

You can get a sense for bluesky from the AT firehose: https://firesky.tv/

Apply for a job there, and you'll quickly learn.

Musk is definitely unhinged on his ADL attacks, but the ADL has some... strange takes.

They have whole articles on how the Bowl Cut and the OK symbol are hate symbols. For the OK symbol they have nested "disclaimers" (why these are not prominent right from the get-go is beyond me, however). And the bowl cut page doesn't even hold any disclaimers at all - as if the 5 year old whose Mom doesn't know how to give a haircut is really very dangerous?

* https://www.adl.org/resources/hate-symbol/bowlcutdylann-roof

* https://www.adl.org/resources/hate-symbol/okay-hand-gesture