Je comprendrai jamais l'intérêt que porte les gens sur Java. Ce langage principalement utilisé en école et en entreprise promeut tant de choses qu'on dit « bonnes » juste par principe mais finalement n'apporte rien :
Abus de l'héritage. Les langages récents comme Rust et Go démontrent que l'on peut faire des projets sans orienté objet. Ce paradigme est probablement voué à disparaitre à terme, il n'apporte que peu de solutions.
Abus des getters/setters. Les projets en Java sont ceux qui ont définitivement le plus de boilerplate juste parce « qu'il ne faut pas modifier une variable directement, saypabien ».
Lenteur excessive. Les langages interpretés c'était bien avant (#boomer). On a des boites à outils pour faire du natif sans se casser la tête (merci LLVM). “Java, write once, run away”.
Verbosité inutile. Il y a tellement d'abus des exceptions que tu te retrouves à écrire des horreur comme private RS232 connect() throws NoSuchPortException, PortInUseException, UnsupportedCommOperationException, IOException, TooManyListenersException, Exception {
Overengineering à outrance. Pour faire une chose simple en Java il faut instancier une factory qui crée une interface qui crée des objets.
git is great because linus did it, mercurial is better because he didn't
Je pense que ta vision de Java doit dater des années 90.
Accessoirement, la majorité de tes points ne sont pas liés au langage lui-même mais à ce que certaines personnes en font.
Lenteur excessive. Les langages interpretés c'était bien avant
Celle-là m'a bien fait rire.
Bref, on ne te fera pas changer d'avis mais, des fois, c'est pas mal de se poser la question de pourquoi tant de gens aiment quelque chose quand on a des idées préconçues comme ça.
Lenteur excessive. Les langages interpretés c'était bien avant
Celle-là m'a bien fait rire.
Je ne parle pas sans connaissance de cause, je maintien des applications en Java à mon travail et je t'assure que j'ai envie de trucider l'ancien développeur qui s'est dit que ça allait être une bonne idée de faire du Java sur de la Raspberry et de la BeagleBone.
Le simple démarrage de l'application met déjà plus de 3 secondes avant même d'arriver dans nos premières fonctions. L'application en elle même n'est pas spécialement compliquée, mais tout est lent. Dire que Java est performant est de la pure mauvaise foi ;)
J'ai fait du Java pendant plusieurs années, je ne parle pas dans le vent. Je m'intéresse à beaucoup de langages et c'est clairement celui dont je ne comprends toujours et encore pas l'intérêt. Comme c'est sujet à débat, je t'invite à me dire ce qui te plait dans ce langage et serait fortement ravi de savoir de quoi il s'agit.
git is great because linus did it, mercurial is better because he didn't
Java sur un rpi, si tu cherches la petit bête aussi…
Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)
Un peu plus sérieusement, chez nous ce sont les containers java qui prennent a peu près une minute pour être fonctionnels quand des applications plus élaborées en python sont dispo quasiment instantanément. Ce sont les même développeurs (java à la base) qui ont fait les deux codes. Et je ne parle pas de la consommation de mémoire …
Sur certains points, c'est pas encore ça.
Par contre, point de vue vitesse d’exécution y'a pas photo, java a une longueur d'avance.
Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)
L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?
L'argument est douteux, si tu configure proprement ta JVM, et optimise correctement ton appli, Java va très bien tourner même sur un grille pain.
L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?
Ça n'a jamais voulu dire que ça doit s'exécuter partout avec la même performance. Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios. Et il ne s'exécute plus sur navigateur non plus.
Ça doit être pour ça que le slogan est mort avec son créateur : sun microsystems. C'est un peu comme utiliser le premier non de c++ pour en parler "c with classes".
Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios.
Sur risc-v et ios, je ne sais pas, mais sur M1, non, on n’est pas obligé de passer par l’émulation x86_64 (même si c’est possible). Il y a des JVM ciblant directement l’architecture arm.
Et c’est heureux, parce que pour avoir testé les deux (JVM x86_64 sous émulation vs JVM arm64 native), les performances de la version native sont bien meilleures, malgré tout ce que peut dire Apple sur la qualité de son émulation x86_64 qui soi-disant autoriserait à utiliser des programmes x86_64 sur M1 sans qu’on ne puisse jamais voir la différence…
Sauf que tu parles d'anecdotes, de plus sur des systèmes ultra spécifiques. Il y a beaucoup de gens qui utilisent Java et sont très contents des performances.
Pour des applications serveurs, le compilateur JIT de Java est assez redoutable.
Si tu veux faire des applications type CLI, tu as GraalVM de nos jours (qui fait de la compilation AOT, ce qui dans certains cas sera moins performant que de la compilation JIT car le JIT peut optimiser des choses basées sur les motifs d'exécution).
Pour prendre un exemple, mon bot GitHub en Quarkus pour le projet Quarkus (dont je compte parler un de ces jours sur ce site) démarre en 20ms compilé en natif avec GraalVM.
Et l'implémentation d'une action simple avec le framework Quarkus GitHub App que j'ai développé pour ça est en tout et pour tout :
classMyGitHubApp{voidonOpen(@Issue.OpenedGHEventPayload.IssueissuePayload)throwsIOException{issuePayload.getIssue().comment("Hello from MyGitHubApp");}}
C'est à dire qu'avec juste cela, tu auras un bot GitHub qui répond aux requêtes et ajoute un commentaire pour tout nouvel issue GitHub créé. Rien besoin d'autre mis à part un fichier de configuration pour les clés de signature. Et l'IOException est là juste à cause de l'API Java GitHub qui devrait virer cette exception dans la prochaine version majeure.
Le fait qu'on puisse mal bosser en Java ne dit rien sur le langage. Tu peux mal bosser dans tous les langages.
Bon et puis parfois, ce n'est juste pas le bon langage pour la tâche. Et c'est pas bien grave, utilise autre chose dans ce cas.
Et pourtant via Java sur Android on a des centaines de milliers d'applications rapides et performantes sur des plateformes embarquées.
Dans la même veine, quand on paie sans contact avec notre carte bancaire, tu as un système d'exploitation qui démarre, initialise une JVM, et fait tourner du Java(card), le tout en 1 ou 2 secondes, le temps du bip.
À l'heure où les technos web, de plus en plus décomplexées, s'assoient sur une montagne de ressources et où on a tendance à bouder de plus en plus le logiciel applicatif hors navigateur web/electron, je ne mènerais pas ma guerre pour l'optimisation à l'encontre de Java.
Aujourd'hui on préfère la composition à l'héritage. Les cadriciels d'injection de dépendance encourage cette pratique.
Abus des getters/setters
Depuis Java 17, les records permettent de simplifier la syntaxe.
Lenteur excessive. Les langages interpretés c'était bien avant (#boomer). On a des boites à outils pour faire du natif sans se casser la tête (merci LLVM). “Java, write once, run away”.
Graalvm permets de compiler une application native. Sur un petit web service migré récemment, j'ai divisé le démarrage par 5 (de 10 à 2 secondes) et la consommation mémoire par 30 (de 300mo à 10mo).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par barmic 🦦 .
Évalué à 4.
Dernière modification le 11 août 2022 à 13:22.
Lenteur excessive. Les langages interpretés c'était bien avant (#boomer). On a des boites à outils pour faire du natif sans se casser la tête (merci LLVM). “Java, write once, run away”.
Graalvm permets de compiler une application native. Sur un petit web service migré récemment, j'ai divisé le démarrage par 5 (de 10 à 2 secondes) et la consommation mémoire par 30 (de 300mo à 10mo).
Java est généralement compilé en natif même sans graalvm. Pour le temps de démarrage c'est logique (il y a un travail en cours à OpenJDK pour ça par contre la mémoire c'est surprenant. Graalvm ne fait pas grand chose pour ça, il permet au gc d'être plus rapide mais c'est à peu près tout. C'est pas que la jvm n'était pas tunnée ?
Même que c'est pour ça que ça n'a jamais été utilisé pour faire des jeux vidéo sur les vieux téléphones… laissez-moi réfléchir… j'ai comme l'impression d'oublier un détail important, la?
Plus sérieusement, je ne pense pas que Java soit la raison derrière le gouffre en RAM et la faible lenteur.
J'accuserai plus volontiers des développeurs qui ne se sont pas cassés la tête, parce que "le client rachètera de la RAM au pire" (entendre ça de la part d'un prof, ça fait rêver… et c'était pas sur du java!), parce qu'il faut release rapidement ou autre.
Ainsi, pour les serveurs, que les admins qui n'ont pas paramétré la JVM selon les besoins de l'application.
Le java dont je me souviens (je n'ai jamais aimé ce langage) a effectivement des "problèmes" hein:
définir la fonctionmain() comme étant une fonction statique d'une classe qui sera instanciée qu'une seule fois, parce que seule la POO devrais exister (oupa)
des namespace avec une profondeur telle qu'on se demande si a force de creuser on va pas finir en enfer
Mais globalement, les exceptions bien spécifiées je trouve ça au contraire génial: si C++ avait ça, ben les exceptions je m'en servirais!
Les getter/setter, j'ai toujours eu ça en horreur, mais c'est pas lié à java, juste a du cargo cult.
Overengineering? Idem.
Tous les trucs que je reprochais à Java, je les ai vus dans des codes dans d'autres langages. Tous.
D'autres langages? Lesquels? C. Et C++.
Oui, j'inclue le C, parce que j'ai vu des gens réimplémenter l'héritage (c'est pratique faut dire, quand c'est bien utilisé) en C, et en abuser. Les namespaces n'existent pas en C? Pas grave, le workaround c'est des "conventions de nommage" du style un_truc_comme_ca_et_ajoutons_encore_un_peu_de_texte_pour_la_route(). Le truc, c'est que tant C++ que Java permettent de faire du using pour réduire ça. Avec le C, on ne peut pas, on est obligé de recourir à des #define…
Ah. Le Go et le Rust, c'est mieux. C'est probablement vrai, mais… l'astuce, c'est l'âge.
Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.
En face, C, C++, Java, Pascal… ces langages ont de l'historique. Et, non, faire comme python2 vers python3 n'est pas acceptable pour des langages de leur importance. A titre d'exemple, le programme ppp que l'on utilise pour les liaisons point à point (modems, entres autres, et sisi c'est toujours utilisé) utilise a certains la endroits des résidus de K&R.
Il arrive que quelques points soient interdits dans des versions plus à jour (auto_ptr pour C++, pour le C les trigrammes sont retirés dans C11 il me semble) mais c'est rare et ne casse pas 90% des bases de code.
Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.
Même si c'est l'explication qu'on trouve sur wikipedia par exemple, ce n'est pas la vraie origine (ceci dit ça a j'imagine aussi été gardé pour le double sens) :
Posté par Maclag .
Évalué à 5.
Dernière modification le 11 août 2022 à 15:36.
Si on a besoin de faire des entrées de blogs pour expliquer qu'un langage ne se porte pas mal, c'est peut-être qu'on est un tout petit peu anxieux aussi, non?
Si un langage est immensément populaire, j'aurais pensé qu'on n'a pas besoin de le dire, parce que ça se voit tout seul.
Comme par exemple des devs Java qui recodent des clients de Tribune en langage populaire. Je dis ça, je dis rien (mais je viens de l'écrire quand même!).
D'ailleurs, StackOverflow avait fait un classement non pas basé sur la demande mais basé sur l'intérêt des codeurs pour le langage qu'ils utilisent: the programming languages they use and if they're interested in continuing to develop with them.
Comme par exemple des devs Java qui recodent des clients de Tribune en langage populaire
Le passage de jb3 à gb3 était logique : Go n'est jamais qu'un Java en moins bloated.
A propos de langage populaire, personne n'a encore écrit de clients de tribune ou de tribune en Rust, pourtant premier dans le classement de stackoverflow. Parce qu'il n'est pas assez performant ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Après Elixir en 2ème, Clojure en 3ème, Delphi en 7ème, SQL en 9ème, solidity en 15ème (un langage pour ethereum),… Le survey me semble donner avantage à certains langages de relativement de niche. Par contre si on va dans la partie "want" java est 10ème.
# Nope
Posté par David Demelier (site web personnel) . Évalué à 2.
Je comprendrai jamais l'intérêt que porte les gens sur Java. Ce langage principalement utilisé en école et en entreprise promeut tant de choses qu'on dit « bonnes » juste par principe mais finalement n'apporte rien :
private RS232 connect() throws NoSuchPortException, PortInUseException, UnsupportedCommOperationException, IOException, TooManyListenersException, Exception {git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nope
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Je pense que ta vision de Java doit dater des années 90.
Accessoirement, la majorité de tes points ne sont pas liés au langage lui-même mais à ce que certaines personnes en font.
Celle-là m'a bien fait rire.
Bref, on ne te fera pas changer d'avis mais, des fois, c'est pas mal de se poser la question de pourquoi tant de gens aiment quelque chose quand on a des idées préconçues comme ça.
[^] # Re: Nope
Posté par David Demelier (site web personnel) . Évalué à 4.
Je ne parle pas sans connaissance de cause, je maintien des applications en Java à mon travail et je t'assure que j'ai envie de trucider l'ancien développeur qui s'est dit que ça allait être une bonne idée de faire du Java sur de la Raspberry et de la BeagleBone.
Le simple démarrage de l'application met déjà plus de 3 secondes avant même d'arriver dans nos premières fonctions. L'application en elle même n'est pas spécialement compliquée, mais tout est lent. Dire que Java est performant est de la pure mauvaise foi ;)
J'ai fait du Java pendant plusieurs années, je ne parle pas dans le vent. Je m'intéresse à beaucoup de langages et c'est clairement celui dont je ne comprends toujours et encore pas l'intérêt. Comme c'est sujet à débat, je t'invite à me dire ce qui te plait dans ce langage et serait fortement ravi de savoir de quoi il s'agit.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nope
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 11 août 2022 à 13:18.
Moi c'est libreoffice qui est lent comme ça sur mon pi. Dire que C++ est un langage performant est de la pure mauvaise fois.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nope
Posté par Elfir3 . Évalué à 5.
Java sur un rpi, si tu cherches la petit bête aussi…
Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)
Un peu plus sérieusement, chez nous ce sont les containers java qui prennent a peu près une minute pour être fonctionnels quand des applications plus élaborées en python sont dispo quasiment instantanément. Ce sont les même développeurs (java à la base) qui ont fait les deux codes. Et je ne parle pas de la consommation de mémoire …
Sur certains points, c'est pas encore ça.
Par contre, point de vue vitesse d’exécution y'a pas photo, java a une longueur d'avance.
[^] # Re: Nope
Posté par David Delassus (site web personnel) . Évalué à 0.
L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?
L'argument est douteux, si tu configure proprement ta JVM, et optimise correctement ton appli, Java va très bien tourner même sur un grille pain.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Nope
Posté par barmic 🦦 . Évalué à 4.
Ça n'a jamais voulu dire que ça doit s'exécuter partout avec la même performance. Par contre il me semble que java ne s'exécute pas sans utiliser une virtualisation en plus sur M1, sur risc-v et sur ios. Et il ne s'exécute plus sur navigateur non plus.
Ça doit être pour ça que le slogan est mort avec son créateur : sun microsystems. C'est un peu comme utiliser le premier non de c++ pour en parler "c with classes".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nope
Posté par gouttegd . Évalué à 5.
Sur risc-v et ios, je ne sais pas, mais sur M1, non, on n’est pas obligé de passer par l’émulation x86_64 (même si c’est possible). Il y a des JVM ciblant directement l’architecture arm.
Et c’est heureux, parce que pour avoir testé les deux (JVM x86_64 sous émulation vs JVM arm64 native), les performances de la version native sont bien meilleures, malgré tout ce que peut dire Apple sur la qualité de son émulation x86_64 qui soi-disant autoriserait à utiliser des programmes x86_64 sur M1 sans qu’on ne puisse jamais voir la différence…
[^] # Re: Nope
Posté par YBoy360 (site web personnel) . Évalué à 4. Dernière modification le 11 août 2022 à 15:40.
Quelle JVM usitlises-tu ?
Il y a eut beaucoup d'amélioration concernant le RPi, celle par défaut n'est pas performante.
Les tél Android ne sont pas tellement plus puissant qu'un RPi, les applications ne mettent pas beaucoup de temps pour se lancer.
[^] # Re: Nope
Posté par Guillaume Smet (site web personnel) . Évalué à 5. Dernière modification le 11 août 2022 à 15:53.
Sauf que tu parles d'anecdotes, de plus sur des systèmes ultra spécifiques. Il y a beaucoup de gens qui utilisent Java et sont très contents des performances.
Pour des applications serveurs, le compilateur JIT de Java est assez redoutable.
Si tu veux faire des applications type CLI, tu as GraalVM de nos jours (qui fait de la compilation AOT, ce qui dans certains cas sera moins performant que de la compilation JIT car le JIT peut optimiser des choses basées sur les motifs d'exécution).
Pour prendre un exemple, mon bot GitHub en Quarkus pour le projet Quarkus (dont je compte parler un de ces jours sur ce site) démarre en 20ms compilé en natif avec GraalVM.
Et l'implémentation d'une action simple avec le framework Quarkus GitHub App que j'ai développé pour ça est en tout et pour tout :
C'est à dire qu'avec juste cela, tu auras un bot GitHub qui répond aux requêtes et ajoute un commentaire pour tout nouvel issue GitHub créé. Rien besoin d'autre mis à part un fichier de configuration pour les clés de signature. Et l'IOException est là juste à cause de l'API Java GitHub qui devrait virer cette exception dans la prochaine version majeure.
Le fait qu'on puisse mal bosser en Java ne dit rien sur le langage. Tu peux mal bosser dans tous les langages.
Bon et puis parfois, ce n'est juste pas le bon langage pour la tâche. Et c'est pas bien grave, utilise autre chose dans ce cas.
[^] # Re: Nope
Posté par Élafru . Évalué à 8.
Et pourtant via Java sur Android on a des centaines de milliers d'applications rapides et performantes sur des plateformes embarquées.
Dans la même veine, quand on paie sans contact avec notre carte bancaire, tu as un système d'exploitation qui démarre, initialise une JVM, et fait tourner du Java(card), le tout en 1 ou 2 secondes, le temps du bip.
À l'heure où les technos web, de plus en plus décomplexées, s'assoient sur une montagne de ressources et où on a tendance à bouder de plus en plus le logiciel applicatif hors navigateur web/electron, je ne mènerais pas ma guerre pour l'optimisation à l'encontre de Java.
[^] # Re: Nope
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Sur quelques points, java a évolué.
Aujourd'hui on préfère la composition à l'héritage. Les cadriciels d'injection de dépendance encourage cette pratique.
Depuis Java 17, les records permettent de simplifier la syntaxe.
Graalvm permets de compiler une application native. Sur un petit web service migré récemment, j'ai divisé le démarrage par 5 (de 10 à 2 secondes) et la consommation mémoire par 30 (de 300mo à 10mo).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Nope
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 11 août 2022 à 13:22.
Java est généralement compilé en natif même sans graalvm. Pour le temps de démarrage c'est logique (il y a un travail en cours à OpenJDK pour ça par contre la mémoire c'est surprenant. Graalvm ne fait pas grand chose pour ça, il permet au gc d'être plus rapide mais c'est à peu près tout. C'est pas que la jvm n'était pas tunnée ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nope
Posté par freem . Évalué à 8.
Même que c'est pour ça que ça n'a jamais été utilisé pour faire des jeux vidéo sur les vieux téléphones… laissez-moi réfléchir… j'ai comme l'impression d'oublier un détail important, la?
Plus sérieusement, je ne pense pas que Java soit la raison derrière le gouffre en RAM et la faible lenteur.
J'accuserai plus volontiers des développeurs qui ne se sont pas cassés la tête, parce que "le client rachètera de la RAM au pire" (entendre ça de la part d'un prof, ça fait rêver… et c'était pas sur du java!), parce qu'il faut release rapidement ou autre.
Ainsi, pour les serveurs, que les admins qui n'ont pas paramétré la JVM selon les besoins de l'application.
Le java dont je me souviens (je n'ai jamais aimé ce langage) a effectivement des "problèmes" hein:
main()comme étant une fonction statique d'une classe qui sera instanciée qu'une seule fois, parce que seule la POO devrais exister (oupa)Mais globalement, les exceptions bien spécifiées je trouve ça au contraire génial: si C++ avait ça, ben les exceptions je m'en servirais!
Les getter/setter, j'ai toujours eu ça en horreur, mais c'est pas lié à java, juste a du cargo cult.
Overengineering? Idem.
Tous les trucs que je reprochais à Java, je les ai vus dans des codes dans d'autres langages. Tous.
D'autres langages? Lesquels? C. Et C++.
Oui, j'inclue le C, parce que j'ai vu des gens réimplémenter l'héritage (c'est pratique faut dire, quand c'est bien utilisé) en C, et en abuser. Les namespaces n'existent pas en C? Pas grave, le workaround c'est des "conventions de nommage" du style
un_truc_comme_ca_et_ajoutons_encore_un_peu_de_texte_pour_la_route(). Le truc, c'est que tant C++ que Java permettent de faire duusingpour réduire ça. Avec le C, on ne peut pas, on est obligé de recourir à des#define…Ah. Le Go et le Rust, c'est mieux. C'est probablement vrai, mais… l'astuce, c'est l'âge.
Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.
En face, C, C++, Java, Pascal… ces langages ont de l'historique. Et, non, faire comme python2 vers python3 n'est pas acceptable pour des langages de leur importance. A titre d'exemple, le programme
pppque l'on utilise pour les liaisons point à point (modems, entres autres, et sisi c'est toujours utilisé) utilise a certains la endroits des résidus de K&R.Il arrive que quelques points soient interdits dans des versions plus à jour (auto_ptr pour C++, pour le C les trigrammes sont retirés dans C11 il me semble) mais c'est rare et ne casse pas 90% des bases de code.
[^] # Re: Nope
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Même si c'est l'explication qu'on trouve sur wikipedia par exemple, ce n'est pas la vraie origine (ceci dit ça a j'imagine aussi été gardé pour le double sens) :
https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/
(Graydon étant un des créateurs)
# Commentaire de jeudredi
Posté par Maclag . Évalué à 5. Dernière modification le 11 août 2022 à 15:36.
Si on a besoin de faire des entrées de blogs pour expliquer qu'un langage ne se porte pas mal, c'est peut-être qu'on est un tout petit peu anxieux aussi, non?
Si un langage est immensément populaire, j'aurais pensé qu'on n'a pas besoin de le dire, parce que ça se voit tout seul.
Comme par exemple des devs Java qui recodent des clients de Tribune en langage populaire. Je dis ça, je dis rien (mais je viens de l'écrire quand même!).
D'ailleurs, StackOverflow avait fait un classement non pas basé sur la demande mais basé sur l'intérêt des codeurs pour le langage qu'ils utilisent:
the programming languages they use and if they're interested in continuing to develop with them.
Edit: J'avais oublié l'URL /o\
https://www.businessinsider.com/stack-overflow-developer-survey-14-most-loved-programming-languages-2020-5?op=1#14-scala-1
Et Java n'est même pas dans ce classement qui affiche les 14 premiers…
[^] # Re: Commentaire de jeudredi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 12 août 2022 à 09:04.
Le passage de jb3 à gb3 était logique : Go n'est jamais qu'un Java en moins bloated.
A propos de langage populaire, personne n'a encore écrit de clients de tribune ou de tribune en Rust, pourtant premier dans le classement de stackoverflow. Parce qu'il n'est pas assez performant ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Commentaire de jeudredi
Posté par barmic 🦦 . Évalué à 5.
Il est pas loin derrière C++.
Après Elixir en 2ème, Clojure en 3ème, Delphi en 7ème, SQL en 9ème, solidity en 15ème (un langage pour ethereum),… Le survey me semble donner avantage à certains langages de relativement de niche. Par contre si on va dans la partie "want" java est 10ème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.