IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Kotlin 1.0 Release Candidate est disponible
Cette mouture apporte une amélioration du compilateur et des résolutions de bogues

Le , par Victor Vincent

349PARTAGES

6  0 
Le langage de programmation Kotlin est désormais passé de Bêta à Release Candidate. L’annonce a été faite dans un billet de blog publié sur le site de Jetbrains dans lequel l’équipe derrière le langage ainsi que la communauté qui la suit se réjouissent de cette nouvelle. La version 1.0 du langage de programmation a fait l’objet d’une recompilation complète, assure l’auteur du billet, Andrey Breslav, qui est l’un des concepteurs du langage chez Jetbrains. Il ajoute que cela a été fait dans le but de s’assurer qu’aucun code compilé avec les anciennes versions du langage ne subsiste.

Cette nouvelle version de Kotlin vient avec des changements considérables. Tout d’abord, l’équipe derrière le langage a tenu à faire un nettoyage. Ainsi les anciens éléments dépréciés du langage qui étaient marqués jusque là comme avertissements sont maintenant considérés comme des erreurs et les éléments dépréciés qui étaient générés dans le Bytecode ont tout simplement été enlevés. La plupart des changements apportés au langage en tant que tel constituent des changements mineurs et concernent le plus souvent des résolutions de bogues.

La nouvelle version du langage vient aussi avec le support d’une nouvelle annotation @delegate. Cette annotation permet par exemple pour marquer un objet délégué avec l’annotation @Transient, de faire tout simplement comme dans le bout de code qui suit :


L’auteur du billet de blog fait également noter qu’ils ont résolu dans cette version un nombre important de bogues relatifs aux projections de types. Le compilateur pourrait maintenant détecter certains bogues qui lui échappaient jusqu’ici dans le code source. Par exemple, le bout de code qui suit était accepté par erreur par le compilateur, mais ne l’est plus dans la nouvelle version.


Le compilateur arrive maintenant à détecter une erreur dans ce code et renvoie le message d’erreur suivant.


Andrey Breslav fait état également de certaines améliorations en ce qui concerne l’interopérabilité avec le langage Java, notamment celles apportées aux propriétés de synthèse dérivées du couple get/set de Java. La version 1.0 de Kotlin permet maintenant l’utilisation de setters Java qui retournent des valeurs. Par ailleurs, il a été ajouté à cette nouvelle version du langage, le support des annotations @Nullable et @NotNull ceci à travers plusieurs bibliothèques populaires telles que javax.annotations ou encore Android SDK.

La bibliothèque standard a également connu certains changements avec son code source qui a été redistribué entre plusieurs packages sans pour autant modifier le code source lui-même. Certaines fonctions ont été transformées en des fonctions de type inline et plusieurs de ces fonctions ne peuvent plus être invoquées à partir d’un code Java. D’après les concepteurs du langage, cela va aider à réduire considérablement la taille de la bibliothèque en exécution. Les fonctions Map.getOrElse() et Map.getOrPut() considèrent désormais les clés associées à une valeur comme manquantes et les fonctions mutableListOf, mutableSetOf, mutableMapOf ont été ajoutées pour la création de collections mutables. La fonction toArrayList a été dépréciée et remplacée par la fonction toMutableList. Les fonctions associate et associateBy quant à elles permettent la création de maps, elles remplacent respectivement les fonctions toMap et toMapBy. Les fonctions de comparaisons ont été déplacées dans le package kotlin.comparisons qui n’est pas importé par défaut.

Des améliorations ont également été apportées à l’EDI (Environnement de Développement Intégré) de Kotlin. Il s’agit notamment de la complétion de code qui suggère des noms de variable ou de fonctions basés sur les identifiants non reconnus dans le fichier courant. Les expressions when sont également autocomplétées et l’annotation @Suppress marche maintenant avec les inspections de l’EDI. Avec cette nouvelle version, si l’environnement d’exécution de Kotlin n’est pas configuré, l’IDE affiche une notification « Kotlin not configured » lors de l’ouverture d’un fichier d’extension .kt. Ces améliorations concernant l’EDI peuvent ne pas être prises en compte par les mises à jour automatiques d’IntelliJ IDEA, les utilisateurs de cet environnement de développement devront par conséquent télécharger et installer le plug-in proprement.

Source : blog Jetbrains

Et vous ?

Que pensez-vous de cette nouvelle version de Kotlin ?

Voir aussi

