was it ever seriously considered to implement the ...

# compiler

[Piotr Krzemiński]

was it ever seriously considered to implement the Kotlin compiler in something like Rust? omitting the aspect of performance, I suppose Kotlin compiler’s API is not just the CLI (which would allow implementing it in whatever one wants), but it also exposes some libraries right? Any thoughts on this?

[dmitriy.novozhilov]

First question is why it is needed?

[hfhbd]

The Kotlin compiler still depends on Intellij language apis and some java libraries, so you need to replace these apis.

[Piotr Krzemiński]

better performance and lower memory usage

[Piotr Krzemiński]

what inspired me is https://github.com/charliermarsh/ruff, a modern replacement for pylint. Runs blazingly fast

[Piotr Krzemiński]

of course Python’s and JVM’s performance are in different grades, but still

[dmitriy.novozhilov]

Cons:
1. Incredible amount of time to rewrite everything (years)
2. Requirement to reimplement/find alternatives for JVM libraries which are used (like intellij was mentioned above)
3. Loosing an ability to natively use kotlin compiler in Kotlin IDE plugin
4. Breaking all tools and plugins in ecosystem which use compiler as library

[hfhbd]

Sure, there are some use-cases, like running the compiler in the browser for an offline playground feature, but do the use-cases outweigh the cons?

[Piotr Krzemiński]

I’m not saying it’s a good idea and it should happen, I’m just asking out of curiosity if it ever was considered. I personally don’t think the benefits would outweigh the cons and the cost

[hfhbd]

BTW the jvm isn't so bad regarding performance and memory usage. Switching to Rust/wasm etc doesn't automatically have a better performance or memory usage.

[Piotr Krzemiński]

also, the bottleneck now seems to be mostly Gradle right? I mean, in a typical use case of building a project, Kotlin takes only part of the time

[dmitriy.novozhilov]

It depends of lot of things
• is it pure build or incremental
• how is project organized
• which gradle features are used
• what other compilers and languages are used
If we are talking about pure compilation time, then K1 compiler is actually slow. But not because of JVM but because of not-very-good architecture
Rewriting frontend 1.0 to FIR (with the same behavior) we got ~4x frontend performance improvement

[dmitriy.novozhilov]

if it ever was considered. I personally don’t think the benefits would outweigh the cons and the cost

Never considered seriously, because there is (yet) not such advantage of it which can overweight all cons

[Piotr Krzemiński]

got it, thanks! 🙇

[hfhbd]

If you want to keep existing compatibility for ide plugins and other consumers, instead of using Rust, rewriting the Kotlin compiler to Kotlin common code would be an option/idea, but it still requires rewriting all jvm code/usages, especially IntelliJ and would take some time.

[hfhbd]

And of course rewriting the compiler (again) would slow down new features.

[dmitriy.novozhilov]

^for another five years

[Piotr Krzemiński]

rewriting the Kotlin compiler to Kotlin common code would be an option/idea

what would it give? do you mean using e.g. Kotlin/Native?

[hfhbd]

Nope, "real" common code with jvm, Kotlin Native, js, wasm targets, so you as consumer could switch the compiler implementation. But this is just an idea/construct.

[dmitriy.novozhilov]

BTW there is also one design reason, why kotlin compiler wouldn't be rewritten to another language: each good compiler should be able to compile itself
And kotlinc obviously can not compile rust code

[Piotr Krzemiński]

“real” common code

yeah, it would be cool (I actually have an use case to compile Kotlin code in the browser), but it doesn’t address the performance issue

[Piotr Krzemiński]

I get the point, the performance issue of the compiler itself may not be a real issue actually

[Piotr Krzemiński]

+ I’ve seen https://kotlinlang.slack.com/archives/C7L3JB43G/p1684239565041619

[mcpiroman]

When writing kotlin code I often miss some lower level performance features that e.g. rust would provide, but which JVM, at least right now, does not.
Still, I think making a huge project, such as a compiler, fast, is more of having smart algorithms and orchestration rather than overhead-free code (though apparently rustc has both). And making the former is actually still easier in kotlin. So even performance-wise I think starting of a compiler in kotlin itself was a good idea.

[Piotr Krzemiński]

optimizations can also be introduced iteratively instead of big-bang rewrite. This makes a lot of sense

[mcpiroman]

Very interesting example of this is GraalVM, which being a JIT compiler for JVM must itself be very fast, was written in Java instead of native code like it has been done to that point. I don't know if it really paid off, but there seem to be close competition between native code that is itself fast vs managed code that is easier to adjust to make it fast.