https://kotlinlang.org
Join Slack
was it ever seriously considered to implement the Kotlin compiler in something like Rust? omitting t...
# compiler
p
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?
d
First question is why it is needed?
h
The Kotlin compiler still depends on Intellij language apis and some java libraries, so you need to replace these apis.
p
better performance and lower memory usage
what inspired me is https://github.com/charliermarsh/ruff, a modern replacement for pylint. Runs blazingly fast
of course Python’s and JVM’s performance are in different grades, but still
d
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
h
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?
p
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
h
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.
p
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
d
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
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
p
got it, thanks! 🙇
h
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.
And of course rewriting the compiler (again) would slow down new features.
d
^for another five years
p
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?
h
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.
d
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
p
“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
I get the point, the performance issue of the compiler itself may not be a real issue actually
m
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.
p
optimizations can also be introduced iteratively instead of big-bang rewrite. This makes a lot of sense
m
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.
6 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by