Pourquoi les startups évitent-elles Java ?
(news.ycombinator.com)Pourquoi les startups évitent-elles Java ? Réponses à une question publiée sur HN
- La raison principale est que l’écosystème Java est cassé, avec l’horreur de Maven/Gradle, etc.
- Elles l’évitent à cause des développeurs qui vénèrent Spring.
- Parce qu’on confond Java avec hibernate/springboot.
- Java évoque un code d’entreprise ennuyeux, pas un sujet brûlant moderne comme Rust.
- Si l’on doit utiliser la JVM, mieux vaut employer un autre langage comme Kotlin ou Clojure.
- Dire en 2022 que votre nouvelle startup utilise Java, c’est comme dire qu’elle utilise Cobol.
- Autrefois c’était hype et tendance, puis Oracle est arrivé.
47 commentaires
+1 à la fin. Après le rachat par Oracle, ça a commencé à régresser.
On sait très bien qu’elles n’ont pas les moyens d’assumer les coûts ni de recruter les effectifs nécessaires, alors qu’est-ce que tu racontes...
Maven/Gradle, etc., quelle horreur
Ça laisse entendre qu’on voit le niveau de l’auteur rien qu’en lisant ça
Merci pour vos conseils, je m’en vais en les ayant bien écoutés.
L’avantage de la facilité de recrutement peut aussi devenir l’inconvénient que vraiment n’importe qui postule.
Il y aura des vétérans qui ont laissé de côté Kotlin et Scala et maîtrisent la JVM, et il y aura aussi des gens qui ont plus de 10 ans d’expérience Java dans le secteur du SI mais aucune volonté de progresser techniquement, qui ne connaissent même pas la Stream API et restent bloqués sur la syntaxe de l’époque. Si on recrute en golang ou en rust, j’ai l’impression que la proportion de cette seconde catégorie diminuerait nettement. Pour Python, je ne sais pas...
Passer de Java à Kotlin n’est pas difficile, et passer de JSP à Thymeleaf ne l’est pas non plus. Il y a simplement l’inconvénient du manque de références. Quoi qu’il en soit, commencez par travailler les objets, l’héritage et la conception structurée. Dépendre de bibliothèques ou d’outils annexes ne prouve qu’une chose : que vous êtes débutant.
Personnellement, j’ai l’impression que Java souffre d’une forte asymétrie d’information du fait de sa longue histoire.
Comme c’était un langage qui a marqué toute une époque, il reste encore beaucoup de contenus produits à ce moment-là, et même après d’innombrables mises à jour, ces contenus semblent souvent être reproduits comme s’ils étaient toujours valables.
Je me souviens avoir eu beaucoup de mal à trouver de nouvelles approches adaptées aux versions récentes.
Ce n’est pas comme si les autres langages étaient épargnés, mais s’il fallait citer des langages très fragmentés, je choisirais sans hésiter Python et Java.
Cela dit, Python est toujours souvent adopté dans les startups parce qu’il est réputé pour sa rapidité de développement.
Mais cela me semble différent des raisons pour lesquelles les startups évitent Java.
[Raisons pour lesquelles les startups évitent Java]
[Mais raisons pour lesquelles les startups devraient choisir Java]
[Mais raisons pour lesquelles il faut quand même y réfléchir à deux fois]
Indépendamment du fait que Java soit bon ou non, ce que je ressens concrètement, c’est que Java ne semble pas être la technologie dominante dans les startups à l’étranger.
J’ai déjà effectué des analyses techniques dans le cadre d’acquisitions d’entreprises étrangères, et pas une seule n’utilisait Java. Fait intéressant, il y avait étonnamment beaucoup de .NET.
J’ai eu la même expérience il y a déjà 2 ou 3 ans, donc c’est un point de vue auquel j’adhère assez facilement.
Maven est trop verbeux, donc je ne l’aime pas trop non plus,
mais Gradle était donc horrible lui aussi.
Moi, c’est plutôt
npmqui me fait le plus peur ;Et puis, je trouve que citer COBOL, c’est quand même un peu abusé.
C’est peut-être parce que c’est surtout utilisé par des développeurs de grands groupes haha.
Quoi qu’il en soit, je trouve toujours amusant de voir Java se faire critiquer aveuglément. En regardant les exemples, on finit par voir les expériences sombres propres à chacun.
Java a été trop paresseux.
Il mérite de se faire critiquer.
Ces derniers temps, on dirait qu’il fait un peu plus d’efforts, mais à mon avis il mérite encore davantage de critiques.
De toute façon, au fil des générations, une autre langue finira par devenir dominante. Pour les startups, la phase de décision pour adopter une nouvelle tendance est plus simple, et pour sortir du stade de startup, il faut aussi que le langage qu’elles utilisent devienne dominant. À l’inverse, dans les grandes entreprises, la prise de décision est plus complexe et implique davantage d’intérêts divergents, donc elles ne l’adoptent qu’une fois sa stabilité assurée. N’est-ce pas là la différence ? COBOL, apparu en 1959, n’a disparu du secteur financier qu’au XXIe siècle. À titre de référence, même Java, que beaucoup d’entre vous jugent médiocre, a démarré comme un projet open source et a été à une époque le langage le plus populaire dans les SOHO. Et si Java s’est retrouvé associé à une image de grand groupe, c’est après son rachat par Oracle et, en Corée, avec l’apparition du framework e-government piloté par l’État.
Je me demande d’où vient ce mythe selon lequel « Java n’est populaire qu’en Corée ». Est-ce parce qu’en Corée, parmi les grands groupes IT, il n’y a au fond que deux entreprises de type Naver/Kakao et que toutes deux utilisent Java ?
Bien sûr, aux États-Unis, le vivier d’ingénieurs est bien plus large, donc il est plus facile de monter une équipe avec d’autres langages. Mais même dans les entreprises IT américaines, FAANG comprises, Java reste une stack technique tout à fait courante.
Comme ce sont des entreprises énormes, les différences d’une équipe à l’autre sont très marquées, mais chez Amazon, le framework standard interne est carrément en Java (j’ai entendu dire qu’ils utilisaient Spring dans la version 2 puis qu’ils sont maintenant passés à Guice). Pour Google, il me semble que c’est à peu près moitié C++ / moitié Java, avec aussi quelques équipes qui utilisent Python. Et chez Apple aussi, si je ne me trompe pas, la majorité des services web tourneraient sur Java.
Pour Netflix, il n’y a même pas besoin d’en parler : hystrix, zuul, eureka, tout ça a été créé par Netflix, donc je me dis que c’est peut-être l’entreprise qui maîtrise le mieux Spring au monde.
Chez Facebook aussi, c’est surtout du C++ ou du Hack, mais je crois savoir qu’il existe aussi quelques équipes qui utilisent Java.
Twitter aussi, si je ne me trompe pas, a commencé en Ruby avant de migrer vers Scala, un langage de la JVM. Et au-delà de ça, chez des grandes entreprises comme Atlassian, VMware, Red Hat, etc., il serait sans doute plus difficile de trouver celles qui n’utilisent pas Java que celles qui l’utilisent.
Comme Kafka, Hadoop, etc. tournent tous sur la JVM, même si une entreprise n’utilise pas Java directement pour ses services, je me dis qu’il n’existe probablement presque aucune entreprise qui n’en ait vraiment pas besoin.
Personne ne nie que Java a été largement utilisé par le passé. Cela me semble assez éloigné de l’idée principale de cet article.
Ton texte parle en lui-même des grandes entreprises de manière générale, indépendamment du pays, mais dans les commentaires je remarque particulièrement beaucoup de mentions du type « en Corée, c'est comme ça » ou « cela ne vaut que pour la Corée ».
La Corée n’est pas le seul pays où Java est beaucoup utilisé, mais il semble que ce soit particulièrement vrai en Corée. Par exemple, selon les résultats de l’enquête de JetBrains l’an dernier, « Java est le langage le plus utilisé en Corée, en Chine et en Allemagne. La part de Java est de 53 % en Corée, 47 % en Chine et 33 % en Allemagne. ». Je pense que, parmi les facteurs expliquant ce phénomène, l’existence du e-Government Framework, souvent mentionnée dans les commentaires, ainsi que le programme des formations au code financées par l’État, ont clairement dû avoir une influence.
Certains commentaires me rappellent l’article sur C++ publié il y a quelque temps. Il est clair que, dans la communauté des développeurs coréens, C++ et Java ont pratiquement atteint le statut de vaches sacrées, haha ; dès qu’on les critique, on dirait que cela déclenche le bouton de crise chez une foule de gens…
Il y a bien sûr des raisons pour lesquelles Java a dominé le marché coréen, mais mettre C++ et Java dans le même panier, c’est un peu… haha.
Le terme « bouton de crise » ne me semble pas être une très bonne expression. Il donne une image négative de l’autre partie.
Je me permets de le dire avec l’espoir que nous puissions devenir une communauté qui se respecte un peu plus mutuellement. Désolé.
Je suis d’accord. Il ne semble pas nécessaire de s’excuser.
Je pense moins que les startups évitent Java que que les avantages des autres langages/frameworks sont plus importants, mais je suis d’accord sur le fait que l’écosystème Java/Spring est moins bon qu’on ne le pense. Honnêtement, même si je suis développeur Spring, je n’aime pas particulièrement Spring. Comme il y a peu de développeurs qui ont fait du développement d’applications web dans un autre environnement que Java (en pratique synonyme de Spring), l’impression est encore pire..
Spring
Java
Les avantages de l’écosystème JVM existent clairement, donc Kotlin est presque indispensable sur un nouveau projet, et s’il n’y a pas de raison évidente de partir sur Spring, je pense qu’il est préférable de commencer avec un framework léger comme ktor. Beaucoup rétorquent aux défauts pointés qu’il s’agit d’un mauvais design ou d’un développement mené sans bien comprendre la philosophie de Spring, mais l’OOP, on peut aussi en faire avec d’autres langages..
Même si l’espace commentaires est extrêmement brouillon et agressif, c’est un commentaire auquel je peux m’identifier.
Je suis d’accord sur le fait qu’il faut adopter plus activement de nouveaux langages et frameworks, mais, pour être franc, la réalité chez nous est qu’il y a encore énormément de gens qui, même lorsqu’ils lancent tout juste un nouveau projet, choisissent par inertie Java 8 au lieu de Java 17, la dernière version LTS, sans la moindre raison rationnelle. Si l’on regarde sur des plateformes comme les blogs Tistory, on trouve vraiment très facilement des articles du type « Comment télécharger Java 1.8 » publiés avec une date de cette année 2022. Quand on voit ça, on se dit que si beaucoup d’autres personnes ici affichent une aversion extrême pour Java, ce n’est peut-être pas sans raison.
Cela dit, j’ai l’impression que ces problèmes ne proviennent pas uniquement du langage Java lui-même. Je pense plutôt que le vrai problème, surtout très marqué chez nous, est une culture hostile au changement et la prolifération de code copié-collé sans aucune progression. En réalité, je travaille à la maintenance de plusieurs programmes similaires développés en C# ; je considère que le langage lui-même est meilleur que Java, mais même avec un bon langage, il n’y a aucun moyen d’échapper à l’horreur d’un code où le prédécesseur s’est contenté de bricoler en copiant-collant du code d’anciens projets. C’est encore plus terrible maintenant qu’en raison de changements dans l’environnement externe, une grande partie de ce code répétitif doit impérativement être remplacée d’ici la fin de l’année.
C’est un vrai bouton rouge qui déclenche des réactions, mais uniquement en Corée.
Je pense qu’il sera difficile d’abandonner Java, largement utilisé depuis longtemps, et comme il faut continuer à recruter, les académies financées par l’État continuent de produire à la chaîne des profils Spring avec le même cursus...
J’ai l’impression qu’il sera difficile de briser ce cercle.
Je vois d’un bon œil les tentatives d’utiliser Kotlin + Spring.
Quand on utilise Docker...
la taille de l'image Docker grossit aussi inutilement.
Le démarrage prend aussi longtemps, etc.
De nos jours, comme tout le monde utilise Docker, j'ai l'impression que c'est devenu moins apprécié..
L’écosystème Java ne s’est jamais véritablement effondré.
Il existe d’innombrables projets open source, et au fil des montées de version, il reflète selon moi les tendances actuelles du développement plus rapidement que d’autres langages.
gradle/mavenne sont que des outils de build parmi d’autres, pas une obligation.Il en existe beaucoup d’autres, et on peut utiliser celui qu’on veut.
Pourquoi utilise-t-on
npmdans Node ? Parce que c’est pratique.gradle/maven, c’est pareil : s’ils sont largement utilisés, c’est parce qu’ils sont pratiques.Même s’il existe de nombreux frameworks en Java, si Spring est utilisé, c’est parce qu’il offre une extension flexible, une gestion de projet pratique et des performances stables, ce qui explique selon moi sa popularité jusqu’à aujourd’hui.
Quand on regarde pourquoi des startups basculent vers Java à mesure que leur activité grandit, la plupart prennent cette décision pour bénéficier d’une gestion de projet plus stable.
Jusqu’ici, il n’y a pas de problème à développer à petite échelle avec Python ou Node, mais si l’entreprise réussit et que l’équipe passe à 100 puis 1 000 développeurs travaillant sur le même projet, il devient difficile de conserver les avantages de Python ou de Node, et leurs inconvénients prennent au contraire plus de place.
Je pense que c’est pour cela qu’elles se tournent vers Java, qui permet de gérer la qualité sur de grands projets tout en garantissant la stabilité.
S’il avait existé une meilleure alternative que Java, n’aurait-on pas adopté ce langage de remplacement avant tout le monde ?
Enfin, les services développés en Java ont une barrière à l’entrée élevée au départ, ainsi que des coûts d’infrastructure élevés. C’est pourquoi, au début d’une startup, on voit surtout l’usage de langages faciles et rapides à mettre en place, plutôt que de consacrer beaucoup de temps et d’argent à l’initialisation.
Déjà, en Corée, il y a surtout un trop-plein de développeurs Java. Plus précisément, il n’y a pratiquement que des développeurs Spring plutôt que de vrais développeurs Java. Comme le framework d’e-gouvernement est basé sur Spring, tous les développeurs formés au kilomètre finissent par n’apprendre que Spring. C’est pour ça qu’il y en a à revendre, même parmi les profils expérimentés. Il n’y a pas de diversité, et l’écosystème du langage est déjà cassé. Beaucoup se disent développeurs Java alors qu’ils ne savent même pas créer un simple forum sans Spring.
Le point clé de cette question, c’est la notion de « startup » : ce qui compte, ce n’est pas tant la « stabilité/scalabilité » que la « vitesse de développement ».
Pour une startup, le temps, c’est de l’argent !
(Quand il y aura plus tard du temps et de l’argent, on passera à Java ?)
Et la popularité de Java ne semble pas être une spécificité propre à la Corée. C’est encore aujourd’hui l’un des 3 langages de programmation les plus populaires.
J’ai l’impression que ce genre de discours sur une migration vers Java ne fonctionne qu’en Corée.
Dans les grandes entreprises, beaucoup de systèmes sont en Java, donc l’objectif principal est surtout la maintenance.
Qu'Oracle entre en scène ou non n'a en réalité pas beaucoup d'importance pour la plupart des entreprises de terrain... même chez Naver, Kakao, Line, Coupang, Baemin, les systèmes principaux sont tous en Java. Même dans des sociétés de jeux comme Nexon, le backend interne est aussi écrit en Java.
Je ne suis absolument pas d'accord avec l'idée que l'écosystème Java serait en ruine ou que Gradle serait affreux.
Je ne vois pas bien la logique qui consiste à dire que, sous prétexte que Java est un vieux langage et qu’il y a beaucoup de développeurs Java, ces gens n’aiment pas apprendre de nouvelles choses ou auraient une qualité inférieure.
Nekaracoubé a entièrement Java comme stack principale, et récemment Kotlin est introduit petit à petit.
À moins que vous ne vouliez vraiment dire que les vrais experts sont dans les startups ? haha
Je pense qu’il devrait y avoir une traduction plus appropriée pour « hotshit ».
« Dire en 2022 que votre nouvelle startup utilise Java, c’est comme dire qu’elle utilise Cobol. »
En Corée, il est impossible de battre l’argument selon lequel il est facile de recruter des développeurs Java. Quant à la qualité des développeurs recrutés de cette façon, c’est une autre histoire.
Dire que l’écosystème Java est cassé ? Pourquoi Spring ne conviendrait pas ? Les arguments sont bien trop faibles.
Si la JVM était une cryptomonnaie, Java serait le bitcoin.
MDRRRRRRRRRRRRRRRR
Ce n’est pas pour rien qu’il y avait autrefois le mème disant qu’il fallait deux personnes rien que pour Java… En plus, comme Java est le framework standard du gouvernement, on l’utilise presque de manière semi-obligatoire dans les projets SI du secteur public…
J’ai du mal à comprendre l’idée que la toolchain côté Java ne soit pas terrible.
Le mode de gestion de Maven/Gradle était presque paradisiaque comparé à ce que j’ai subi avec npm...
J’ai moi aussi commencé ma carrière avec Java, et après avoir travaillé environ quatre ans dans une entreprise uniquement comme développeur Java, j’ai changé plusieurs fois de société, ce qui m’a permis de découvrir différents langages comme Python, Ruby ou Go. Depuis peu, je poursuis ma carrière comme développeur Solidity.
Dernièrement, on voit beaucoup de startups, une fois qu’elles ont atteint un certain niveau de croissance et sont entrées dans une phase de stabilité, migrer l’essentiel de leur infrastructure vers Java. En y réfléchissant, j’ai fini par me dire
que c’était simplement par inertie.
Beaucoup de développeurs de niveau lead sont à l’aise avec Java et hésitent à apprendre d’autres langages, alors ils utilisent tout simplement le Java qu’ils connaissent bien. Et quand ce type de profils afflue vers les startups, on a l’impression que toute l’infrastructure finit par devenir basée sur Java.
Personnellement, j’ai du mal à comprendre qu’on refonde une infrastructure pour la seule raison qu’on est habitué à un langage. Mais les gens sont naturellement réticents à apprendre de nouvelles choses, et comme l’écosystème Java est extrêmement solide en Corée du Sud, il me semble que le faire évoluer sera très difficile.
Java et Spring sont bien adaptés pour fournir des services à grande échelle de manière stable, mais les premiers services d’une startup sont de petite taille, donc il est difficile de tirer parti des avantages de Java.
Au début, une startup peut aussi devoir gérer le front et le back avec une équipe réduite, et pour cela il est plus pratique de tout développer d’un seul coup avec Node.js ou JS qu’avec Java.
Au final, une fois qu’elles obtiennent des investissements en série, elles finissent toutes par migrer vers Java et Spring, non ?
le premier point, je ne le comprends pas toujours très bien. Ce n’est pas non plus que les autres langages soient instables. De toute façon, à grande échelle, il faudra aussi optimiser Java.
Quand on regarde, j’ai parfois l’impression qu’ils disent simplement que c’est « stable » parce qu’ils y sont habitués et que cela leur facilite le tuning des performances et le troubleshooting.
Comme vous le savez tous, Java fournissait dès ses premières versions plusieurs choses qui nous paraissent aujourd’hui tout à fait évidentes, comme la gestion automatique de la mémoire. Et lorsque Java est apparu pour la première fois dans les années 1990, des langages comme C ou C++, où une simple erreur du développeur pouvait provoquer une fuite mémoire et affecter bien plus gravement la fiabilité de l’ensemble de l’application, étaient alors bien plus largement utilisés qu’aujourd’hui. À une époque comme celle-là, l’arrivée d’un langage qui, même s’il pouvait entraîner un arrêt temporaire de l’exécution (stop-the-world), réduisait fortement la probabilité qu’un service tombe complètement à cause d’un problème mémoire, a apparemment fait sensation. C’est pourquoi Java a commencé son histoire avec l’image d’un langage bien plus stable que les autres, et j’ai l’impression que cette image s’est maintenue jusqu’à aujourd’hui.
Par ailleurs, à l’heure actuelle, Java bénéficie d’un haut niveau de confiance et d’une expérience accumulée grâce à son utilisation large et durable dans toutes sortes de services. Comme vous le dites, cela facilite aussi bien le réglage des performances que le troubleshooting, et il existe de nombreux outils et solutions, qu’ils soient commerciaux ou open source. L’écosystème d’un produit largement utilisé a en lui-même pour effet de rendre la résolution de problèmes plus facile, et le fait qu’en cas d’incident il soit plus simple de résoudre le problème et donc de réduire le downtime représente un avantage majeur pour ceux qui accordent de l’importance à la stabilité.
Et dans le cas de Kotlin, souvent mentionné dans d’autres commentaires, d’après un autre commentaire posté sur GeekNews, il y aurait de manière assez surprenante encore beaucoup de bugs de compilateur et de problèmes liés à la compatibilité. Quand on voit qu’un langage qui utilise la même JVM et qui existe publiquement depuis bientôt dix ans en est encore là, si l’on place la stabilité tout en haut des critères de décision, il me semble tout à fait rationnel de choisir, sauf raison particulière, quelque chose qui a été suffisamment éprouvé au fil de longues années.
À titre de référence, même si cela peut sembler très étrange aujourd’hui, lorsque Java est apparu pour la première fois, pour reprendre l’expression utilisée par Im Baek-jun dans son livre Polyglot Programming (2014), il « donnait même une impression de fraîcheur, de jeunesse, voire de sex-appeal ». À ce sujet, je vous présente une traduction d’un texte écrit en 1997 par James Gosling, le père de Java.
Je pense que la raison d’aller vers Spring tient à la spécificité du marché des développeurs en Corée.
À l’étranger, la JVM est en général en train de basculer vers Kotlin, comme le dit cet article.
Pour moi aussi, l’image de Java s’est dégradée à cause des adeptes de Spring.
Surtout en Corée, quand on dit qu’on fait du Java, c’est pratiquement toujours du Spring Boot. Du coup, on voit souvent ça comme : Java = Spring Boot.
Je suis développeur et je ne sais pas programmer en Java, alors ça me fait plaisir.
J’ai quand même l’impression que pour recruter dans une startup, ce serait le plus rapide..
Mais en Corée...
J’ai moi aussi utilisé Java à une époque, mais aujourd’hui, j’aimerais éviter d’en faire usage autant que possible.
Pourquoi est-ce à la fois triste et drôle..? haha
(J’utilisais Java dans mon ancienne startup, mais plus maintenant)