la rubrique Autres langages pour la JVM

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 20/02/2016 à 11:10
Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même. J'ai l'impression que c'est un compromis imposé au backend JVM pour le bénéfice de l'interop javascript, en réalité je suis pas sûr des vraies raisons.

Les points les plus intéressants à mon sens dans Ceylon et qui me manquent en java, soit

  • les properties (un remplacement de getter/setter sans méthodes détournées comme Lombok)
  • la distinction entre référence nullable ou non
  • Les variables immuable (final) ou non
  • l'inférence de type


Je les retrouve aussi dans Kotlin. En revanche, un point sympa dans ceylon qui n'est pas dans Kotlin, ce sont les intersections et les unions de type.

J'ai utilisé kotlin dans un projet non stratégique ces derniers jours (conversion de données) et je voulais tester en même temps l'interaction avec du java standard. J'ai utilisé l'une des choses les plus moches de java, soit du JAXB dont j'ai recouvert mes classes kotlin d'annotations. Je m'attendais à ce que ça foire à cause de la réflection et de différences subtiles sur la nature des types, Je n'ai eu aucun effort spécifique à faire pour sérializer mes objets en XML dans un sens et l'autre, j'ai juste du mettre des valeurs par défaut aux arguments de mon constructeur principal pour être compatible javaBean. Ajouté une librairie java pour parser du HTML, aucun souci là non plus, je me sers directe de la lib sans ciment.

J'ai adoré me servir des extensions de la lib standard pour la classe File (ForeachLine, Writer)
https://kotlinlang.org/api/latest/jv...java.io.-file/

Je me sers peu des lambdas dans java8 sur les collections et les map, en quelques minutes de Kotlin j'en suis devenu accroc. Etant utilisateur d'Intellij ultimate, j'avais droit à un support IDE de pointe, la syntaxe sort naturellement, y'a ce petit "it" pour faire référence à l'objet concerné qu'on peut renommer si le souhaite en cas de nesting, tout cela coule tout seul, concis et lisible. Normalement je suis pas emballé par les déclarations "nomVariable : Type" mais ça pose en fait rarement problème tant j'use et abuse de l'inférence de type.

Bref, après ce premier contact, sentiment très positif. J'ai l'impression de faire du python avec le typage poussé (càd avec l'IDE qui comprend ce que vous retourne vos constructions et l'autocomplétion en conséquence) tout en pouvant profiter pleinement de l'écosystème de java. Pour moi c'était l'un des possibles juste milieu pour la JVM, un java amélioré avec 80% de ce que Scala offre de vraiment utile mais sans l'effort d'apprentissage.

Je ne saurais pas pondre une comparaison ceylon et kotlin, mais je trouve qu'ils vont tous les deux dans le bon sens et surtout les deux se relisent très très bien. Je n'aurai aucun souci à les utiliser pour un développement en équipe avec des développeurs de niveau inégal (alors que Scala je serais prudent à ce que je risque de devoir lire). C'est cependant dommage qu'effectivement, autant pour l'un que pour l'autre, il manque le super framework qui donne envie, comme play! pour Scala.
4  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 08/12/2017 à 15:40
Citation Envoyé par SurferIX Voir le message
Merci beaucoup pour toutes ces informations, très utiles. Cela confirme que rester dans des langages bétons comme C / C++ est plutôt pérenne...
En plus C# est vraiment un langage excellent.
Côté Web, même chose pour la rentabilité : rien n'arrive à la cheville de Django / Python.
De rien!

C#, oui, si on aime l'héritage C, la syntaxe, etc. (j'aime pas... rien à faire...), mais chapeau à MS. Et ils font le même coup avec TypeScript: reprendre un langage vieux (voire pourri) et en faire un truc nettoyé, propre, puissant, agréable, ... (ils avaient déjà fait ça avec DOS... devenu Windows 95, puis NT, ils savent faire...)
Je préfère la lignée Lisp et Smalltalk: resp. Elixir (voire Clojure) et Pharo.

Python/Django, vraiment le plus productif?
J'ai essayé l'an dernier...
Et puis devant faire des apps mobiles, rien à faire, on doit se taper swift/java, ou ES (React Native, ou NativeScript, ou Ionic 3 que je vais tester... Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).
A priori, le plus productif est Pharo, pas Python, Seaside, pas Django, et en plus y'a un smalltalk client JS: Amber, plus avancé que le Python transpilé en JS, Transcript par exemple (y'en a 3 au moins...):
https://medium.com/smalltalk-talk/a-...9ab#.pfbyjfuq5
https://medium.com/@richardeng/i-gue...t-2e166eff88bf
Elm et Clojure ont aussi un expérience de dev "wow"...

