Kotlin Meta and CT programming vs D

[Jo Blow]

I used to program in D heavily many years ago then stopped 
because, basically, the D ecosystem sucks. Amazing language but 
getting anything significant done was a PITA.

Anyways, I moved to Kotlin/android to write some apps about 2 
months ago and made great progress(I did more in 2 weeks than 
I've done in a year of D programming and this includes learning 
the language, the IDE, etc). Everything just worked as expected 
and was simple to use. Maybe the biggest issue was figuring out 
all the Gradle BS but I eventually got the hang of it. I was able 
to get a simple app to view PDF, play audio, jni(using FFPEG), 
etc within about a week. This is unlike D where basically you 
have 3 different packages you have to use, hope they work, and 
then figure out how to get them to work in the system. With 
android basically it just works and all the boilerplate crap is 
basically abstracted out(it's designed for a modern system rather 
than some console based system that D was). The IDE is pretty 
nice too since it works well with the language.

In any case, it was a great experience for the first month or so 
but then when I started looking for more complicated "D like" 
features such as CT/meta programming they don't seem to actually 
exist... at least not in the way one thinks and seems to be quite 
limited.

It has runtime reflection which, for the most part, is your 
standard introspection on types. It's not as robust as D's 
reflection and not compile time but there are some nice features 
that work well for basic stuff.

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.

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?

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.

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.