Coder pour Android se fait normalement en Java, ce qui m’a permis d’appréhender le SDK Android assez vite, vu que je connaissais bien le langage. Puis on me parle un jour de Scala, langage qui monte à vitesse grand V dans la Silicon Valley.

Android mange du Scala = indigestion

Curieux comme je suis, je commence à me renseigner sur l’animal et ce que je lis est alléchant : programmation fonctionnelle, syntaxe concise et agréable, obligé de spécifier à la déclaration si l’élément est mutable ou pas, pattern matching. C’est donc logiquement que je me suis mis en tête de mettre du Scala dans Radis, mon application Android.

Je lis et vois plusieurs exemples de code Scala qui tournent sur Android : c’est donc possible, alors je me lance dans l’écriture d’une nouvelle fonctionnalité ! En effet, on peut mélanger du code Java avec du code Scala, et les deux peuvent interagir facilement. Les premières lignes compilées, je teste et ça fonctionne. Chouette ! Je continue à coder la fonctionnalité, j’ajoute des dépendances à des bibliothèques Scala quand soudain, c’est le drame.

La compilation échoue pour cause de limite du nombre de méthodes atteinte. Stupéfaction, je ne savais même pas qu’il existait ce genre de limitation. En creusant un peu, j’apprends qu’effectivement, les fichiers dex ont une limite à ce qui ressemble à max_int méthodes, et que le runtime Scala en bouffe beaucoup à lui tout seul. En parallèle, j’avais commencé un projet de client RSS en Scala pour Android, et pareil, juste le runtime Scala avec du Spring et c’était mort.

Tristesse ! Mais c’est alors que Swift est sorti pour iOS et que je me suis mis à chercher « Swift for Android ». Car oui, même si je ne l’ai pas expérimenté, sur le papier Swift semble être un langage très bien ; j’ai même interprété son annonce comme un aveu d’Apple sur la shittiness d’Objective-C 😄 (on peut rêver).

Kotlin, copain d’Android

J’ai donc croisé le chemin de Kotlin via un article au titre parfait : Kotlin, the Swift for Android. Exactement ce que je cherchais !

En le lisant, je vois que la syntaxe est très similaire et que la philosophie est la même que celle de Scala, sauf sur un point crucial : un runtime minimal.

Kotlin ne va pas chercher à recoder intégralement le SDK Java, il va utiliser les structures de données existantes et utiliser la force de ses extension functions pour rendre le SDK Java plus élégant, style Kotlin.

Me voilà donc en train de reconvertir mon code Scala en Kotlin, et les deux sont tellement similaires que le tout fut converti et débuggé en l’espace d’une demi-journée (pour la feature des graphiques, donc). Depuis, je convertis petit à petit le code Java vers Kotlin, lors de correction de bugs par exemple, et ce langage m’a permis de rendre le tout bien plus stable et m’a aidé à identifier les crashs de manière plus précise, notamment grâce au fait qu’il faille absolument définir à la déclaration si l’élément peut être null ou pas.

De plus, vu que tout est fait par la même boîte, l’intégration de Kotlin dans IntelliJ est poussée, et ils visent clairement tout le monde couvert par Java, sans oublier Android, donc.

Le langage a toutefois un souci important : il n’est pas encore en 1.0, ce qui signifie qu’à chaque sortie, il se peut que des choses ne fonctionnent plus ou pire, ne fonctionnent pas exactement de la même façon. Heureusement, le blog dédié au langage documente chaque changement et donne les outils (souvent intégrés à IntelliJ) pour faire la transition sans douleur. De plus, cette fameuse 1.0 a été annoncée pour cet été 2015, ce qui mettra un terme à ce bémol et permettra à Kotlin de prendre son envol.

Bref, je conseille à tout programmeur sur JVM de s’essayer à ce langage, et j’espère vraiment que la 1.0 lui permettra de gagner ses lettres de noblesse dans le monde professionnel. Moi, je sais déjà que tous mes projets perso Android seront en Kotlin 😉