Hacker News Reader

Comment by strulovich | Hacker News Reader

Hi HN! I’m the author of this post. I’d be happy to answer questions here on this subject!

Hi! Congrats on the huge accomplishment.

Is that list of disadvantages really accurate? Reading them, I get the impression that the "popularity gap" between Kotlin and Java was a major reason FB was behind the industry on converting to Kotlin. (For context for non-Android engineers reading this, Kotlin has been the first party recommended language for 3 years now, and has been supported for 5 years) I can't imagine y'all were interviewing Android candidates in Java? And while certainly the Kotlin ecosystem as a whole is smaller than the Java ecosystem, the Java Android ecosystem is miniscule.

My recollection from my time in the building at IG was that build times and binary sizes were the two heaviest lifts, almost to the exclusion of anything else. Am I misremembering, or did the conversation change? Or does that list of tradeoffs reflect a realization by your team that you'd need to convert everything to Kotlin, not just the Android code?

> Is that list of disadvantages really accurate?

I think this is a good depiction of our worries. Our biggest is and always was build times.

> I can't imagine y'all were interviewing Android candidates in Java?

We let people choose their preferred language for a while now. Also, while this blog is celebrating some milestones in the conversion, some smaller apps and new code was using Kotlin for a while now.

> My recollection from my time in the building at IG was that build times and binary sizes were the two heaviest lifts, almost to the exclusion of anything else. Am I misremembering, or did the conversation change? Or does that list of tradeoffs reflect a realization by your team that you'd need to convert everything to Kotlin, not just the Android code?

Binary size has generally not been an issue. Build times are an issue. We migrated and migrating some optimizations we have to alleviate that. We're also crossing fingers for more wins from the new Kotlin compiler JetBrains is working on.

I hear that KSP makes a huge difference, as you call out. Not an easy task to get rid of kapt, though, so - good luck! And again, congrats. :)

I know it’s not the NYT, but just curious how it feels to wake up and see your work on the front page of HN

It’s pretty nice. :)

This post is the (pretty short) summary of a lot of work which took us a long time to do. So it’s nice to get any kind of validation.

Personally I read HN a lot and it’s my main source for interesting articles nowadays. So that makes me appreciate HN upvotes even more.

For us hackers, it's better than the NYT!

Yeah. NYT reporters don't show up here to answer our questions.

1) Is that a mono repo?

2) If not, how many LOC is the largest Kotlin repo?

3) How do you tackle challenges of large codebases like language servers/synthax highlighting crawling to a halt in IDEs?

I don’t know about this area in particular but almost all FB code lives in a handful of very large monorepos.

1 & 2) Yes, almost all of the mobile code lives in one repo, and the 10M number quoted is all in one mercurial repo.

3) There's a lot of different things we do to work around such issues. Some things that come to mind right now: - We have plugins for Android Studio to avoid loading all the code at once that help. - We had forks for the Kotlin plugin for Android Studio to deal with some issues that were worse for our repo. (especially around module loading) - We also worked with JetBrains by pushing some fixes and they fixed a lot of the issues over time. - We do a lot of work as async jobs that run on the repo without you waiting for them, so you don't have to wait for such tools.

Have you released the source code for the following (primarily running AS in headless mode). It's something I've wanted to look into adding into our CI:

> As part of this step, we also apply our autocorrecting linters and apply various Android Studio suggestions in headless mode.

No. It's pretty coupled with a bunch of our pipelines.

I'll check again with the people who built it and see if it's doable to open source it.

Thanks! If you manage to get it out in the open, could you send me a ping (email is on my profile). Happy to put in the effort to get it usable.

What's the share of React Native in your apps and where it is used? Also, what about Obj-C/Swift?

I'm not the right person to comment on the React Native part. (There's definitely quite a bunch of React Native in the app on top of the Kotlin)

Other people are also working on Obj-J/Swift, but from my superficial knowledge I think it's a much harder migration to do. I really think the Kotlin team did amazing language and tool design which makes Java to Kotlin migration easier than almost any other language migration I could think off. Kudos to them.

Why does meta have 10 million lines of code just for Android?

I too would like to know how this is justified.

> Today, our Android apps for Facebook, Messenger, and Instagram each have more than 1 million lines of Kotlin code, and the rate of conversion is increasing. In total, our Android codebase has more than 10 millions lines of Kotlin code.

Probably 1000 engineers working on an app with each writing 1000 lines of code. I am not surprised Facebook app has >1 million lines of code. The app is bloated with features that it's user unfriendly.

I have parents that are pretty not tech literate (they didn't how to save contact or send SMS) but they have no trouble navigating Facebook app for the core set of features they use.

I would like to know your arguments against it. How would you define a maximum count of LOC, why would you set that particular limit, and how would you address the "problem" if your team were to hit that limit?

There's many reasons, so I'll give it a try:

- There's a few apps here. Plus a bunch of tools.

- The Facebook app is huge in terms of features. Just look at the menu with more things. I use very few of them, yet they're all pretty popular and justify themselves.

- Instagram is smaller than Facebook, but still has a lot in it.

- A lot of our code was optimized over time in many ways that add a lot of edge cases: internationalization, accessibility, optimizations for dealing with media, loading and data. It's can be easy to write something with much less code that looks pretty good at first sight, but all those extras really make the experience better and pay off for users.

- We build new features all the time, some code may be unreleased, some is in A/B testing and so you can have two or more pieces of code that do the same.

- A lot of test code.

- Not that much dead code. Trust me. I love deleting code! And I will happily spend time removing bloat. There's definitely a lot of dead code to remove, but it won't change those top line numbers by much.

(Also, it's 10M Kotlin lines of code, we have much more)

(I would love to know how many lines of code the other really big companies with big mobile apps have for comparison)

> just

Where did this come from?

Please see The Thirty Million Line Problem https://www.youtube.com/watch?v=kZRE7HIO3vk

Reply on news.ycombinator.com