5 ms·

> The irony being that most of the big shops are aggressively dumping it in favor of Buck — Facebook’s Android build system. Google is chasing a dying strategy

by yla92 9y ago

> The irony being that most of the big shops are aggressively dumping it in favor of Buck — Facebook’s Android build system. Google is chasing a dying strategy here. Igave it a try to a "small" project and there weren't any noticeable advantage over Gradle (and given that Instant Run is working quite well, it was really buggy when it comes out). I know for a fact that aside from Facebook, Uber uses it and comes out with a nice Gradle plugin for Buck called OkBuck[0]. I wonder what other big shops use as well. And I would like to know if anyone here has used it and saw any dramatic advantage over Gradle and worth investing time integrating Buck into current projects. [0]: https://github.com/uber/okbuck https://github.com/uber/okbuck

jmull 9y ago
I think of Instant Run as the "crash" button.
merb 9y ago
Well Google has their alternative to "Buck" aswell, called Bazel: https://docs.bazel.build/versions/master/tutorial/android-app.html https://docs.bazel.build/versions/master/tutorial/android-ap...
- izacus 9y ago
  Internally Google doesn't use Gradle at all (never did) so I have no idea what the author tried to tell with his paragraph. The fact that iOS is successful without a comparable build system (everything is bound to Xcode projects and tooling based on that undocumented changing format), makes me think he's overestimating importance of the build system.
  - NotSteveYegge 9y ago
    Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet. The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction. Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time. Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
    - pjmlp 9y ago
      And you haven't addressed the NDK, which is like life in the trenches of build systems.
    - izacus 9y ago
      > Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale. > Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet. Tools team is certanly aware of it. > The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction. Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor. > Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time. Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer. > Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past. Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.
      - vickychijwani 9y ago
        > Instant redeploy is very nice but hardly a huge deciding factor. I think you're wrong on this one. A large number of devs care about dev experience at the expense of other important things like platform maturity, reliability, and security. I don't agree with many of Steve's points in his post, but I do agree on this point. Both factors - x-platform development and instant redeploy - have contributed significantly to React Native's success so far. Indeed, if it weren't so important, I wouldn't expect Google to invest as much time and money as it did in getting Instant Run to work correctly (like others said, it was buggy as all hell when it first landed in Studio's stable channel and only became usable after many months). The fact that Flutter advertises "stateful hot reloading" prominently is just more evidence that it's important for attracting devs.
  - vorg 9y ago
    > overestimating importance of the build system True. Gradle (and its Apache Groovy build DSL) conquered a market by first creating that market. There's really no need for a build system with a procedural build language -- a declarative language to describe a build like with Make and Ant/Maven is good enough.
    - HillaryBriss 9y ago
      my recollection from the days of the Eclipse plugin is that building from a command line and building from the Eclipse plugin were two separate pathways. you could get a different apk building through the IDE than through some CI system running the build from a command line!! so, they addressed that pain point by using Gradle, which also did dependency management really well (compared to say Ant and, many would argue, Maven) and by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.
      - pjmlp 9y ago
        They could have sorted out that problem by using Maven and improving their Eclipse plugins, just like tons of Java developers do every single day. Instead someone at Googleplex managed to steer a team to rebuild the world to their favourite IDE and in the process reboot the whole Android development stack, which by the way is still not done. Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion not been released and to this day there wouldn't be a solution how to use the NDK inside Studio. I bet Google IO 2018 will again have a talk about how to improve Android build speeds.
        izacus 9y ago
        Pretty much anyone not insane these days is switching to the IntelliJ stack. Eclipse development is dead in the water and lagging behind more and more.
        pjmlp 9y ago
        I am yet to use InteliJ professionally, specially given that it requires more beefy computers than Eclipse. Indexing that one cannot turn off unless laptop mode is enabled, spinning the HDD all the time, really? Also none of our customers IT teams allows InteliJ on their leased hardware/VMs to external partners. The exception being Android Studio.

by yla92 9y ago

jmull 9y ago

I think of Instant Run as the "crash" button.

merb 9y ago

Well Google has their alternative to "Buck" aswell, called Bazel: https://docs.bazel.build/versions/master/tutorial/android-app.html https://docs.bazel.build/versions/master/tutorial/android-ap...

izacus 9y ago
Internally Google doesn't use Gradle at all (never did) so I have no idea what the author tried to tell with his paragraph. The fact that iOS is successful without a comparable build system (everything is bound to Xcode projects and tooling based on that undocumented changing format), makes me think he's overestimating importance of the build system.
- NotSteveYegge 9y ago
  Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet. The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction. Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time. Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
  - pjmlp 9y ago
    And you haven't addressed the NDK, which is like life in the trenches of build systems.
  - izacus 9y ago
    > Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale. > Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet. Tools team is certanly aware of it. > The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction. Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor. > Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time. Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer. > Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past. Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.
    - vickychijwani 9y ago
      > Instant redeploy is very nice but hardly a huge deciding factor. I think you're wrong on this one. A large number of devs care about dev experience at the expense of other important things like platform maturity, reliability, and security. I don't agree with many of Steve's points in his post, but I do agree on this point. Both factors - x-platform development and instant redeploy - have contributed significantly to React Native's success so far. Indeed, if it weren't so important, I wouldn't expect Google to invest as much time and money as it did in getting Instant Run to work correctly (like others said, it was buggy as all hell when it first landed in Studio's stable channel and only became usable after many months). The fact that Flutter advertises "stateful hot reloading" prominently is just more evidence that it's important for attracting devs.
- vorg 9y ago
  > overestimating importance of the build system True. Gradle (and its Apache Groovy build DSL) conquered a market by first creating that market. There's really no need for a build system with a procedural build language -- a declarative language to describe a build like with Make and Ant/Maven is good enough.
  - HillaryBriss 9y ago
    my recollection from the days of the Eclipse plugin is that building from a command line and building from the Eclipse plugin were two separate pathways. you could get a different apk building through the IDE than through some CI system running the build from a command line!! so, they addressed that pain point by using Gradle, which also did dependency management really well (compared to say Ant and, many would argue, Maven) and by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.
    - pjmlp 9y ago
      They could have sorted out that problem by using Maven and improving their Eclipse plugins, just like tons of Java developers do every single day. Instead someone at Googleplex managed to steer a team to rebuild the world to their favourite IDE and in the process reboot the whole Android development stack, which by the way is still not done. Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion not been released and to this day there wouldn't be a solution how to use the NDK inside Studio. I bet Google IO 2018 will again have a talk about how to improve Android build speeds.
      - izacus 9y ago
        Pretty much anyone not insane these days is switching to the IntelliJ stack. Eclipse development is dead in the water and lagging behind more and more.
        pjmlp 9y ago
        I am yet to use InteliJ professionally, specially given that it requires more beefy computers than Eclipse. Indexing that one cannot turn off unless laptop mode is enabled, spinning the HDD all the time, really? Also none of our customers IT teams allows InteliJ on their leased hardware/VMs to external partners. The exception being Android Studio.