Mais je suis tout ouïe pour découvrir enfin du vrai dev productif! (fatigué de réinventer des roues... ), web et apps (webapps mobiles ou natives stp)? Grand merci!
ps: je cherche un CTO pour ma start-up, projet excitant, un bon, si intéressé... https://fr.linkedin.com/in/nicolashugodot/fr !
2  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 13/12/2017 à 9:59
Euh, ça parle plus beaucoup de Kotlin là

Citation Envoyé par nhugodot Voir le message

A part des bricolos qui ne sont pas des vrais hackers niveau ingénieurs, y'a plus personne de sérieux qui fasse du PHP... En France c'est Java, aux USA c'était Ruby, JS/ES/TS maintenant, et on passe aux langages fonctionnels svp, merci...!
C'est bien trop réducteur...

Je voulais pas trop intervenir dans le débat mais tu oublies que PHP est très présent dans le eCommerce, et c'est un secteur en très grande expansion où il a de l'argent et beaucoup à faire. En 10 ans que je suis dans une PME qui édite justement des solutions de pilotage de merchandising, on a vu défiler énormément de PHP, et sinon du .Net et du Java (ces 2 derniers sont souvent pour les gros comptes) mais par exemple dans ce secteur : quasi jamais de Python.

Et je dirai que les développeurs PHP de qualité, ça ne court pas les rues, peut être parce que c'est une techno très accessible, donc il y a largement la place pour sortir du lot, faire du travail sérieux et bien gagner sa vie. Pour les indices TIOBE et tout ça, tout a déjà été dit sur les topics dédiés à ces classements, on peut quasiment rien en tirer. Pour ça je suis d'accord avec dukoid que les offres d'emplois c'est "presque" un meilleur indicateur, resterait bien sûr à savoir maintenant si c'est des emplois d'esclaves sous payés qui doivent modifier un plugin wordpress ou des vrais postes où il y a de la valeur, mais c'est indéniablement un plus grand nombre d'opportunités.

Pour finir, si SurferIX juge qu'il est plus productif avec django qu'avec symfony parce que les templates se débuggent plus facilement, ben il a raison d'utiliser ça. Ca veut dire moins de travail pour lui et plus de satisfaction client, et c'est juste la seule chose qui compte. Je dirai la même chose d'un type qui pense l'inverse. A côté de ça, les graphiques de performance, le fait que ça fasse ou pas du mobile, du big data, ou du shell scripting, c'est complètement hors sujet.

Avant que quelqu'un se la ramène pour me dire que je défends PHP alors que c'est un langage de merde (et là dessus il y a beaucoup à redire), sachez que je n'ai jamais eu le loisir de choisir un langage selon mes propres critères d'appréciation, ça a toujours été selon l'écosystème, les libs/API disponibles ou les cibles de déploiement. Si vous pouvez vous permettre de vous limiter à un langage que vous adorez par dessus tout en fonction de vos seules opinions, je vous envie.
2  0 
Avatar de IsiTech
Membre actif https://www.developpez.com
Le 15/02/2016 à 23:18
Je test Kotlin pour du développement Android depuis peu et j'aime beaucoup. La syntaxe est particulièrement agréable, toutes les bibliothèques que j'utilise sur mes projets Android fonctionnent avec Kotlin et le langage est bien intégré à Android Studio.

Je pense que Kotlin a toutes les chances de se faire une place dans le développement Android, il reste à espérer que Jetbrains continue à supporter le langage et que Google s'y intéresse.
1  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 19/02/2016 à 22:16
Ayant étudié de prêt Ceylon, je suis curieux de regarder ce langage de plus prêt. Le problème c'est que ce n'est pas le seul sur la pile sans compter les frameworks, les bases de données, les sérialisations, les middlewares, etc. difficile de tout regarder dans le détail.

En parlant de Ceylon, il va plus loin dans la sûreté en l'appliquant également dans la conversion (cast), ainsi il n'y a pas de ClassCastException non plus. Est-ce que Kotlin fait de même ?

