Do you think Kotlin could ever support being run t...

# language-evolution

[stantronic]

Do you think Kotlin could ever support being run through an interpreter? I'm a big fan of compose multi-platform, but I miss the fast hot-reloading of flutter and react. It would seem that having Kotlin run as an interpreted language would be a vital step in achieving hot-reload for Compose.

[Joffrey]

I hope this will never happen. The whole point of the compilation step is to prevent errors that could be detected by the compiler from making it to the runtime. Going interpreted just for the sake of a faster hot reload would throw away this benefit and let some errors slip as long as you don't hit the problematic piece of code during your manual tests. With incremental compilation and a warm daemon, compilation should be or become fast enough for hot reload.

[Joffrey]

What numbers are we talking about, by the way?

[stantronic]

numbers? do you mean how fast?

[stantronic]

you would still have compiled mode for release builds. interpreted mode would be for developing the UI - like dart.

[Joffrey]

Yes, like how fast a reload time would be acceptable to you? And what are you witnessing right now?

[stantronic]

well flutter works within a second or two. compose works differently on different platforms, but i use incremental compilation, and on Android still takes about a minute

[Joffrey]

Ok thanks!

[eygraber]

Depending on what I'm doing, I can get sub 5 second incremental compilation on a pretty large Android project with Kotlin and Compose

[eygraber]

Most of the wins come from setting up Gradle correctly (especially configuration cache)

[stantronic]

wow. wish i knew how to get that fast. we might be hindered by a couple of gradle plugins we use...

[eygraber]

It's been a big multi-year effort that's ongoing, but the benefits are worth it.

These were a big influence

https://developer.squareup.com/blog/herding-elephants/
https://developer.squareup.com/blog/stampeding-elephants

[stantronic]

thanks 🙂

[Tadeas Kriz]

Huge benefit of interpreted mode would be hot reloading without leaving the screen you’re on. Also it’d enable faster dev loop on Native.

[Joffrey]

@Tadeas Kriz I haven't done mobile development for a long time, so I cannot comment on Android/iOS dev specifically. But we can't make the general assumption that hot-reloading a given screen requires interpreted mode. There's likely other areas that can be improved to enable fast and/or partial hot-reload. In Kotlin/JS, the resulting JS can be reloaded just like any other JS, and interpreting Kotlin wouldn't help. For Native, I'd much prefer the Kotlin team to focus on the compilation time and incremental compilation of native targets than on building an interpreter that would interop with native platform calls in the same way as the compiled native Kotlin code

[Tadeas Kriz]

The issue with native is, that it's not as simple. Because of memory layouts, linking and using platform code, you can't easily hot-reload stuff without losing state. So either there would have to be a special dev mode that stores data differently, or you're stuck with a lot of restrictions. On the other hand having a interpreted dev-mode for Kotlin itself is a net benefit, because it makes Kotlin more powerful and would certainly make it so much better at writing scripts too. There's essentially nothing to be lost, everything to be gained.

[Joffrey]

There's essentially nothing to be lost

I'm ready to accept that you want to ignore the loss of the benefits of Kotlin's type system and advanced compiler errors, on the assumption that we're using an IDE in dev mode (which is not true for plain scripting), and thus it's already running the compiler for us in real time (so the developer is likely to see errors in at least a part of code).

However, we can't ignore that developing such a thing would imply deallocating resources for other things, and that is a huge drawback that needs to be part of the analysis.

[Tadeas Kriz]

We wouldn't be losing the benefits of Kotlin's type system. The changed code could still be type-checked before sent to the target platform to be run. Most importantly, you'd still see errors in IDE and during non-dev build which would always be pre-compiled as usual.

I chose to ignore "deallocating resources" because that's something the two of us can't really compare, because there's a lot of nuance.

[Tadeas Kriz]

Getting improvements in incremental compilation and speed is important, but there's only so far you can get with it and as I mentioned, on native you're not getting over some issues that might not be solvable (look at how long Swift or Rust compilation takes and they've been working on it for years). So it might be fine to have a long release build if the dev feedback loop is shortened to seconds by the interpreted dev mode.

Sidenote: with the interpreter mode, you could be deploying the changes to multiple devices and platforms instantly. You could have the same app running on iPhone and Android side by side and see the changes right away.

[stantronic]

Yep good point. Its like the "flutter octopus" demo where you hit save and see changes instantly on 8 platforms at once. Its impressive, just that Dart is nowhere near as nice to code as Kotlin. (imho).

[Tadeas Kriz]

I've talked to a couple of Flutter developers and they were like "We'd love to use Kotlin, but want to do Flutter, so there's no other option than Dart" 😄

[Sam Stone]

Cash App’s Redwood and Treehouse libraries are experimenting with something pretty similar using Zipline to convert Kotlin/JS to Compose.

[mcpiroman]

loss of the benefits of Kotlin's type system and advanced compiler errors

Interpreted mode does not imply that. All the compiler frontend part, including type checking and analysis would still (need to) be run. Same as all the IDE diagnosis, if you're using IDE.
Interpreted != python.

It rather means that, later, instead of compiling the analysed code to some standardized form, such as bytecode or native code, saving it on disk, loading from disk by VM or OS, and then running, interpreter would run the kotlin code directly from memory, with just a minimal amount of intermediate transformations. Minimal still means quite a bit, I think, but even then the overall process from source to execution should be way faster.