That's not true, Spark's entire query engine relies on use of runtime codegen via macros/quasi quotes

Look up the architecture of Catalyst + Tungsten

https://www.databricks.com/glossary/catalyst-optimizer

Scala 2's macros are compile time constructs. There is no runtime code generation / staging.

Scala 3's macros support staged compilation, so you can have macros which create code in later stages at runtime.

https://docs.scala-lang.org/scala3/reference/metaprogramming...

Catalyst uses runtime codegen, sure, but the OP wasn't using that.

Kotlins "ecosystem" is all of Java, and then all of Kotlin.

Put another way: Java only has access to a subset of the ecosystem

Almost all of the backend libraries I use are Java libs. Some of them have additional Kotlin extension libs that add syntax sugar for more idiomatic code.

There are Kotlin compiler flags to default to "indy" optimization, and which may be enabled by default for some time now?

Also not all Kotlin inlines are lambdas or even include method calls

The return type of a Java main is the JVM platform return type

Sending system signals is external to the JVM platform

This article specifically discusses calling external C ABI libraries via the FFM API.

GraalVM is for compiling JVM bytecode to native, architecture-specific binaries.

FFM is like "[DllImport]" in .NET, or "extern" definitions in other languages.

The article shows how to auto-generate JVM bindings from C headers, and then allocate managed memory + interact with externally linked libs via the FFM API passing along said managed memory.

BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong

May as well throw the Native Image C API for FFM-like capabilities out there too

https://www.graalvm.org/latest/reference-manual/native-image...

One of the neatest things I've been able to do is compile a .dll library "plugin" for an application which loads plug-ins by invoking a special exported symbol name like "int plugin_main()" using GraalVM and @CEntryPoint

The entrypoint function starts a Graal isolate via annotation params and no native code was needed

Don't we have JNI for that?

My org had to write a pivotal backend service on the JVM, due to JDBC having the largest number of data source adapters.

The choice was Kotlin. Scala is too "powerful" and can be written in a style that is difficult for others, and Java too verbose.

Kotlin is instantly familiar to modern TypeScript/Swift/Rust etc devs.

The only negative in my mind has been IntelliJ being the only decent IDE, but even this has changed recently with Jetbrains releasing `kotlin-lsp` for VS Code

https://github.com/Kotlin/kotlin-lsp

async-profiler

The killer is specifically the inlining of macros -- which Kotlin lacks.

And not all macros, but just the ones which expand to massive expressions

Think template expressions in C++ or proc macros in Rust

If your Maven/Gradle/SBT build specifies a version constraint for a third party lib, updating your Scala or Kotlin version doesn't affect this

(For scala-specific libs, there is a bit more nuance, because lib versions contain scala version + lib version, e.g. foolib:2.12_1.0.2 where 2.12 = scala version)

It would have been a transitive dependency based on the comments about the library being "transparent" and the author unaware it was even used.

Pinning specific versions of transitive deps is fairly common in large JVM projects due to either security reasons or ABI compatibility or bugs