Autre point, y a-t-il un projet porteur pour ce langage comme Play!/Akka pour Scala, Gradle/Grails pour Groovy ? Je pense que c'est ce qui fait cruellement défaut à Ceylon pour réellement décollé. Même si un gros travail a été fait pour proposer une API Vert.x pour Ceylon.
1  0 
Avatar de UnFroMage
Futur Membre du Club https://www.developpez.com
Le 25/02/2016 à 11:29
Citation Envoyé par _skip Voir le message
Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même.
Je ne veux pas faire de la promo pour Ceylon dans une discussion sur Kotlin, ça serait mal venu. Par contre je voulais juste répondre à ça pour dire que en Ceylon si vous compilez pour la JVM, vous pouvez utiliser les tableaux de la JVM (`int[]` -> `java.lang.IntArray` en Ceylon par exemple) qui ne feront donc pas de boxing.
1  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 12/12/2017 à 14:54
Citation Envoyé par nhugodot Voir le message
Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).
Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.
1  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 12/12/2017 à 15:51
Citation Envoyé par _skip Voir le message
Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.
Merci Skip, commentaire autrement plus intéressant que l'humanoïde dissocié et son PHP...

Oui, TS est génial car garde toute la compatibilité avec l'existant: codes JS, codeurs JS et C++/Java/C#... , .. Google a été très pragmatique sur ce coup là, en faisant une évolution et pas une révolution. Et on peut utiliser TS avec Angular (donc Ionic et NativeScript) mais AUSSI avec React et VueJS etc.

Kotlin tournant sur VM JS et Java, je me demande quelle killer stratégie on peut bien y trouver pour faire quelque chose de génial que Java ou JS ne saurait pas faire... : tourner sur backend java et sur front end (JS, forcément... tant que WebAssembly n'est pas partout), profiter des deux écosystèmes et richesses de librairies?
1  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 12/12/2017 à 16:32
  • Symfony est d'origine française, pas Django. "NIH"? (syndrome Not Invented Here?)
  • Et personne n'a parlé de chercher du travail avec Django. Entre un poste de CEO et un job de plombier, y'a aussi plus d'offres d'emploi pour plombier...
  • 1er résultat de ma recherche "Symfony vs Django": boum, enfoncé Symfony...


Rapidité? ah ben flûte: http://blog.websitesframeworks.com/w...03/davis11.png
Ah ben vraiment flûte même: perdre 3% de clients et être lent à ce point...: http://static.alrond.com/siege.gif

La messe est dite: quand on fait sa pub sur PHP, on sait à qui on a affaire... (pas un ingénieur... un vrai)
1  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 12/12/2017 à 17:03
Salut SurferIX et merci pour ton appréciation... je ne suis plus codeur mais me passionne néanmoins pour les belles choses, simples et efficaces, les architectures, et déçu par le "reinvent the wheel" pour la 100000 fois pour faire un bouton ou un bout de chat dans une app, cherche constamment "quel est le plus productif des outils de dev.. désespérant, quand même... on revient à ... Smalltalk. Tout ça pour ça.

Tout est là: https://medium.com/@richardeng , le mossieur est encore plus désillusionné que moi mais encore plus compétent néanmoins. Pharo, bébé d'un directeur de recherche de l'INRIA de Lille, est le futur, le SmallTalk du 21e siècle. Quelques trucs top dedans: tout est dans un seul fichier, même l'état, rechargeable après un reboot donc on retrouve l'endroit ou on était (une app iOS ou Android me fait pleurer: en pause hop elle dégage et en rallumant son phone... faut tout recharger... ). Syntaxe hyper claire, une autre façon de travailler. Etc.

Mais Pharo ne fait pas Android et iOS, Dart/Flutter si et est le futur de Android: FuschiaOS:
et surtout https://hackernoon.com/why-native-ap...r-e97361a1c073
Dart>TS>ES>JS... J'ai pas encore trouvé mieux, je vais sans doute m'y mettre... Comme Pharo, le fait qu'on se passe parfaitement d'outil à la Gulp Grunt et autres acronymes vulgaires veut tout simplement dire que c'est propre, dès le départ. Le bazar JS React etc. c'est du bricolage, de génie mais du bricolage. "AMHA"...

(Ah, Elm, aussi, mais non pas OO mais fonctionnel, est à essayer absolument aussi; idem, pas besoin de pléthore d'outils compliqués, expérience de dev géniale. Clojure aussi avec son IDE interactif "REPL" que les amateurs louent aux nues... Go est un C++ facile aussi. Tout est là, je compile mes lectures ici: https://docs.google.com/document/d/1...h.te2c3nnwu1w7
à toi d'y participer!
1  0