La ontología de Kotlin

Hay una diferencia enorme entre saber escribir Kotlin y saber qué hace Kotlin, y esa diferencia es exactamente la que separa a quien colecciona recetas de quien predice el comportamiento de su programa antes de ejecutarlo. Casi ninguna característica del lenguaje es puro maquillaje sintáctico sobre lo mismo de siempre: casi todas son transformaciones concretas del compilador, con un código generado concreto y un coste concreto. Marcar una función como suspend no la vuelve mágicamente asíncrona, sino que añade un parámetro oculto de tipo Continuation y reescribe el cuerpo como una máquina de estados donde cada punto de suspensión es una etiqueta a la que se puede volver; por eso las corrutinas son baratas y por eso una suspensión dentro de un bucle cerrado tiene un coste que se puede razonar. Marcar una lambda como inline no es una sugerencia de rendimiento: elimina literalmente la asignación del objeto lambda copiando el cuerpo en el punto de llamada, que es la razón de que let, apply o forEach no generen basura y de que return no local funcione. Una data class no es una clase con menos ruido, sino una clase para la que el compilador genera equals, hashCode, toString, copy y los componentN, con todas las consecuencias que eso tiene sobre la herencia y la compatibilidad binaria. Una value class a veces desaparece por completo y a veces hace boxing según dónde aparezca, y saber en qué casos ocurre cada cosa es la diferencia entre una abstracción gratis y una abstracción cara. Quien aprende Kotlin como una lista de idiomatismos que hay que imitar se queda en la superficie y se sorprende cada vez que el perfilador dice algo raro. Quien aprende qué genera el compilador en cada caso puede leer el bytecode cuando hace falta, predecir el rendimiento sin medirlo a ciegas y diseñar APIs sabiendo qué le está pidiendo a quien las use. Ese es el nivel al que apunta este track.