(Filing to track and centralize discussion, since this has come up in several discussions.)
The number of generators in Pigeon is an issue for ongoing development (e.g., event channel support), and we are currently maintaining two generators—Java and Kotlin—for the use case of Android plugin development. Ideally we would only maintain one, and Kotlin has a number of advantages (true nullability support, more similarity to the modern generation of languages that also use, most notably Dart and Swift).
In favor of turning it down:
- Java/Kotlin interop is pretty seamless; in my experiment with some Flutter-team-owned plugins, I could replace the Java generated code with Kotlin generated code with almost no changes to non-generated code.
- It gives us stronger type safety all the way to the client-authored code boundary, so there's some incremental value in switching.
Impediments to turning it down:
- We are not using Kotlin in our own plugins currently, and don't have plans to switch in the near term, so we would be introducing an extra language (although not one we would need to interact with regularly as it's generated).
- Adding a Kotlin dependency to a plugin that didn't previously have one can affect plugin clients, and increase the incidence of ecosystem issues like Kotlin version mismatches.
(Filing to track and centralize discussion, since this has come up in several discussions.)
The number of generators in Pigeon is an issue for ongoing development (e.g., event channel support), and we are currently maintaining two generators—Java and Kotlin—for the use case of Android plugin development. Ideally we would only maintain one, and Kotlin has a number of advantages (true nullability support, more similarity to the modern generation of languages that also use, most notably Dart and Swift).
In favor of turning it down:
Impediments to turning it down: