Le topic de la programmation: Et envoyez des sioux!

[Thamior]

Déjà il me semble que le constructeur c'est MaClasse et non MaClasse<T>, je suis étonné que ça marche.

PS: Et aussi std::is_same<const MaClasse<T>&, Args...>, ça doit pas marcher quand le nombre de Args... est différent de 1.

Merci, que de très bonnes remarques, ça marchotte dans mes tests unitaires mais en effet quand le nombre de Args... est différent de 1 ça s'arrête de marcher. Le MaClasse<T> c'est juste moi qui n'ai pas réfléchi en recopiant.

Une version qui je pense fait ce que je veux est donc plutôt :

class MaClasse
{
public:
    template<typename... Args>
    std::enable_if_t<
      ((!std::is_same<const ReferenceCounted<Pointed>&, Args>::value && ...) &&
      (!std::is_same<ReferenceCounted<Pointed>&, Args>::value && ...) &&
      (!std::is_same<ReferenceCounted<Pointed>&&, Args>::value && ...))
      , bool
    > = true
  >
  MaClasse(Args &&... args);
};

Ca fonctionne même avec 0 paramètres, ce qui est top vu que MaClasse je m'en sers comme smart pointer. C'est aussi pour ça qu'ajouter un paramètre "dummy" je n'aime pas trop car ça casse un peu le truc. Après j'imagine que c'est peut-être pour ça qu'on a std::make_shared() et std::make_unique()...

[Cwningen]

Je pense que tu as un problème si tu passes plusieurs paramètres dont au moins un est une référence. Si tu tiens à aller dans cette direction, utilise un type_traits custom dans le genre :

template <typename T, typename... Args>
struct is_copy_or_move_constructor_args: std::false_type {};
template <typename T>
struct is_copy_or_move_constructor_args<T, const T &>: std::true_type {};
template <typename T>
struct is_copy_or_move_constructor_args<T, T &>: std::true_type {};
template <typename T>
struct is_copy_or_move_constructor_args<T, T &&>: std::true_type {};

Ces types de références ne sont pas suffisant, dans cet article, l'auteur prend on compte le cas où on passe un objet de type dérivé au constructeur de copy dans la classe de base. Il faudrait peut-être aller jusqu'à considérer tout ce qui est convertible en référence ?

C'est très compliqué, je préfère contourner le problème avec des fonctions libres/méthodes statiques make_truc, ou des constructeurs à tags (qui peuvent être utilisés en interne par les fonctions make_truc, si tu les trouves moches).

Edit: J'ai retrouvé l'exemple dans le livre de Scott Meyers, c'est is_base_of + decay.

class Person {
public:
  template<
    typename T,
    typename = std::enabled_if_t<
      !std::is_base_of<Person, std::decay_t<T>>::value
      &&
      !std::is_integral<std::remove_reference_t<T>>::value
    >
  >
  explicit Person(T&& n)        // ctor for std::strings and
  : name(std::forward<T>(n))    // args convertible to
  { … }                         // std::strings

  explicit Person(int idx)      // ctor for integral args
  : name(nameFromIdx(idx))
  { … }

  …                             // copy and move ctors, etc.

private:
  std::striing name;
};

[Thamior]

Merci pour l'article ! Je pense que pour le moment, je vais rester sur l'exemple de Scott Meyers qui a quand même l'air d'être le plus concis (pour du template...), et si jamais j'ai des soucis je passerai sur une fonction statique à la "make_shared()".

[Anonyme20240202]

Bon je viens de démarrer sur un projet qui utilise du Ruby (+ Rails) et Go (golang), avec du C++.

Franchement pas très impressionné de ce que je vois du côté de Ruby. Genre je comprends l'idée de "c'est facile de faire des prototypes", y'a pas mal de trucs pré-machés, mais vu qu'il faut aussi prendre le temps d'apprendre les conventions du language (qui franchement sont déstabilisantes parfois, genre le délire de parser le suffixe d'un nom de fichier pour faire un truc derrière)... Au final j'irai plus vite à installer la lib C++ qu'il me faut et basta.
Aussi direct on voit les écueils classiques, y'a une bonne partie des tests du projet qui seraient résolus directement si y'avait du typage fort.

'Fin bref curieux d'avoir les avis des canards qui sont sur du Ruby, mais ça me vend pas le truc. Puis la communauté n'a pas l'air super active, m'enfin, j'apprendrai de quoi faire les 2-3 trucs dont j'ai besoin.

Sinon Go ça va, franchement rien d'extraordinaire, p'têt qu'à l'époque l'idée de faire un langage en réaction à l'état du C++ tel qu'il était avait du sens. Mais aujourd'hui avec le C++ moderne y'a pas vraiment un moment où je me dis "ah, pratique le Go, ça aurait été chiant en C++".
L'avantage du Go pour l'instant c'est la gestion des dépendances, là y'a pas trop à chier, C++ devrait s'en inspirer niveau simplicité. Et puis la cross compilation est super facile aussi en Go.

Là encore si y'a des canards qui ont des pro-tips en go, je prends.

Et je suis resté sur les IDE de jetbrains pour les 2, on change pas une équipe qui gagne

[MrBeaner]

Go c'est mon langage à apprendre cette année J'hésitais avec C++, mais je suis plus hypé par ça.

J'ai pas de besoin particulier actuellement, mais je voulais apprendre un truc moderne si jamais j'ai envie de plus de perfs que Python ou JS.

[gros_bidule]

Go j'ai vraiment du mal avec la syntaxe. J'ai l'impression que ses créateurs font parti des gens qui se disent qu'un nouveau langage doit forcément se démarquer de par sa syntaxe :
- un tableau de strings ? Par ex en Java on déclare "String[]", c'est établit, tout le monde connaît. Bah en Go : "[]string"
- en python on a les fonctions "fun" : bah écrivons "func", parce que
- une affectation : plutôt que "=", faisons ":="
- rhoo et puis si je me fiche du retour d'une fonction, je dois faire "_ = mafonction()" (sur ce point on peut peut être faire mieux ? je ne suis pas expert non plus)
- la librairie standard n'est pas très fournie pour ce qui concerne la gestion des listes/tableaux, j'ai miséré...
- en Pyhon la gestion des listes, tableaux, maps et même du Json c'est super méga simple. Pourquoi ne pas avoir repris cette super idée ?
Pourquoi ne pas reconnaître que les précédents langages ont de bonnes idées, et essayer d'en faire un mix plutôt que forcément chercher à tout changer ? C'est comme la gueguerre des OS avec LF vs CR vs CRLF, ou / vs \, j'ai l'impression qu'on en est encore là.
Quand dans une même semaine tu fais du Java, Kotlin, Python, et Go, la gymnastique intellectuelle devient un calvaire. C'est comme ça que tu laisses tomber des langages.

C'est dommage car en effet la cross-compilation est cool, et installer un environnement de dev se fait en quelques clics. Pas besoin d'installer et configurer plein de trucs : installeur du SDK, clics sur Enter, voilà tu peux faire du Go. Et ça marche.
Sous Windows y'a juste certains antivirus (comme Node32) qui n'aiment pas que les exe soient générés et exécutés depuis %TMP% lorsque tu dev, c'est effectivement moche, mais les AV se configurent. Peut être Go aussi, je n'ai pas creusé plus loin.

Ruby ce n'est pas comme Perl, Groovy ou Scala ? C'est vieuuuuuux et laid, plus personne n'en veux. Je ne sais pas si vous le ressentez comme moi, mais un langage doit voir un bon écosystème, mais ledit langage doit aussi être agréable à utiliser.

[Teocali]

Perso, là, c'est Dart dans lequel je vais me plonger. On a récupérer le code d'une application mobile developpé en Flutter pour la maintenir, et je dois avouer que mes premiers contact le code m'ont un peu déstabilisé mais rien de rédhibitoire. on verra ce que ça donne au fil du temps

[Anonyme20240202]

