5 ms·

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

by strulovich 4y ago

johnwheeler 4y ago
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
- strulovich 4y ago
  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.
  - deleted 4y ago
    [deleted]
    - throwaway123f 4y ago
- pantulis 4y ago
  For us hackers, it's better than the NYT!
  - AnimalMuppet 4y ago
    Yeah. NYT reporters don't show up here to answer our questions.
hu3 4y ago
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?
- loeg 4y ago
  I don’t know about this area in particular but almost all FB code lives in a handful of very large monorepos.
- strulovich 4y ago
  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.
peterkelly 4y ago
Why does meta have 10 million lines of code just for Android?
- deleted 4y ago
  [deleted]
- bottled_poe 4y ago
  I too would like to know how this is justified.
  - deleted 4y ago
    [deleted]
  - nowherebeen 4y ago
    > 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.
    - kyawzazaw 4y ago
      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.
  - raydev 4y ago
    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?
- strulovich 4y ago
  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)
david_allison 4y ago
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.
- strulovich 4y ago
  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.
  - david_allison 4y ago
    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.
billjings 4y ago
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?
- strulovich 4y ago
  > 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.
  - billjings 4y ago
    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. :)
deleted 4y ago
[deleted]
zerr 4y ago
What's the share of React Native in your apps and where it is used? Also, what about Obj-C/Swift?
- strulovich 4y ago
  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.

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

johnwheeler 4y ago

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

strulovich 4y ago
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.
- deleted 4y ago
  [deleted]
  - throwaway123f 4y ago
pantulis 4y ago
For us hackers, it's better than the NYT!
- AnimalMuppet 4y ago
  Yeah. NYT reporters don't show up here to answer our questions.

hu3 4y ago

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?

loeg 4y ago
I don’t know about this area in particular but almost all FB code lives in a handful of very large monorepos.
strulovich 4y ago
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.

peterkelly 4y ago

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

deleted 4y ago
[deleted]
bottled_poe 4y ago
I too would like to know how this is justified.
- deleted 4y ago
  [deleted]
- nowherebeen 4y ago
  > 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.
  - kyawzazaw 4y ago
    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.
- raydev 4y ago
  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?
strulovich 4y ago
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)

david_allison 4y ago

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.

strulovich 4y ago
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.
- david_allison 4y ago
  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.

billjings 4y ago

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?

strulovich 4y ago
> 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.
- billjings 4y ago
  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. :)

deleted 4y ago

[deleted]

zerr 4y ago

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

strulovich 4y ago
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.