Kotlin Meta and CT programming vs D

[Renato Athaydes]

On Thursday, 19 December 2024 at 06:04:33 UTC, Jo Blow wrote:
> But there have been several cases when I have asked others 
> about trying to do certain "compile time" things in Kotlin that 
> say it can't be done. It seems that there is actually no 
> compile time programming in Kotlin(and I guess Java too?)? That 
> at best one has to work in some DSL like thing that uses a 
> "plugin" but things that make D shine because you can just get 
> shit done, usually several ways, doesn't exist. Things like 
> string mixins, CTFE, etc. D would be an amazing language to use 
> if it was integrated into android studio like Kotlin.

Those features are exactly what makes D such a difficult language 
to provide good support for in an IDE. Even things that are 
trivial in languages like Kotlin, like removing unused imports, 
can't be easily done in D (I was told that in a discussion about 
why that didn't work at all with D).

Kotlin and Java have always taken IDE integration seriously and 
would not add a feature that "breaks" the IDE, even if that makes 
compile-time programming impossible. Reflection is heavily used 
by frameworks, but nearly never in application code, exactly 
because it makes IDE support and static analysis impossible.


> Anyways, the entire point of this point is to ask this 
> question: Is anyone who is pretty familiar with Kotlin and it's 
> compile time programming willing to explain what the heck is 
> really going on with it and why it seems so different to D's?

As someone coming the opposite way, D metaprogramming looks like 
pure magic. It's mind blowing (and so completely underrated, Zig 
is getting all the attention for having something similar but 
still less powerful). But yeah, the cost of those features seem 
to be bad IDE support, which kind of sucks, for sure.

Kotlin has annotation processors, like Java, which are about the 
only metaprogramming you can do outside of just writing code that 
explicitly generates source code (which you can do easily enough 
with https://github.com/palantir/javapoet for Java, or the Kotlin 
spinoff: https://square.github.io/kotlinpoet/

This is the current Kotlin solution: 
https://kotlinlang.org/docs/ksp-overview.html

As far as I know, almost no one uses this though. People are 
happy to just NOT do anything at compile-time, I guess it's hard 
to believe that if you come from D, but it's indeed possible.


> The way I see D's metal language was that essentially anything 
> that was "defined at compile time" could be treated as a 
> program at compile time and all the compile time information 
> would be filled in as such since it could. If code could be 
> determined to be completely well-defined at compilation then it 
> could simply be "executed"(evaluated) at compile time(in a 
> first pass). Kotlin doesn't seem to have anything like this. It 
> doesn't even have string mixins or eval without including a 
> kotlin compiler inside the language.

Correct. Kotlin and Java people would be horrified of those 
features, I think :D

Again, because of IDE and tooling support.

>
> I'm wondering if it would be worth the effort to try to get D 
> to work with android studio since it can compile to all those. 
> E.g., write the jetpack compose code in kotlin and hook up the 
> business in with D somehow. If it wasn't too much trouble and 
> worked well then this might give one the best of both worlds. 
> JNI is a bit of a PIA when trying to call java from C because 
> one has to use reflection for every aspect and it is very long 
> winded. This probably could be simplified greatly with some D 
> meta programming.

You're absolutely correct that with D, you could easily generate 
stuff like JNI bindings.

But notice that JNI is going to be replaced with a new solution: 
https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html

This is still in preview but you may want to look at it if you 
find JNI too horrible.

Regarding whether D could be a good option for Android, I very 
much doubt it. You can't remove the nice tools people are used to 
in the Java/Kotlin world, if you try you will get a very large 
backlash... and I'm afraid D will never have as good tools even 
if it some day gets huge corporate backing because the language 
was not designed to allow that to be possible (maybe it is 
possible, but I doubt it's actually feasible - correct if I am 
wrong), from the list of features it is very clear that was 
absolutely never a high priority concern.