true, and databinding was written in Kotlin at some point IIRC? What I meant was more that they still aren't proponents of doing apps the way that most people do them for modern Android development, so it's not like we're sticking to Google's advice very tightly as it is, anyway

They took Kotlin out of the databinding tool (it was causing some random issues to people who were using Kotlin in their apps).

I'd imagine anything Google does to make Kotlin difficult to use would have to break a lot of other libraries as well, too

To break Kotlin that would probably also break a bunch of libraries, yes. But they could do something stupid and say “We’re making Java legacy only, all new apps will be written in Go!” But that would break all your existing code anyway, unless they also provided a Java -> Go converter. So there are imaginable scenarios, but not likely scenarios in my opinion.

there'd be no way a migration tool would work in a scenario like that. The amount of libraries that rely on generics, annotation processors, etc, is massive, and they would be completely broken in the process

Well, they could certainly write a bytecode -> .lib with go annotations convertor, that would make most existing code work (annotation processing would obviously have problems). But as I said I think this is pretty unlikely, and it’s somewhat pointless to speculate on. What I do believe is that any non-cataclysmic compatibility issues will be addressed by JetBrains.

yup, and I think any cataclysmic compatibility issue would cause major problems for non-Kotlin codebases too. Kotlin generates Java bytecode anyway so in your case, the converter would just run on the emitted Kotlin bytecode 😛

sure, Google hasn't embraced it, but they also haven't embraced the mile-high stack of libraries from Square and the like that we all use to make Android dev tolerable, anyway 1 reply Actually, OkHttp is used within Android since KitKat IIRC. Google also experimented with Kotlin on Android, provides early Android Studio builds to JetBrains for Kotlin support, and acknowledged it on the release notes of a canary build of Android Studio. Maybe there'll be some announcements soon

Where did Google experiment with Kotlin on Android?

Aside from code inside the IntelliJ platform and latent code from the databinding prototype I haven't seen evidence of them experimenting on Android anywhere. Only for Android tools.

@jw Temptation: https://twitter.com/romainguy/status/675584817912680448 Experimentation: https://twitter.com/romainguy/status/812454073232453632

That was to write a path tracer on my desktop machine

Quite a far cry from experimenting on Android :)

But the fact you're here almost proves you're experimenting with Kotlin on Android 😉

Or maybe the experimenting stage is already behind you

I'm also on the gamedev channel and I don't write games :)

nope, you want

object

then I guess

@romainguy But you definitely work on Android 🙃

Somebody got Litho running with Kotlin ?

does it use any special build time stuff?

if no, I doubt there's anything blocking you from using it with Kotlin

@danneu has left the channel

is anyone using Buck (https://buckbuild.com/) instead of Gradle for their build in real production non-trivial apps? 16 replies @bulwinkel thanks for that YT link. Benchmarks benchmarks so YMMV but good to see they have some ambitious performance goals in mind

Has someone tried espresso tests with kotlin coroutines? Coroutines don’t start if I run an espresso test. Meantime if I just start the app, the coroutines work.

@jarp has left the channel

is anyone using Buck (https://buckbuild.com/) instead of Gradle for their build in real production non-trivial apps? 21 replies I'd be hesitant to move away from Gradle for a few reasons: 1. It's the default supported build system. There are a lot of really useful services that require gradle plugins to use (i.e. Crashlytics). You could go off on your own and support this through buck, but it'd be painful. 2. Gradle has actually gotten it's act together. There is a nominal difference in compilation speed between Gradle and Buck (or Bazel). Performance improvements have been a huge focus in the past few release of 3.x. With Gradle 3.5, they've even added a proper build cache (and even a distributed cache like buck!). The reason why your Android builds are slow right now isn't because of Gradle, but rather because the Android Gradle Plugin is slow, and the Android Gradle build tasks, don't yet take advantage of all the new fast awesome features from Gradle yet (i.e. none of the Android build tasks can be cached yet). The Android tooling team, and Gradle have been working closely to resolve this for Android plugin version 2.5 (which I'm REALLY looking forward too). You can read about it, and see some early benchmark numbers here: http://tools.android.com/tech-docs/new-build-system/2-5-alpha-gradle-plugin

Scott, I really wouldn’t know why everybody and his uncle is doing build systems currently. make, cmake, sbt, maven, ant, gradle, rebar … I probably miss twenty-odd others. I think it’s a waste building and maintaining so many systems that basically do the same. I would say stay with gradle.

And what about languages? Why everybody is making languages? 😉

Hmm, anyone ever tried to FatAAR the Kotlin standard library? E.g. to ship it inside the AAR?

Hey, do you know if gradle plugin checkstyle is working with Kotlin? Im getting troubles to get it working, it seems that Kotlin .kt files are ignored even when I specify them in task settings