Hacker News Reader

Comment by keyle | Hacker News Reader

I have a genuine side question... Why does Meta have 10M lines of Java for their Android code base? What's in it?

(Android dev at Meta here, though not involved with the Kotlin migration. Opinion below, completely my own)

We have: public and internal apps, tests for those, tons of wrappers around Android APIs, autogenerated infra code, did I mention the API wrappers?, custom layout engines, duplicate code that people wrote because they couldn't be bothered to search the monorepo, code that was copied without much thought because people searched the monorepo and found something, app architecture tools like dependency injectors, annotation processors, custom build tooling, etc

If you can think it, someone has probably committed Java/Kotlin or native code for it already.

That makes sense. Thanks for the answer.

> duplicate code that people wrote because they couldn't be bothered to search the monorepo, code that was copied without much thought because people searched the monorepo and found something

This is also a very common way in Object-Oriented code bases to ensure you're not messing anything up by re-using classes. Concatenating yet another class to the code base is the safest and laziest way to ensure you're not possibly changing the behavior of anything else when you inevitably need to add/change something in the class.

We move fast and break things ;)

Why is this a OOP problem and not a problem in large code-bases in general? I can easily see it happening in functional or imperative languages where one creates an almost identical copy of a function instead of reusing and modifying an existing one.

While the reason people would be scared of modifying a class and a function could be the same, the way this defensive copy-paste of code would pan out is not the same; in one case we get an entirely new class, with all its nonsense in it (in many cases), in the other we get a new function operating on the same data types.

The former is not how OO is supposed to really work, but it is a direct result of adopting OO (non-obvious results of inheritance and other features) and in the latter we get exactly what we already were doing: Lots of functions operating on data, it's just more of the same.

It seems to me that one of these highlights the failure of its respective paradigm much more than the other.

I should note that I don't think functional programming as a paradigm is a particularly fruitful one. What I'm arguing for in the large, if anything, is bog standard procedural/imperative code with procedures/functions + data. Sprinkle in the few useful ideas functional programming does offer and you have something that has a fighting chance.

I don’t agree. What do you mean by all the additional nonsense if a class.

This sees to give an unreasonable leeway to copy pasted code to imperative functional languages. What if the copied function also has side effects, mutates a global variable etc. All these problems still exists.

Wouldn't it make more sense to do a massive refactoring given the situation is as you described? And, if needed, rewrite to Kotlin later. This would just cause the same problems to be reproduced in a different language.

No, the translation is mostly automated.

A rewrite, too, would take less than years, would have a better end result. Honestly the FB application is not exactly rocket science, and the massive amount of code they have points more on the direction of broken internal process and a total lack of simplicity in the design and choices.

There's a lot of subtlety in what exactly a "line" is, especially for Java and especially for a legacy enterprise codebase: hard to say that Meta's 10M is actually twice as big as someone else's 5M.

I have no clue what's in their code, but I would expect a lot of "almost redundant" stuff around specific Android versions, manufacturers, etc, which can really pile up.

I don't think people realize that "Android" at Meta is not just the "Facebook" app, but also: WhatsApp, WhatsApp for business, Instagram, the whole Oculus layer on top of AOSP, whatever they use for Ray Bans, etc.

As a consumer you're only ever seeing the tip of the iceberg of Meta apps. There are at least 3 major user groups: The consumers, the producers, and the advertisers, and each of them is at least as complex as the others. Then you have to consider the global audiences, and that e.g. ads are handled very differently in the EU than in North America, and that needs to be accounted for.

Java's how you wrote Android apps before Kotlin came out. I expect they have __all their existing Android code__ in Java. 10MM lines doesn't seem out of line for a very, very established company with 100k developers across several products. It's one of the 3 main platforms that people interact with Facebook on and so they'd want it to be as good and as fast as possible, especially on older phones for the time when Android phones were new.

Why they wouldn't use React Native?

  * Facebook Messenger came out on Android in 2011 [0]
  * React Native came out in 2015 is written in C++, Java, JavaScript, Objective-C, Kotlin [1]

[0] https://en.wikipedia.org/wiki/Messenger_(software)

[1] https://en.wikipedia.org/wiki/React_Native

So, even if they did use React Native, they still have 4+ years of code in the original language; and, React Native doesn't stop the use of Java

Most importantly, why was Threads not written in React Native?

Because Instagram wasn't, and Threads is pretty much a copy pasted Instagram codebase (for good reasons).

I'm pretty sure wg0 was being facetious.

I'm well aware of the history of Android, Kotlin and Java. Still my question stand...

Meta doesn’t have close to 100k developers.

All those AbstractContextFizzProviderMetaFactoryBuilderInjectorStreamManager quickly add up.

That is mostly a meme. What really adds up is putting every little thing into its own file and having an interface and a (usually trivial) implementation for everything.

Really the only question I have on this post. So many of their non ai updates make me roll my eyes

Reply on news.ycombinator.com