Even more provocatively, do these so-called costs actually result in performance penalties (given how the JVM actively optimises code at runtime, compiling it to efficient machine code based on actual usage, the answer to this question may not be as clear as it seems)?
Without putting numbers to the hidden costs, that's impossible to answer.
For that reason, I decided to write JMH benchmarks
to try to quantify the actual costs of each Kotlin construct mentioned in all the 3 parts of that blog post series published so far.
Methodology and system
Some of the Kotlin constructs' costs mentioned in the blog posts can be directly compared to the equivalent Java construct. For example, the cost of Kotlin lambdas can be directly compared to the cost of Java lambdas. However, many Kotlin constructs don't have a Java equivalent, in which case instead of comparing the Kotlin construct with the equivalent Java version of it, I compare them with the author's suggestions to improve on the costly constructs.
If you do run them, beware the full benchmark takes a few hours to run.
All results were collected using the following system:
Macbook Pro (2,5 GHz Intel Core i7, 16GB of RAM)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
The Kotlin version (1.1.3) and JMH (0.5.6) are the latest as of writing (see the pom.xml