Ah oui le truc parfois pénible avec Go c'est quand tu veux chercher un truc sur google, vu que "Go" c'est trop petit la moitié du temps je tombe sur des réponses pour un autre langage haha.
Je m'en sors avec du "golang" ou autre dans la recherche, rien de bien grave.

Mais je sais que pour C ou C++ google a fait en sorte que ça fonctionne bien (genre j'avais lu un article qui expliquait comment le moteur de recherche gérait des termes aussi petit et était capable de comprendre c++ = cpp), marrant qu'ils n'aient pas l'air d'avoir implémenté ça pour Go (qui est le langage "de chez google")

[Helix]

Go j'ai vraiment du mal avec la syntaxe. J'ai l'impression que ses créateurs font parti des gens qui se disent qu'un nouveau langage doit forcément se démarquer de par sa syntaxe :
- une affectation : plutôt que "=", faisons ":=".

Juste sur ce point, la syntaxe mainstream n'est pas toujours bien claire. Par exemple il est souvent plus naturel à mes étudiants débutants (iut Ge2i) d'utiliser '=' pour le test. L'idée de garder ce '=' pour le test et d'avoir un ':=' pour l'affectation (ce que faisait Pascal) me semble une très bonne chose.

Ah mince, en écrivant je vérifie et Go utilise '==' pour le test. Il a deux opérateurs d'affectation, '=' et ':=' qui implique une déclaration. C'est bof ça.

[GrandFather]

Ruby est, parmi tous les langages que j'ai utilisés ou seulement étudiés, celui avec une implémentation de l'objet parmi les mieux foutues et les plus limpides sur le plan théorique. Sans bidouille du type autoboxing (Java) et à des années-lumières de l'implémentation foutraque des objets dans Python. Pour le reste, le langage a été conçu dans une optique de « moindre surprise », et pour l'avoir utilisé dans un cadre professionnel je trouve que ce contrat a été rempli. Les choix de nommage et de syntaxe qui ont été faits l'ont été pour faciliter l'apprentissage du langage et le rapprocher du langage naturel. Pour tout dire, si mon contexte de travail le permettait, je ne travaillerais qu'en Ruby.

Ruby est quand même le langage dans lequel a été conçu le framework web MVC Rails, qui a servi de référence à tous les frameworks MVC modernes dominants comme Symfony, par exemple. Et si vous voulez coder un DSL (Domain Specific Language), vous ne trouverez pas un meilleur langage pour le faire.

[acdctabs]

Moi = pour l'affectation et == ou === pour la profondeur du test
(égalité simple, égalité + type) je trouve ça parfait.

Après je dois avouer j'aime bien le php.

[Cwningen]

Moi = pour l'affectation et == ou === pour la profondeur du test
(égalité simple, égalité + type) je trouve ça parfait.

Donc, si === c'est la version plus "profonde" de ==, ça veut dire que = est la version plus "superficielle" de ==. C'est bien ça ?

[Shurin]

Perso, là, c'est Dart dans lequel je vais me plonger. On a récupérer le code d'une application mobile developpé en Flutter pour la maintenir, et je dois avouer que mes premiers contact le code m'ont un peu déstabilisé mais rien de rédhibitoire. on verra ce que ça donne au fil du temps

Tu va kiffer je pense.
Le duo Flutter/Dart est vraiment cool, hésites pas à poser des questions d'ailleurs, je suis beaucoup dessus depuis 2ans.

[acdctabs]

Après un test d'égalité et une affectation ça s'utilise pas au même endroit, enfin je ne vois pas trop où ça pourrait.
Bon je code peut être trop à l'ancienne...

[Cwningen]

En C, c'est courant. Surtout avec les appels systèmes posix :

if ((fd = open("fichier", O_RDWR)) == -1)

Mais aussi quand tu as une valeur que tu peux directement tester comme un booléen (par exemple un pointeur) :

if ((ptr = get_pointer(...)))

Au point, qu'il y a une convention pour éviter les avertissements du compilateur.

[Orhin]

C'est très moche le C.

[Cwningen]

Et pourtant plein de langages ont repris sa syntaxe. Mais pour l'affectation avec un simple =, il semble que ce soit Fortran le coupable.

[Orhin]

Je ne parlais pas de la syntaxe, mais de faire une assignation en même temps qu'un test.

[William Vaurien]

C'est l'absence de gestion standard des erreurs qui rend moche le C. Quasiment toutes les fonctions de la lib standard n'utilisent la valeur de retour que pour remonter un code d'erreur. En plus souvent c'est 0 -> pas d'erreur, comme en shell et donc ça ne se comporte pas comme un booléen et ça donne des trucs encore plus moche et pas facile à lire pour un dev non habitué. Sans compter que des fois le comportement change un peu dans une lib donné: des fois c'est une variable globale qui est utilisé pour stocker le dernier code d'erreur éventuel.

Cette absence de gestion d'erreur par exception (couplé aussi avec l'absence de String standard) rend le C vraiment désuet et assez insuportable pour un gros projet quand on est habitué à d'autres idiomes.

Un de mes collègues qui ne fait que du C et à arrété de faire de la 'veille technologique' vers 2000 (il fait du html avec des balises en majuscule ) et il est toujours surpris par les langages plus modernes comme Java (pour lui c'est très moderne Java...). Il à beaucoup de mal avec les try/catch, ou encore à utiliser le retour de la fonction pour retourner le résultat d'une opération non mathématique. Il a tendance à plutôt vouloir modifier un paramètre que de retourner un résultat.

Perso je suis habitué à la syntaxe C dans sa variante Java et j'ai du mal avec les langages comme Kotlin ou Scala qui changent par example l'ordre de déclaration entre type et nom de paramètre.
Après c'est comme un changement de layout de clavier: c'est chiant parceque ça devient 'cablé en dur' dans le cerveau et que le changement génére une frustration car on fait la même erreur tout le temps et que ça ralenti, mais on fini par s'habituer si on utilise assez longtemps...

Pour Ruby j'ai l'impression que ce langage, qui devait tuer Java un peu avant 2010, est quand même un peu en train de crever, ou au moins de stagner...
J'avais fait qqs scripts avec et je l'avais trouvé sympa (plus que Python qui termine systématiquement en code bordélique pour moi; je ne comprend pas pourquoi ni comment Python a pu devenir si populaire...)
Là je n'en entends quasi plus jamais parler.

[Teocali]

Perso je suis habitué à la syntaxe C dans sa variante Java et j'ai du mal avec les langages comme Kotlin ou Scala qui change par example l'ordre de déclaration entre type et nom de paramètre.

Pour Kotlin, l'inversion s'explique par la volonté de donner beaucoup de capacité au compilateur, et entre celle de l'inférence de type. Si tu gardais le type avant, ça serait compliqué de le supprimer dans le cas d'un typage implicite.

Exemple :

//Typage explicite en Kotlin
val variable:String = methodeQuiRetourneUneString()

//Typage implicite en Kotlin
val variable = methodeQuiRetourneUneString()

// Typage explicite en java
String variable = methodeQuiRetourneUneString()

//Typage implicite en java
variable = methodeQuiRetourneUneString() //ERROR : c'est quoi ? Une déclaration ou une affectation ?

Je sais que Java a introduit le mot clé val, mais il faut avouer que la manière de Kotlin donne une meilleur cohérence au langage. Perso, je suis très heureux de coder en kotlin full time et les quelques fois ou j'ai du retourner sous Java, j'ai eu du mal.

Bon après, il est vrai que Kotlin est destiné à être utilisé au sein d'un IDE moderne. Lire le code d'une application Kotlin au sein d'un simple editeur de texte, même avec la coloration syntaxique, tu tousses.

Mais bon, y'a que quelque cas bien spéciaux qui continue a coder sans IDE

[Orhin]

Après cette inversion n'est pas spécifique à Kotlin, on la trouve dans la majorité des langages "récents" (Swift, Typescript, Rust ou Go par exemple).
Langages qui ont généralement de l'inférence de type (comme le souligne Teocali pour Kotlin).

[deathdigger]

Je viens de mettre à jour mon visual studio community vers la version 2022 et putain cette auto-complétion
Genre, un truc tout bête quand t'as un tableau de strings :

[Shinosha]

Ruby ce n'est pas comme Perl, Groovy ou Scala ? C'est vieuuuuuux et laid, plus personne n'en veux. Je ne sais pas si vous le ressentez comme moi, mais un langage doit voir un bon écosystème, mais ledit langage doit aussi être agréable à utiliser.

Première fois que je me sens obligé de parler sur ce topic, mais je ne peux pas laisser passer ça Ok le langage est pas opinionated, mais Scala (notamment la version 3) met à l'amende tous les autres langages de la JVM. Si je devais commencer un nouveau projet backend entreprise aujourd'hui et si j'avais un peu de latitude dans le process de formation et du recrutement, je choisirai forcément Scala. Quant à Ruby oui il est clairement en train de crever

[Nattefrost]

Du perl j'en vois encore un peu chez les vieux sysadmins (pour du cron par ex quand sh/bash est trop limité). Ruby a été partiellement remplacé par du Golang dans les outils/services de devops/infra ( les 'nouveaux' projects Hashicorp par ex).
Du coté dev pur genre web ou client lourd je sais pas je m'en suis éloigné depuis longtemps mais je veux bien croire que ç'ait été supplanté par d'autres langages plus modernes

[TwinBis]

Scala est au mieux stagnant, au pire moribond.
Probablament en partie à cause de Kotlin, qui remplit une niche proche (sans être tout à fait identique).

Après ça ne retire rien aux mérites propres du langage.
Mais encore faut-il trouver des devs pour bosser avec, et avoir un écosystème vivant autour, ce qui me semble être problématique avec Scala ces derniers mois/années.

[Orhin]

Kotlin a le gros avantage d'être poussé par Google pour le dev Android.
Ça donne une base très importante de développeurs utilisant le langage au quotidien.

Du coup forcément ça a tendance à "déborder" sur le reste de l'environnement Java.

[Shinosha]

Scala est au mieux stagnant, au pire moribond.
Probablament en partie à cause de Kotlin, qui remplit une niche proche (sans être tout à fait identique).

Après ça ne retire rien aux mérites propres du langage.
Mais encore faut-il trouver des devs pour bosser avec, et avoir un écosystème vivant autour, ce qui me semble être problématique avec Scala ces derniers mois/années.

En terme d'adoption oui c'est probable, et je trouve ça fort dommage. Son gros problème niveau adoption c'était surtout les breaking changes entre chaque version à mon sens (ce qui était surtout un problème pour Spark, et donc tout le monde, soyons honnêtes). Pour le coup Scala 3, en plus d'améliorer le langage substantiellement, est censé être maintenant rétrocompatible sur les versions mineures.
Concernant l'écosystème, il est toujours très vivant. On y trouve beaucoup de libs très cools. On peut citer par exemple ZIO qui vise à rendre la programmation fonctionnelle accessible aux devs OOP, ou Tapir qui te permet te décrire des endpoints HTTP pour ensuite te générer un client ou serveur associé avec la doc Swagger qui va bien. Le tout en restant le plus typesafe possible bien sûr.

Pas sûr que Kotlin vampirise tant que ça par contre. Initialement conçu et vendu comme un meilleur Java alors que Scala c'est juste pas pareil. D'ailleurs je me demande ce qu'il va advenir de Kotlin quand Java aura rattrapé un peu son retard. Et vu son nouveau rythme de release... Contrairement à Scala par contre ils ont été assez intelligents pour se faire soutenir par Android et Spring.

[gros_bidule]

Une des forces de Kotlin, c'est de proposer des releases fréquentes tout en restant compatible avec du vieux bytecode.
Tu as les bénéfices de Kotlin récent tout en ciblant du bytecode java8 ou java11 (et java6 pendant un temps). Java se remet à évoluer rapidement (enfin... ça reste un peu lent hein, je parle des LTS), mais en entreprise on commence tout juste à penser à migrer des bases de code Java 8 vers Java 11. Alors Java 17 (toutes les 3 des LTS. En milieu pro on évite évidemment les non-LTS)...
Du coup on fait du Kotlin, comme ça on a pas le stress de devoir mettre à jour le JDK pour l'attrait des nouvelles fonctionnalités, vu que c'est décorrélé now.

Puis c'est super bien pris en charge par les IDE, les linters, etc. Avoir un env de dev sexy ça compte.

Rhoo et le compilateur était déjà rapide à la base, et il s'améliore encore. Côté Scala on ne peut pas en dire autant je crois ? (je suis resté sur Scala 2 cela dit, pour faire du Gatling uniquement). De mémoire, le compilo Scala est suuuuuuuper lent. Ses devs ont même eu l'audace de titrer un jour "rholala c'est trop cool Scala rendez-vous compte, on a amélioré les perfs du compilo de 50%". Sauf que 50% de super méga lent ça fait super lent, le compilo part de très très loin.

Les écosystèmes de Java Kotlin et Scala, ça serait dommage d'essayer de les comparer vu que tout ça c'est grosso-modo un seul écosystème, celui des langages de la JVM. "Akka" par ex, un "grand" projet Scala tel qu'on le présentait à l'époque, bah tu peux l'utiliser en Java...
Les libs faites en Scala, la plupart existent aussi en Java / Kotlin de toutes façons. Les "bons" trucs de Scala ou des libs Scala ont tous (sinon 99%) été repompés pour en faire de très bonnes libs Java ou Kotlin, et améliorer ces langages. Scala n'a plus autant d'avance sur les autres langages JVM, c'est finit ça.
Je pense sincèrement que Scala mérite les honneurs, il a introduit de très belles nouveautés. Mais c'est un vieux soldat, sa place est dans la maison de retraite des vieux langages.

---

L'avenir de Kotlin aussi, et là c'est un pari (et c'est porté par des devs assez renommés), c'est d'en faire un des grands langages du frontend. Tu peux déjà générer du JS, ça marche super, mais le futur c'est de faire du webassembly. Ca plus des framework front basés sur Kotlin, si ça prend, ça serait une tuerie. Tu aurais un seul langage pour le backend et le frontend. Ca serait tellement mieux que cette horreur de NodeJS.

[Shinosha]

Rhoo et le compilateur était déjà rapide à la base, et il s'améliore encore. Côté Scala on ne peut pas en dire autant je crois ? (je suis resté sur Scala 2 cela dit, pour faire du Gatling uniquement). De mémoire, le compilo Scala est suuuuuuuper lent. Ses devs ont même eu l'audace de titrer un jour "rholala c'est trop cool Scala rendez-vous compte, on a amélioré les perfs du compilo de 50%". Sauf que 50% de super méga lent ça fait super lent, le compilo part de très très loin.

C'est sûr que quand ton compiler fait rien c'est rapide Évidemment c'est mieux qu'avant mais franchement je trouve ce point un peu surfait. Il y a plusieurs choses à considérer avant de déclarer ça comme un problème bloquant... Est-ce gênant pour le feedback développeur ? Pas vraiment, normalement t'as un IDE qui t'aides et surtout la compilation incrémentale. C'est long de build sur la CI ? Peut-être mais est-ce que c'est grave que ça dure 5 mins de plus alors qu'en échange t'as un type system qui t'offre vachement plus de possibilités et de sécurité. Moi j'pense la question, elle est vite répondue.

Les écosystèmes de Java Kotlin et Scala, ça serait dommage d'essayer de les comparer vu que tout ça c'est grosso-modo un seul écosystème, celui des langages de la JVM. "Akka" par ex, un "grand" projet Scala tel qu'on le présentait à l'époque, bah tu peux l'utiliser en Java, Kotlin, Groovy...
Les libs faites en Scala, la plupart existent aussi en Java / Kotlin de toutes façons. Les "bons" trucs de Scala ou des libs Scala ont tous (sinon 99%) été repompés pour en faire de très bonnes libs Java ou Kotlin, et améliorer ce langages. Scala n'a plus d'avance sur les autres langages JVM, c'est finit ça.

Niveau fonctionnalités si, Scala 3 a toujours de l'avance, et pas qu'un peu. Par exemple les opaque types, un pattern matching complet, dependent function type, les typeclasses, higher-kinded type et beaucoup d'autres choses. Ces manquements se traduisent bien sûr niveau écosystème.
En effet même si certaines libs fournissent une API Java ou autre, c'est souvent avec une ergonomie inférieure ou avec des implems spécifiques (dédicace à Lombok ou Vavr). Là tu as pris un exemple qui t'arranges avec Akka (qui aurait peut-être pu être implémenté en Java), mais si je te parle des substituts aux for-comprehensions ou aux HKT dans Arrow-kt par exemple, c'est tout de suite moins joli. Pensons aussi aux maintainers derrière, toi tu peux potentiellement avoir une belle API mais par contre en coulisses c'est moins reluisant.

Je pense sincèrement que Scala mérite les honneurs, il a introduit de très belles nouveautés. Mais c'est un vieux soldat, sa place est dans la maison de retraite des vieux langages.

L'avenir de Kotlin aussi, et là c'est un pari (et c'est porté par des devs assez renommés), c'est d'en faire un des grands langages du frontend. Tu peux déjà générer du JS, ça marche super, mais le futur c'est de faire du webassembly. Ca plus des framework front basés sur Kotlin, si ça prend, ça serait une tuerie. Tu aurais un seul langage pour le backend et le frontend. Ca serait tellement mieux que cette horreur de NodeJS.

Scala.js suit le sujet aussi

[Orhin]

L'avenir de Kotlin aussi, et là c'est un pari (et c'est porté par des devs assez renommés), c'est d'en faire un des grands langages du frontend. Tu peux déjà générer du JS, ça marche super, mais le futur c'est de faire du webassembly. Ca plus des framework front basés sur Kotlin, si ça prend, ça serait une tuerie. Tu aurais un seul langage pour le backend et le frontend. Ca serait tellement mieux que cette horreur de NodeJS.

Ouais alors ça je parierais pas dessus (ou en tout cas pas avant 5 ans minimum).
Les gros framework JS (React/Angular/Vue) sont vraiment bien implantés et l'environnement TS/ESnext est très dynamique.

Contrairement à Scala par contre ils ont été assez intelligents pour se faire soutenir par Android et Spring.

Ben c'est un peu le cœur du sujet.
Les qualités intrinsèques d'un langage c'est bien, mais l'environnement tout autour (framework, IDE, plateforme de dev, etc) est encore plus important.

D'ailleurs je me demande ce qu'il va advenir de Kotlin quand Java aura rattrapé un peu son retard. Et vu son nouveau rythme de release...

Alors déjà Y'a encore du boulot à ce niveau.
Au delà des fonctionnalités, la syntaxe Java donne quand même moins envie que celles de langages "modernes".

Mais surtout, ça va être une question de dynamique.
Aujourd'hui passer de Java à Kotlin a du sens car ce dernier est objectivement mieux.
Si demain Java ne fait que rattraper son retard, quel serait l'intérêt pour les dev Kotlin de repasser sur du Java ?

Le seul argument pour moi serait une forme d'inertie, si les grosses organisations sont encore sur du Java, alors il y aura une pression pour uniformiser.
Mais ça ne sera le cas que si Java rattrape son retard avant que Kotlin soit devenu majoritaire.

C'est sûr que quand ton compiler fait rien c'est rapide Évidemment c'est mieux qu'avant mais franchement je trouve ce point un peu surfait. Il y a plusieurs choses à considérer avant de déclarer ça comme un problème bloquant... Est-ce gênant pour le feedback développeur ? Pas vraiment, normalement t'as un IDE qui t'aides et surtout la compilation incrémentale.

Ben ça dépend ce que tu fais.
Quand tu bosses sur de l'UI, avoir une compilation quasi instantanée est vraiment appréciable.