D'après cet article
il semblerait qu'Oracle ait décidé de réduire, voire de stopper le développement de Java EE. Cette décision ferait suite au procès perdu contre Google à propos des API Java utilisées dans Androïd.
Je ne sais pas s'il s'agit d'un fake, ou d'une stratégie d'Oracle pour tenter d'influencer le jugement lors d'un procès en appel, mais d'après cet article, "Sans un investissement et un pilotage continus, chaque partie de l’écosystème Java risque de se fragiliser, même chose pour l’industrie IT mondiale qui s’appuie sur cette technologie.
Certains en profitent pour "inciter l’entreprise américaine à coopérer davantage avec la communauté, ou à lui transférer la propriété de Java EE 8".
Personnellement je trouve que les réactions sont un peu trop alarmistes, cependant elles illustrent les risques de se baser sur une techno non libre contrôlée par un seul acteur pour développer son activité, même si cette techno est très populaire (et attention, je n'ai pas dit quie c'est mal, j'ai juste dit que c'est prendre des risques).
Maintenant, question un peu plus technique : pour un daicideur, quelles sont les alternatives à Java EE qui pourraient permettre de migrer leurs applis sans trop de problèmes ? Quelles sont les alternatives tout court ? (Ne me parlez pas de trucs à base de Python ou pire à base de PHP SVP, c'est pas sérieux).
# Alternatives
Posté par Chris K. . Évalué à 6. Dernière modification le 08 juillet 2016 à 12:43.
Utiliser Glassfish et OpenJDK ça ne suffit pas ?
Je n'utilise pas EE mais SE donc c'est une vraie question.
[^] # Re: Alternatives
Posté par barmic . Évalué à 5.
Ça dépend si tu parle vraiment de JavaSE. Spring ou Hibernate se basent sur des spec de JavaEE (les servlets et JPA par exemple).
Ça dépend de beaucoup de choses. Ce qui est craint par le journal, c'est de en plus voir évoluer les standards JavaEE.
Si cela arrive c'est la mort à moyen terme de toutes les techno JavaEE (un écosystème qui ne se renouvèle pas assez est voué à disparaître assez rapidement, il y a encore du boulot dans JavaEE pour gérer les base NoSQL, HTTP2, etc - quand ça existe c'est améliorable -). Et contre ça on peut voir arriver une alternative (comme Spring).
Mais il serait intéressant de garder une forme de standard pour harmoniser les bibliothèques et les frameworks. et c'est là qu'il y a le plus de risques. IBM et RedHat ont annoncé dans la semaine avec d'autres vouloir monter leur propre standard JavaEE pour aller dans ce sens.
Ensuite selon comment Oracle se comporte, il peu vouloir embêter tout ceux qui utilisent JavaEE et là c'est plus embêtant (on ne peu plus faire évoluer JavaEE, il faut repartir de JavaSE et recréer des standards).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Alternatives
Posté par groumly . Évalué à 8.
La question, c'est quelle est la part utile de j2ee qui vient réellement d'oracle?
Je suis pas l'actualité de super près, mais pour autant que je sache, ces derniers temps les évolutions viennent vachement de la communauté qui finit par pousser ses secs dans le standard.
Genre jsr-330 et tout le di/ioc vient de spring et/ou guice, ou des trucs genre jaxrs qui vient en grande partie des nombreux appservers de la communauté.
C'est clair que la standardisation est très appréciable, mais en pratique, tu dépends toujours plus ou moins d'un jar spécifique à l'implementation, donc c'est pas non plus la fin du monde. Genre sur jsr-330, la spec est pas assez complète et manque de features certaines (genre @value), et chez jaxrs, ton code finit toujours par tirer des classes vendor specific. Idem sur jpa, où il va toujours manquer un bout, et tu finit par tirer du hibernate specific de toutes façons.
Du coup, est ce que c'est réellement un problème?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Arguments ?
Posté par Guillaum (site web personnel) . Évalué à 10.
Peux-tu développer ?
Note : bien que j'imagine que ma question soit surement hautement sujette à troll, ce n'est pas mon but. Je ne connais absolument pas l'écosystème Java et donc je ne peux pas vraiment comprendre pourquoi ce n'est pas sérieux. C'est juste le débat statique / dynamique ou c'est autre chose ?
[^] # Re: Arguments ?
Posté par Meewan . Évalué à 6.
Je ne connais pas assez php pour répondre mais je pense qu'on lui reproche la même chose qu'a python
1) python et jee n'ont rien a voir. JEE s'utilise dans des gros serveur d'application (gros dans le sens tres riches en fonctionalités) alors qu'en général python pour le web s'utilise comme des script qui se lancent a chaque requete. Il n'est pas possible dans ces conditions de construire des caches a ce niveau (on peut en mettre a d'autres niveaux)
2) python est extremement lent (de mémoire de l'ordre de 4 ou 5 fois plus lent que java)
3) les developeurs python sont plus rares (moins vrai pour les developeur php). Le langage est moins répendu que java, n'importe quel SSII a plein de dev java, en python il y en a moins (il y a aussi moins de demande)
4) python a des defauts qui le font passer pour un langage jouet (oui GIL c'est de toi qu'on parle) comme l'absence de multi thread ou le fait d'avoir cassé la compatibilité avec python 3.
5) de ce que j'ai vu passer Python scale en général moins bien que JEE
ps: python est un langage génial qui a plein de qualité, mais tu as demandé les defauts face a Java donc les voila
[^] # Re: Arguments ?
Posté par groumly . Évalué à 5.
Le débat statique compilé/dynamique interprète est important aussi.
Je peux changer le nom d'un champ ou supprimer une fonction en Java et être sur que ça va pas me peter à la gueule en production.
L'écosystème aussi. Python n'est pas en reste, certes, mais Java a vraiment tout ce que tu peux imaginer avoir besoin, et toujours en version tres stable.
Et oui, les perfs, effectivement. Quand t'en as besoin, c'est bien :).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Arguments ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Non dans la façon classique/recommandée les scripts ne sont pas relancés à chaque requête. Selon ta configuration, ton app va être relancée toutes les X requêtes ou toutes les X minutes, mais tu peux même laisser vivre ton app ad-vitam. Il me semble que c'est possible en PHP depuis pas mal de temps aussi.
OK pour le reste.
[^] # Re: Arguments ?
Posté par CrEv (site web personnel) . Évalué à 5.
J'ai pas compris, c'est un argument en faveur ou en défaveur de java ça ?
[^] # Re: Arguments ?
Posté par flan (site web personnel) . Évalué à 5.
1) tous les gros frameworks Python (comme Django, par exemple) fonctionnent avec des serveurs d'applications multithreadés ou multiprocess (comme tu veux), sachant qu'il y a plusieurs serveurs d'applications existants (comme uwsgi, gunicorn).
2) les perfs ne sont pas forcément un problème :
- pas mal de sites (notamment sur intranet) n'ont pas forcément beaucoup de clients simultanés
- il faudrait mettre en rapport au temps de dev. si tu dois mettre un dev en plus pendant un an sur un projet parce que faire un projet en Java peut prendre plus de temps, ça coûte 70k€ (en comptant avec une très grosse louche deux fois le salaire pour les charges). Combien coûte un second serveur si un seul ne suffit pas ?
3) vu le niveau des dév. purement Java que j'ai rencontrés, je ne sais pas si c'est un défaut ou une qualité :D
4) on pourrait dire ça de Java ; les défauts de Python ne sont pas dus au hasard, simplement à la base Python n'a pas les mêmes buts que Java
5) on en revient au problème de perfs
[^] # Re: Arguments ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Quand c'est un dév Java qui sort cet argument il se fait éclater.
[^] # Re: Arguments ?
Posté par nlhss (site web personnel) . Évalué à 2.
La maintenabilité est un facteur important. On peut coder rapidement en java (pas aussi rapidement qu'en python mais quand même, ça va assez vite).
[^] # Re: Arguments ?
Posté par wilk . Évalué à 8.
En Java on code vite mais y a beaucoup à coder ;-)
# microsoft
Posté par ckiller . Évalué à 10.
Pendant ce temps là, l'écosystème .NET (parfaitement concurentiel face à j2ee) devient de plus en plus libre.
[^] # Re: microsoft
Posté par Mimoza . Évalué à 6.
Exactement, passer sur OpenJDK ou autre implique aussi de ne plus avoir une société commerciale derrière, connu qui plus est.
.Net serait le grand gagnant de cette manœuvre.
Mais bon il y a quand même de forte chance que la fondation Apache récupère tout ça, un peu comme OpenOffice en son temps.
[^] # Re: microsoft
Posté par barmic . Évalué à 4.
RedHat ? IBM ?
Et groovy plus récemment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: microsoft
Posté par barmic . Évalué à 8.
L'écosystème est beaucoup beaucoup plus petit que celui de Java (alors que le langage est vraiment meilleur que java).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: microsoft
Posté par ckiller . Évalué à 3.
Ce n'est pas forcément un mal, on trouve quand même quasiment tout, mais en un seul exemplaire, il est vrai :)
[^] # Re: microsoft
Posté par YBoy360 (site web personnel) . Évalué à -1.
Java est largement plus populaire et c# une popularité qui commence à péricliter.
De plus il y a au moins 100 fois plus de projet libre en groovy, Scala, Java, que ce que représente JEE, plus .Net et tous les projets libre .Net.
# OpenJDK
Posté par NumOpen . Évalué à 0.
Une implémentation multiplateforme d'OpenJDK : https://www.azul.com/products/zulu/
[^] # Re: OpenJDK
Posté par totof2000 . Évalué à 5.
Sauf si j'ai mal compris, java EE, ce n'est pas qu'un JDK.
[^] # Re: OpenJDK
Posté par Xavier Poinsard . Évalué à 0.
Implémentation ou binaires certifiés ?
# sondage
Posté par Maclag . Évalué à 10.
Écrire ça un vendredi, mon pauvre ami…
Allez, je l'aide à le lancer:
C#
Erlang (rien à voir mais faut relancer les langages fonctionnels de temps en temps)
Ruby (parce que RoR c'était trop hype pour ne plus écrire Ruby partout à toutes les sauces)
COBOL, parce que si on y revient ça aura été le langage le plus pérenne de tous les temps
Voilà, c'était ma contribution drediesque!!
[^] # Re: sondage
Posté par totof2000 . Évalué à 4.
Pourquoi rien à voir ? Je pense qu'Erlang a tout à voir au contraire, et serait bien plus efficace que Java dans pas mal de cas.
[^] # Re: sondage
Posté par YBoy360 (site web personnel) . Évalué à -1.
Kotlin aussi, c'est quand même THE langage libre du moment.. Avec Go.
[^] # Re: sondage
Posté par CrEv (site web personnel) . Évalué à 5.
Mouai, Kotlin ça commence à avoir une certaine popularité dans le monde Java (en étant simplement un meilleur java, rien de magique non plus) ou dans le monde Android car il y a des libs intéressantes pour combler les lacunes du sdk mais en dehors de ce monde java personne n'en parle en fait… J'ai pas vu une seule personne dire "oué je vais écrire du kotlin pour le fun tellement ça a l'air cool" alors que la même chose en Go ou Rust c'est hyper fréquent.
[^] # Re: sondage
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
A l'inverse, je n'ai pas vu une seule personne dire ce projet critique, il faut le faire en Go ou Rust.
C'est peut être finalement le fond des critiques faites à java sur linuxfr: il n'est pas fun, car omniprésent en entreprise.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: sondage
Posté par CrEv (site web personnel) . Évalué à 3.
Pourtant pas mal de monde parie (utilise aujourd'hui je ne sais pas) sur Rust pour écrire du code un peu plus sûr.
Et des projets critiques (bon après on peut définir critique aussi) en Go j'ai l'impression qu'il y en a pas mal, surtout pas mal de services backend, d'outils, cli, etc.
Ce n'est pas parce qu'il est omniprésent en entreprise qu'il n'est pas fun, c'est parce que c'est un langage pauvre, pas très intéressant, assez verbeux. La JVM est pas mal par contre, ça marche bien, les perfs sont intéressantes.
Kotlin c'est sympa, mais ça montre juste ce que devrait être java en fait. Un peu comme quand Google sortait guava, guice, etc et que ça a fait un peu bouger l'ecosystème basé sur les libs apaches.
Le revers de la médaille pour kotlin (de mon point de vue) c'est que c'est juste java en mieux, mais pas assez pour me donner envie. Sauf dans le cas d'Android où je le testerais bien.
[^] # Re: sondage
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Go est plus pauvre que Java pourtant le geek de la rue le trouve plus fun.
Java en tant que langage pro se doit de maintenir une compatibilité avec l'existant pas comme les toy languages (Python c'est à toi que je pense), les fritures sont d'abord testés dans Scala, Kotlin & co puis introduite au compte goutte (lambda apparu avec Java 8 par exemple).
Je n'ai pas eu le temps de jouer avec, mais il y a aussi http://www.ceylon-lang.org/ qui compile à la fois pour la jvm, node.js ou les brouteurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: sondage
Posté par YBoy360 (site web personnel) . Évalué à 1.
c'est quoi cet argumentaire à 2 balles? j'ai l'impression que tu te la ramènes pour balancer des généralités, mais qu'en fait tu ne connais ni java, ni groovy, ni Kotlin, et encore moins Go…
On peut faire des projets fun en C, si on aime les compilateurs, les performances, le coté fun du langage n'a rien à faire la dedans, par contre avoir un contrôle total de la production du binaire EST fun.
Java est fun, si tu l'utilise vraiment. Java c'est d'abord la JVM, l'AOP, l'injection de dépendance, plein de logiciels libres, comme Eclipse ou Intellij, qui ne pourrait pas être programmé en PHP, ni en Python, ni en Javascript …
[^] # Re: sondage
Posté par totof2000 . Évalué à 1. Dernière modification le 14 juillet 2016 à 13:33.
Eclipse, c'est l'un des trucs qui me fait fuir Java. Pour Intellij, pas encore essayé, mais e devrais le faire sous peu.
[^] # Re: sondage
Posté par woffer 🐧 . Évalué à 5.
Je peux te dire que dans mon entreprise (grand telco français). L'équipe, dont je fais parti, développe une application critique basée sur une architecture microservices. Et un gros 1/3 des microservices est écrit en Go.
Et pour ma part, c'est un réel bonheur par rapport à Java/spring/spring boot/spring cloud.
Il y a beaucoup moins de tuning à faire, ça fonctionne beaucoup mieux "out of the box" (pas de pool de thread à configurer, consommation mémoire bien plus sobre, déploiement simplifié)
De plus, il y a pleins de fonctionnalités utilisables directement car disponibles sur l'os hôte (e.g. Upgrade d'un microservice sans aucune interruption de service via simple fork et passage du fd du socket au processus fils).
J'ai l'impression de ne pas vivre dans un environnement aseptisé imposé par la jvm, je peux donc facilement tirer avantages des fonctionnalités proposées de l'os sous-jacent (i.e. GNU/Linux pour ma part).
# Fuyez Oracle a tout prix
Posté par rakoo (site web personnel) . Évalué à 10.
Petite correction:
Il ne faut pas se tromper de cible, le gros problème dans l'histoire c'est bel et bien Oracle qui, comme a son habitude, casse volontairement les pieds de tout le monde juste pour se faire plus d'oseille. Non pas que j'ai un problème avec l'oseille ou les gens qu'y s'en font, mais on a justement la un projet théoriquement libre mais qui en pratique se comporte comme un système propriétaire.
Et pour ceux qui doutent encore, Oracle n'en est pas a son coup d'essai. Loin de la, on se souvient de l'historique d'OpenSolaris qui a du être forké, d'OpenOffice qui a été lâchement abandonné, du créateur de MySQL qui a préféré forker MySQL que de le laisser dans les mains d'Oracle. Java EE n'est qu'un bullet point dans la liste des projets qu'Oracle tue sans laisser la communauté prendre les commandes.
[^] # Re: Fuyez Oracle a tout prix
Posté par barmic . Évalué à 4.
Je ne suis pas d'accord. Pivotal a lâché groovy l'an dernier. Scala n'est plus géré par TypeSafe pour justement ne plus être gérér par une seule entité commerciale, mais par des universitaires/une fondation. C'est nettement plus saint.
Après Oracle a clairement acheté Sun pour voir tout ce qu'il pouvait se faire comme brouzoufs et se rend compte qu'il y a une série de truc où ce n'est pas aussi simple que ce qu'ils imaginaient.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Fuyez Oracle a tout prix
Posté par ʭ ☯ . Évalué à 8.
saint? parler d'Oracle vous rend fort religieux chers geeks… cachez ce "sain" que je ne saurais voir!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Fuyez Oracle a tout prix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Ohé, les tueurs, à la balle et au couteau, tuez vite !
[^] # Re: Fuyez Oracle a tout prix
Posté par reynum (site web personnel) . Évalué à -6.
Il y a des limites.
Je suis persuadé que tu aurais un problème avec les gens qui font de l'oseille en louant des enfants de 1 ans à des pervers.
Ou alors alors peut être aurais tu un problème avec des gens gagnant 400 fois plus d'oseille que ceux qui travaille pour lui.
kentoc'h mervel eget bezan saotred
[^] # Re: Fuyez Oracle a tout prix
Posté par Dabowl_75 . Évalué à 3.
Pour avoir subi des audit d'oracle et essayer de s'intéresser un tant soit peu au licensing, un seul mot : racket
Je ne peux donc qu'abonder en ton sens.
Tout est fait pour passer à la caisse et le flou est entretenu pour ne pas t'avertir que tu vas droit au piège.
En quand l'audit passe, ça fait mal au c…
il faut fuir ces technos au plus vite.
Mais cela implique aussi de se doter de compétences en interne, et surtout de ne pas le faire tout seul.
Je pense que bon nombre de DSI feraient mieux d'y voir clair dans le jeu d'oracle.
[^] # Re: Fuyez Oracle a tout prix
Posté par Kerro . Évalué à 2.
Le pépin est qu'il y a beaucoup d'éditeurs incompétents qui ne savent s'interfacer qu'avec Oracle.
J'ai vu ça à plusieurs endroits. Alors bien sûr le prétexte donné par les éditeurs est qu'Oracle est bien plus puissant… pour faire tourner 30 postes clients, sans aucune réplication, sans rien de spécial. Et si possible avec uniquement le paramétrage par défaut tellement leurs techniciens/développeurs n'ont jamais pris le temps d'étudier la question (ou n'ont jamais pu car l'éditeur s'en fiche).
J'ai même du Oracle pour une application monoposte (gestion de cimetière). Mais là on peut utiliser une version gratuite. Ça reste tout de même hyper lourd à gérer.
# Faut étudier un peut l'histoire pour éviter de refaire les mêmes erreurs
Posté par Wawet76 . Évalué à 2.
Coopérer avec la communauté ou lui transférer la propriété, comme pour OpenOffice.org (Libre Office), MySQL (MariaDB), Hudson (Jenkins) et tous les autres trucs libres que faisait Sun.
[^] # Re: Faut étudier un peut l'histoire pour éviter de refaire les mêmes erreurs
Posté par mickabouille . Évalué à 3.
Pour Ooo et Hudson, ils les ont bien transférés à la communauté. Mais pas avant de les avoir tués.
[^] # Re: Faut étudier un peut l'histoire pour éviter de refaire les mêmes erreurs
Posté par Wawet76 . Évalué à 4.
Surtout, après que les forks "hostiles" aient pris le dessus.
# Actu
Posté par barmic . Évalué à 10.
L'info dur journal est légèrement datée. Oracle a déjà répondu : http://www.developpez.com/actu/101010/Oracle-brise-le-silence-et-rassure-au-sujet-de-Java-EE-la-firme-pourrait-devoiler-un-nouveau-plan-pour-la-plateforme-a-la-JavaOne-en-septembre/
et un peu avant c'est RH et IBM qui annonçaient prendre vouloir prendre en main la chose : http://www.developpez.com/actu/100909/Des-partisans-de-Java-EE-soutenus-par-Red-Hat-et-IBM-decident-de-poursuivre-leur-propre-developpement-de-la-plateforme-independamment-d-Oracle/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Enfin !!
Posté par reynum (site web personnel) . Évalué à 10.
Rhaaa depuis le temps que j'attends que ce chateau de carte incompréhensiblement populaire qu'est Java se casse la geule.
Quelle belle journée ♫ la la lala ♫
kentoc'h mervel eget bezan saotred
[^] # Re: Enfin !!
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Jaloux va!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Go ?
Posté par Julienng . Évalué à 1.
Est-ce que le go ne serait pas une alternative viable ? Il manque surement encore de librairie sur certains points, mais semble vraiment solide pour construire des applications robustes. En tout cas, j'en entends parler de plus en plus.
Qu'en est-il du scala ? Il permettrait de changer de techno en gardant le code métier du projet.
[^] # Re: Go ?
Posté par wilk . Évalué à 9.
Le monsieur te dit qu'il veut quelque chose de sérieux. Sérieux ça veut dire un minimum compliqué et pénible sinon c'est pas du jeu. Donc Go est hors jeu. Où plutôt Go est un jeu.
[^] # Re: Go ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Go est lent et n'a pas de généricité.
Scala est très lié à l'écosystème Java donc Oracle est toujours dans le coin :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go ?
Posté par Julienng . Évalué à 2.
Tu peux développer les points sur le go s'il te plaît ? Sur quel point est-il lent ?
[^] # Re: Go ?
Posté par André Rodier . Évalué à 7.
Peut être que le monsieur voulait faire de l'humour avec un mauvais je de mot.
[^] # Re: Go ?
Posté par CrEv (site web personnel) . Évalué à 7.
L'espace d'un instant j'ai cru que tu présentais des arguments contre Go.
[^] # Re: Go ?
Posté par Aluminium95 . Évalué à 2.
Par curiosité, quel est le reproche fait à la généricité de Java ? Je crois comprendre que cela permet d'ajouter du polymorphisme au niveau des types, ce qui est à priori une bonne chose.
Une rapide recherche peut mener sur un article qui explique que les « generics » ne sont pas nécessaires en Go, mais ses arguments sont peu convaincants. La première solution proposée est assez amusante
Qui revient exactement à utiliser des fonctions non-polymorphes, et faire ensuite à chaque appel un dispatch pour savoir quelle implémentation utiliser.
[^] # Re: Go ?
Posté par CrEv (site web personnel) . Évalué à 4.
Rien de spécial, je pense juste que ce n'est pas un argument contre Go :-)
[^] # Re: Go ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu aimes faire des casts et perdre l'avantage du typage statique?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go ?
Posté par El Titi . Évalué à 0.
Le typage statique est un avantage ?
[^] # Re: Go ?
Posté par nlhss (site web personnel) . Évalué à 3.
Évidemment :)
C'est même un très gros avantage du point de vue génie logiciel.
[^] # Re: Go ?
Posté par El Titi . Évalué à 3.
Quels arguments !
Parce qu'un troll en vaut un autre.
La programmation par contrat est aussi un avantage du point de vue génie logiciel, l'inférence de type,
les test unitaires, …
Je vois aussi assez bien les inconvénients du typage statique.
Bref beaucoup de gratuité dans ces affirmations.
[^] # Re: Go ?
Posté par nlhss (site web personnel) . Évalué à 2.
J'ai avancé un argument mais je pense qu'il est bon. Le typage statique est une sécurité pour des très gros projets. Ses inconvénients sont ses forces si tu vois ce que je veux dire. Bon je pense qu'il faut essayer pour être convaincu de l'intérêt du typage statique.
[^] # Re: Go ?
Posté par El Titi . Évalué à 4.
Je pense qu'il faut l'utiliser pour être convaincu de s'en passer lorsqu'on en a la possibilité.
C'est pourquoi aussi, ce qui fait la richesse de l'écosystème java, c'est avant tout sa JVM qui permet de composer avec différents langage selon ses besoins.
Quel bonheur de pouvoir écrire ses TUs avec du Groovy et du Spock ( https://github.com/spockframework/spock ) tout en garantissant la qualité de ton code de prod au lieu de se taper des infâmes combinaison de JUnit, Mockito, AssertJ JUnitParams & Co
Quel bonheur de builder et deployer son produit avec du gradle plutôt que d'en passer par du XML et du Java.
Quel bonheur d'écrire du code de glue dans un langage dynamique tout en appelant directement des classes implémentées en Java
Quel bonheur de prototyper en Clojure …
C'est pour ça que le vilain troll lancé par le posteur du journal est mort-né et qu'il faut l'élever avec amour pour qu'il prenne un tant soit peu son envol.
Il n'y a que .NET qui puisse offrir la même chose à l'heure actuelle et l'ouverture qui se met en place est à mon sens une
menaceopportunité bien plus réelle de détrôner Java que les soubresauts d'Oracle.[^] # Re: Go ?
Posté par wilk . Évalué à 8.
Je pense que le problème vient du fait qu'on résume le problème aux "erreurs de type". Hors j'ai toujours remarqué qu'en Python j'avais vraiment très peu d'erreur de type à l'exécution, du coup je ne comprenais pas trop d'où venait cette phobie.
Le typage statique ça n'est pas qu'une vérification de sécurité avant exécution, c'est surtout une aide à la saisie, à la refactorisation, à la documentation etc.
Je me suis amusé à compter en Python le nombre d'erreurs que je faisais qui auraient été détectées à la saisie en Go (j'utilise vim + vim-go), c'est impressionnant ! Mais je ne m'en rendait pas compte car ce sont des erreurs qui sont très vite détectées (F5 ou test unitaire) et faciles à corriger. De même pour le temps passé à jongler avec la documentation, rien d'impossible ni bloquant, mais juste plus long.
Donc je confirme, il faut essayer !
ps: je sais qu'il existe des éditeurs Python qui aident plus ou moins, mais c'est beaucoup plus lourd, moins sûr et très limité.
[^] # Re: Go ?
Posté par Aluminium95 . Évalué à 5.
Avoir un système de type permet aussi de renforcer certains invariants du programme quand même.
Un exemple pas forcément pertinent : en python, quand je voulais faire des arbres rapidement, j'utilisais des dictionnaires. La raison principale était qu'il n'y avait pas besoin de définir de classes, que je pouvais ajouter des attributs très facilement aux noeuds (puisqu'ils étaient des dictionnaires) et la sérialisation/dé-sérialisation était facile.
Le problème, c'est qu'en regardant le code, il n'y a aucun moyen de savoir quels champs étaient obligatoires, quelle était la structure générale, ou tout simplement si les informations ajoutées sur les noeuds étaient préservées par les fonctions qui traitaient les arbres (par chance c'était le cas). C'était génial pour faire du développement rapide, mais par la suite cela ne faisait pas « propre » (et c'était très dur de relire le code pour ajouter une fonctionnalité).
[^] # Re: Go ?
Posté par flan (site web personnel) . Évalué à 5.
De mon côté, j'utilise PyCharm avec des annotations pour l'aider encore plus à détecter les types. J'utilise parfois la souplesse du typage dynamique, mais de façon très ponctuelle (parfois ça aide bien !). Au final, je ne vois pas tellement de différences entre un langage fortement typé et du Python, et le refactoring se passe très bien.
Je préférerais avoir un vrai système de typage fort, mais ça ne me gêne pas plus que ça.
[^] # Re: Go ?
Posté par Michaël (site web personnel) . Évalué à 2.
Oui et le coût de refactorisation dirige le coût de maintenance du logiciel après conception.
Très vite est ici assez faux dans mon expérience. Parfois à l'exécution tu ne trouves une erreur qu'après des heures de calcul ou bien dans des conditions rares si les branchements de code sont touffus… Dans mon expérience le typage statique (OCaml) dispense d'écrire un grand nombre de tests unitaires – sans rien perdre de la maintenabilité!
[^] # Re: Go ?
Posté par lasher . Évalué à 5.
Le typage statique ne suffit pas. Dans le cas d'OCaml (ou même C++, si tu respectes les règles et que tu ne fais pas des transtypages barbares style C) tu as non seulement un typage statique, mais surtout un typage fort. Je ne pense pas que ton expérience avec OCaml serait la même si l'un de ces deux aspects n'était pas présent.
Un exemple pour illustrer : le langage C a un typage statique. Techniquement on peut dire que le typage est fort (tous les transtypages ne sont pas autorisés implicitement), mais il est malgré tout extrêmement permissif pour stocker une valeur d'un type T1 dans une variable de type T2. N'importe quel développeur un peu expérimenté te dira qu'il faut utiliser ton compilateur de façon à ce qu'il ait les warnings au maximum, si possible qu'il considère les warnings comme des erreurs, etc., car le langage lui-même n'impose pas cela, et donc il faut se reposer sur le compilateur pour ajouter ces fonctionnalités.
[^] # Re: Go ?
Posté par totof2000 . Évalué à 0.
Je suis convaincu que dans la plupart des cas, le typage statique ne sert à rien vu qu'on a inventé un tas de trucs pour se débarasser de ses inconvénients. Je suis même convaincu qu'il apporte plus d'inconvénients que d'avantages dans beaucoup de cas. Dans les cas ou on a besoin d'une telle sécurité, il y a un langage assez bien foutu pour ça mais que pas grand monde utilise, ça s'appelle Ada.
[^] # Re: Go ?
Posté par CrEv (site web personnel) . Évalué à 4.
Et c'est pas pour rien que pas grand monde l'utilise ;-)
Je trouve ça super cool, avec spark on arrive a des trucs vraiment bien, mais au pris d'une lourdeur et d'une verbosité inimaginable !
[^] # Re: Go ?
Posté par totof2000 . Évalué à 3.
C'est marant, c'est exactement l'impression que j'ai avec Java ;)
[^] # Re: Go ?
Posté par CrEv (site web personnel) . Évalué à 3.
Ben dans ce cas je te conseille de tester Ada/Spark pour de vrai alors, parce qu'à côté Java c'est aussi verbeux qu'un uniline perl.
[^] # Re: Go ?
Posté par Aluminium95 . Évalué à 6.
Je suis curieux, quelles sont les alternatives dont tu parles ? L'analyse statique du code ?
Là encore je suis curieux, est-ce une question de verbosité, de puissance d'expression, de flemme (ne pas avoir à se demander ce qu'on manipule) ?
[^] # Re: Go ?
Posté par Michaël (site web personnel) . Évalué à 2.
Tu peux développer?
Le dernier programme que j'ai écrit en OCaml fait 5000 lignes, il a déjà des dizaines milliers d'heures de production derrière lui sur des centaines de machines, et pendant la phase de tests j'ai trouvé un unique bug, et depuis le lancement en production zéro. Pour moi les avantages sont évidents. :) Mais il serait faux d'attribuer cela uniquement au typage statique, qui est aussi un indicateur pour des langages évolués, fonctionnels, et une communauté qui produit des bibliothèques de qualité légèrement supérieure à ce qu'on peut trouver dans des communautés plus larges. J'ai travaillé trois mois dans un projet Python basé sur une bibliothèque GIS toute pourrie, j'en garde un assez mauvais souvenir. :)
[^] # Re: Go ?
Posté par Aluminium95 . Évalué à 6.
Tout dépend du système de type, mais un système statique peut se permettre d'oublier les types à la compilation (pas de checks à runtime) alors qu'un système dynamique doit conserver et vérifier les types durant l'exécution du programme. Cela apporte potentiellement une meilleure performance du programme.
L'argument principal en faveur du typage statique étant toutefois qu'un système de type permet de détecter des classes d'erreurs à la compilation en rendant les mauvais programmes impossibles à écrire.
C'est l'expressivité du système de type qui détermine sa capacité à capturer des mauvais comportements. Toutefois il faut limiter cette expressivité pour être capable d'assigner un type à une expression en un temps raisonnable.
Un système de type dynamique n'assure rien à la compilation, donc par construction on remplace la notion d'état non représentable en erreur (spécifique) à l'exécution. Cela permet de ne pas se soucier des types avant de lancer le programme, mais en contrepartie, il faut se convaincre que tout marche comme on s'y attend (ce qui devient dur sur de gros programmes).
Une petite remarque : les garanties d'un système de types sont à modérer, car on peut faire des conversions non-sûres dans la majorité des langages. C'est le cas de C avec les casts, mais aussi d'ocaml avec
Obj.magic.Pour moi un système de type statique fort est un avantage certain.
[^] # Re: Go ?
Posté par nlhss (site web personnel) . Évalué à 1.
Oui, je suis d'accord. On peut faire des casts aussi en java mais en règle générale, il vaut mieux éviter. Si on veut du code générique, mieux vaut éviter les cast de toutes façons.
[^] # Re: Go ?
Posté par barmic . Évalué à 7.
C'est marrant car pour moi go est l'exact inverse de Java. Java est un langage haut niveau qui permet de faire des choses assez bas niveau alors que j'ai l'impression que go est un langage de bas niveau qui permet de faire des choses d'assez haut niveau.
Quoi qu'il en soit, il lui manque un écosystème pour pouvoir entrer dans la course (on parle de la plateforme JavaEE pas du langage java).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Go ?
Posté par Firwen (site web personnel) . Évalué à 5.
Go a déjà un écosystème. Je dirai même qu’il a un écosystème étonnement conséquent compare a la popularité du langage.
La seul différence est que écosystème de go n'est pas centralisé comme EE, mais se base sur une des libraires indépendantes github/got-get.
Tu as déja tout ce qu'il faut en go pour faire du REST, du messaging, du rendu dynamique, de l'ORM, du parsing, etc, etc…
[^] # Re: Go ?
Posté par barmic . Évalué à 4.
Je n'ai pas la sensation que tout cela soit vraiment mature et le fait que la gestion des dépendances, elle, ne l'ai clairement pas fait que je suis assez frileux pour faire tout ça en go.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Go ?
Posté par CrEv (site web personnel) . Évalué à 4.
Qu'est ce qui n'est pas mature ? Faire du REST en Go par exemple ? Ça veut dire quoi mature ?
Pour la gestion des dépendances, je ne dirais pas que c'est pas mature. C'est sur que c'est loin de maven, mais c'est plutôt une bonne chose :-D
Franchement il suffit juste d'essayer. Genre durant les 6 mois qui viennent apprenez Go, les 6 mois suivant Clojure, ensuite Rust, puis …
C'est le meilleur moyen de voir ce qui est mature ou non, productif ou non, rapide ou non, et d'ensuite pouvoir faire des choix qui dépassent la techno qu'on maitrise et les dires des autres.
[^] # Re: Go ?
Posté par barmic . Évalué à 6.
Bonne question et ici j'en parle dans le sens, on commence à converger vers une solution/une API relativement pérenne.
Aujourd'hui les solutions que j'ai essayé en go sont, je trouve, assez bricolées. Accéder à des paramètres dans l'URL, dans les entêtes HTTP, dans le chemin,… n'est pas très agréable on a pas d'abstraction qui permet de passer un paramètre de l'un à l'autre, d'avoir un routeur qui se base sur des patterns. Après la gestion d'erreur n'est pas agréable, mais je pense que ça vient du fait que je ne suis pas encore assez familiarisé avec Go.
Ça tombe bien c'est ce que je fais (Go actuellement) et je donne mon impression (qui n'a valeur que de mon avis). Après Clojure et Rust ne me font pas envie, j'ai plus envie de jouer avec Scala par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# migre
Posté par CrEv (site web personnel) . Évalué à 1.
Heu, rien et tant mieux. Parfois juste dropper en ayant appris le métier et réécrire mieux c'est bien. Ha oui par contre il faut un dicaÿdeur qui n'ait pas fait intervenir des SSII à tout va avec un mega turnover pendant des années et aucune capitalisation (à moins qu'un amas de bug, fix et erreurs soient une capitalisation…)
Ben tout ce que tu veux. Aussi bien python que nodejs, ruby ou php, clojure ou lfe. Toutes ces technos sont tout à fait capable de gérer des applications complexes, riches, scalables sans problème. Aujourd'hui (mon petit doigt me dit qu'avant aussi en fait…) les problèmes pour gérer des applis riches en fonctionnalités et scalables se résolvent par de l'architecture, aussi bien côté code qu'infra.
Bref, si JavaEE baissait vraiment de régime, certes ça me ferait sourire mais au fond ça ne changerait tellement rien sur les app cools qu'on développe aujourd'hui.
[^] # Re: migre
Posté par totof2000 . Évalué à 1.
Jusq'à riche, je suis d'accord avec toi. Pour la scalabilité, Python (et probablement ruby et PHP) sont à la ramasse au bout d'un moment. Pour de la scalabilité, si je pouvais, je choisirais Erlang.
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 10.
-_-'
Ha, on est toujours dans le troll ? Nan parce qu'on est samedi, mais je sais plus en fait.
Scaler, dans la grande majorité des cas, n'est absolument pas un problème de langage, runtime, vm.
Scaler aujourd'hui c'est de l'archi, tout existe pour que ça scale. Allez, je prend des exemples réels. J'ai une app Rails dont une grosse partie de son temps de traitement est dédié à manipuler des images et faire des vidéos. Ha c'est sur que de base ça scale pas beaucoup. Ok, je peux viser le scale vertical, prévoir une plus grosse machine qui va utiliser imagemagick et qui va être plus performant. Ou alors je sort chaque brique qui pose problème et je résous chaque problème indépendamment. Générer des miniatures, cropper des images ? J'ai 1000 Lambda chez Amazon qui n'attendent que ça. Le jour où attendre 1.5s pour générer simultanément 1000 traitements d'images (une image source, 3 images en sortie) j'en demanderai plus à Amazon, mais j'ai de la marge pour le moment… Ha oui, c'est du js. Je dois encoder des vidéos. J'ai un service Go couplé à de l'elastic transcoder. Je dois scaler ? Mon service Go est totalement stateless, je peux en déployer absolument autant que je veux pour réduire l'attente si j'ai besoin.
Mon app pourrait être en ruby, en python, en java, en dotnet, en brainfuck, ça ne change absolument rien niveau scalabilité. Elle sert à faire qq calculs et répondre aux demandes front. Tous les gros traitements sont séparés dans des unités qui scales chacune de manière appropriée. Et bien évidemment mon app rails est en cluster derrière un load balancer. Bref la ramasse elle est où ?
[^] # Re: migre
Posté par totof2000 . Évalué à 3.
Certes mais la scalabilité est plus facile avec certaines techno qu'avec d'autres (c'est pour ça que je parle d'Erlang qui a été conçu à la base pour permettre facilement la scalabilité horizontale, contrairement à Python, ou Java pour lesquels la scalabilité horizontale n'est pas "native").
[^] # Re: migre
Posté par rakoo (site web personnel) . Évalué à 1.
Oui, c'est sur, si tu veux que la totalité de ton infrastructure soit écrite dans un seul et unique langage, Erlang est probablement la réponse. Sauf que justement il n'y a pas besoin de se contenter d'un seul et unique langage, si tu veux scaler tu dois jouer sur l'architecture de ton système. Il faut voir les microservices comme des librairies, avec l'avantage que tu peux les utiliser depuis n'importe quel langage.
[^] # Re: migre
Posté par groumly . Évalué à 10.
Bon, je vais me lâcher un peu, ca tombe sur toi, le prend pas personnellement, mais fallait pas lâcher "les microservices c'est d'la balle parce que tu peux utiliser le langage que tu veux" devant moi ce soir.
En pratique si tu veux ou doit vraiment scaler, t'as une palanquée d'utilisateurs, t'as aussi une palanquée d'ingénieurs et d'équipes différentes.
Et la t'as 2 choix: chacun fait fait fait, c'qu'il lui plait plait plait, et tu gâches 30% de tes ingénieurs a réinventer la roue (et vas y que la lib cliente pour le service discovery est maintenu dans 5 langages, et pareil pour le logging/monitoring, et les roles puppet/chef, et les quarante douze docker images différentes, et les inits scripts etc. Ah, et je parle pas des lib clients pour tes 150 microservices, hein, 8 versions différentes en 5 languages (parce que les nodeux on pas réussi a se mettre d'accord la librairie de promises a utiliser, et ya bob qui ne jure que par guice, spring c'est de la merde, alors il a forke aussi)).
Et quand un service pete, personne d'autre que sont auteur n'est capable de le debugger/reparer et tu te retrouves comme un con a devoir pager un mec a moitié bourre a 3 heures du mat' pour réparer le bordel.
Mais bon, le service est écrit en rust, c'est super cool, mais ya pas de profiler, alors on saura jamais pourquoi la machine a commence a bouffer 100% du cpu un beau matin, mais bon, on a tue la task dans mesos et relancer, et maintenant c'est bon, alors c'est cool?
Tout ca parce que chaque ingénieur est un petit flocon de neige si unique, et si important qu'il doit faire les choses absolument a sa façon sinon il trépigne des pieds et arrête de respirer. Putain de millenials, un coup de pied au cul et au lit sans dessert, voila ce qu'ils méritent.
Et ca c'est du vécu (meme le coup du le polonais bourre qui nous a remit un service en marche a 2 heures du mat en rentrant du bar), j'invente rien.
Standardiser sur un petit set de technos, c'est de l'hygiene de base quand t'as une taille un tant soit peu conséquente (on va dire 100+ ingenieurs). Et choisir des technos un minimum mature, c'est de l'hygiène de base aussi.
Le but de l'informatique c'est d'automatiser les taches a large échelle. cookie cutter, cookie cutter, cookie cutter. C'est vachement moins bandant que de se tripatouiller avec des microservices tous snowflaké a un techno particulière (ou la tendance du moment), mais c'est pas grave, on va se faire du blé, et avec ce blé on peut s'acheter un truc qui fait vraiment bander.
Disons que c'est un peu toujours le meme problème. $NEW_METHODOLOGY débarque accompagne de $NEW_LANGUAGE ou $NEW_FRAMEWORK et $HIPSTER_ENGINEER saute dessus en promettant que ca va faire resoudre tous les probemes du monde, y compris ceux qu'on a pas.
Sur le papier, ca a l'air sympa, en pratique ya de sérieux problèmes de passage a l'échelle, comme toujours, mais on les connait pas (encore), alors on s'en fout.
Au final, la plupart des vrais problèmes de fond sont humain/communication/organisationnel, les autres sont en general pas si dur que ca a résoudre avec qq ingénieurs qui savent ce qu'ils font, qu'importe la methode.
Et ca loupe pas, on passe des mois a refaire des trucs pour zero resultat, tout ca parce qu'un connard irresponsable a vendu de la poudre de perlimpinpin a des managers incompetents qui comprennent pas les problème. Au final? retour a la case depart, on a toujours des problèmes, ils sont juste un peu differents de ceux qu'on avait a la base.
Potentiellement, on peut scaler 20x, mais en fait, on le saura jamais, parce que tout ce temps passer a réécrire le backend, il a pas été passe a bosser sur le produit.
Promis mec, cette fois ci, ce langage/methodologie, c'est la bonne, ca va tout changer. On va tout révolutionner et scaler 20x cette fois.
Serieux, on dirait des héroïnomanes en quete d'un dernier fix.
</rant>
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: migre
Posté par barmic . Évalué à 3.
Les microservices peuvent être vu comme une évolution sexy du SOA. Je suis d'accord avec toi (c'est très très compliqué pour un gain souvent inutile, c'est la mode d'aujourd'hui,…).
Mais je pense qu'on peut toujours tirer des bonnes idées/techno de ces choses là. Netflix, LE monsieur microservice, a développé des bibliothèques libres très sympas (je pense par exemple à feign).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 12 juillet 2016 à 12:34.
Et plus encore avec une petite équipe: j'ai vu des cas extrêmes où il y a plus de plateformes de développement que d'ingénieurs…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: migre
Posté par barmic . Évalué à 3.
Ouai mais non. Je comprends tout à fait ce que tu veux dire et je suis certains que tu en fait un peu trop à fin de souligner ton propos, mais :
Mais bon je trouve la conversation totalement inutile. Ce qui donne de l'importance à JavaEE c'est son écosystème (de quoi faire du messaging, de l'accès aux base de données relationnel, du web, de la gestion de la sécurité, de la distribution, des services web REST et SOAP, etc).
De ce que je vois dans tous les autres langages chaque framework fais à sa sauce, sauf en python où il y a une tentative de standardiser des choses. Je ne sais pas à quel point ça fonctionne.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 6.
C'est un vrai exemple dont je parle, pas d'un truc exagéré pour souligner mon propos…
Même pas, les choix répondent à d'autres critères. Rails pour la productivité du framework et ruby, absolument pas pour une histoire de (non)performance. Go parce que c'est le fun, du js parce que j'avais pas envie de python et que la version java était carrément trop lente. Bref le langage (à part java) je m'en fiche côté perf :-)
Ha oui mais ça n'entre pas en compte ça. Si les clients, demandeurs ou décideurs veulent rester dans le passé qu'ils restent sous java ee même s'il n'évolue plus, ils seront bien ! Je donne des solutions qui scale, si les gens n'en veulent pas faut pas se plaindre derrière ;-)
Mouai, pas tant que ça par rapport à des serveurs hébergés en interne/infogérés avec les sys admin qui vont bien…
Mais en fait ce que tu décris c'est juste ce qu'on peut faire partout, non ? Ok, excepté SOAP car plus personne ne veut en faire.
C'est exactement là où il faut s'élever d'un cran. Langage, framework c'est bien, mais il faut penser en terme de services et d'archi, quitte à mixer plusieurs technos, chacune adaptée. Et surtout pas viser une techno qui sait soit disant tout faire. Ça s'appelle juste une usine à gaz.
[^] # Re: migre
Posté par barmic . Évalué à 3.
Rah tu va me faire dire des choses que je n'aime pas faut que je fasse gaffe…
La performance n'est jamais un objectif en soit, mais il faut tout de même y faire attention. À plus bas niveau que l'architecture d'un projet le fait d'utiliser des algo en O(N) plutôt qu'en O(log(N)) par exemple est une erreur. Les 2 scales, on est à un grain plus précis, mais c'est ce qui différencie une partie de ton application que tu va devoir instancier 4 fois plutôt que 2.
Justement la perf pourrie c'est le passé et c'est JavaEE qui t'oblige à avoir un modèle de thread ridiculement pourri et te dis qu'on s'en fou tu fou un répartiteur de charge et tu duplique tes serveurs inutilement là où avec un nodejs/vertx/ratpack, tu diminuerais fortement la pression là dessus.
Je n'en sais rien (et je m'en fou à vraie dire), la question c'est de le comparer. Faire du webservice REST aujourd'hui en GO de mon expérience (et de mon goût) c'est largement moins agréable que de le faire avec JAXRS. De même pour la version Spring que je trouve moins bien faite. À coté je n'aime pas du tout JPA que je fuis comme la peste.
Oui mais tu semble chercher à ignorer tous les effets de bord (je t'en veux pas tu troll ;)
Multiplier les techno, c'est multiplier la complexité de maintenance.
Multiplier les techno, c'est devoir se tenir sur tout ces environnements (tu subit les cassures de compatibilité/évolution/dépréciation de chacune de tes technos)
etc
C'est vraiment pas enviable surtout si les arguments sont « c'est fun » ou « j'ai pas envie de … ». Personnellement ça ne me donne pas envie de travailler avec, même si l'architecture est bonne et que chaque techno peu me plaire. Se la jouer « on fait du microservice donc on peut faire ce qu'on veut » je te le laisse volontiers.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 5.
Même pas, le vrai argument (que j'ai déjà dit) n'est pas là. Le vrai argument c'est "j'extrais chaque problème et je choisi la bonne solution pour résoudre ce problème". Parfois ça me fait changer de techno, parfois non, parfois je change pour en introduire une nouvelle à la marge et tester en prod ce que ça donne sur un élément non risqué.
Ce n'est pas une question de "faire ce qu'on veut" mais de faire ce qu'il faut pour chaque problème. Résoudre un problème de traitement d'images en parallèle ne se règle pas du tout de la même manière ni avec les mêmes outils que résoudre un problème de génération d'html avec des templates.
[^] # Re: migre
Posté par barmic . Évalué à 4.
Je n'ai fais que reprendre ce que tu as dis hein ?
Tu réponds sur pourquoi tu t'autorise à changer de langage moi j'ai repris les arguments que tu nous avancé pour choisir tel ou tel langage. C'est pas la même chose.
Mais ces choix sont plus compliqué que ça. Ce n'est pas une question de geek, dans le choix, la pérennité de la techno et la gestion de vos compétences sont vraiment à prendre en compte.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 1.
Pas vraiment non, tu extrais bien juste ce que tu veux mais pas de prob, c'est le jeux ma pauv' Lucette ;-)
Clairement non, je ne dis pas que je peux faire ce que je veux je dis que l'isolation fournie par des services me permet de ne pas avoir des contraintes de plateforme/langage. Et donc je peux intégrer d'autres dimensions dans mes choix, ce que tu ne peux pas faire si tu reste monolithique. Et prendre une brique pour tester en prod un langage qui n'était pas dans la stack (Go, fun, toussa) est clairement un choix intéressant.
Bien sur que c'est plus compliqué, sauf que dans un cas tu n'as simplement pas de choix.
Gestion des compétences de quoi ? Pour écrire un service Go de quelques centaines de lignes ? Soyons sérieux, n'importe quel développeur devrait être en capacité de le faire. Pérennité de quoi ? Go et Javascript ? Je pense que c'est pas trop mal à ce niveau.
[^] # Re: migre
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Niveau pérennité oui, niveau compatibilité par contre…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 2.
Compatibilité avec quoi ?
[^] # Re: migre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Avec le passé!
La jvm et le jdk maintiennent une très bonne compatibilité avec les versions précédentes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 2.
C'est vrai, c'est aussi un de leur problème mais je le comprend.
Javascript est pas mal sur ce point, non ?
[^] # Re: migre
Posté par rakoo (site web personnel) . Évalué à 2. Dernière modification le 12 juillet 2016 à 10:50.
La retro-compatibilité est aussi un des buts de Go (voir cette page), ça devrait aller de ce cote la.
[^] # Re: migre
Posté par barmic . Évalué à 3.
Il faudra voir pour le langage, la bibliothèque standard et pour l'écosystème (→ toutes les bibliothèques hors du standard).
Mais s'ils y arrivent c'est génial.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par rakoo (site web personnel) . Évalué à 2.
Le langage et la bibliothèque standard resteront retro-compatibles, c'est dans le contrat (et c'est pas juste une promesse, les développeurs de Go eux-mêmes se rendent compte de certains problèmes avec les APIs telles qu'elles sont aujourd'hui, qui auraient pu être pensées un peu plus génériquement pour être plus facilement utilisables mais qu'ils ne peuvent pas casser)
Pour l'écosystème, par définition, c'est pas quelque chose garanti par une entité en particulier donc il faut y aller a la confiance… mais c'est la même chose dans les autres langages de toute façon.
[^] # Re: migre
Posté par barmic . Évalué à 4.
On est justement sur un journal sur JavaEE dont le principe est de proposer des API standards pour un maximum d'usage (je suis d'accord du coup c'est très limite sur la distinction bibliothèque standard/écosystème). Mais disons que la majorité des bibliothèques sont partiellement couverte (au moins fonctionnellement) par une JSR et l'objectif est d'agrandir continuellement cette couverture. Tu as évidement des bibliothèques qui ne respectent pas du tout JavaEE (comme jOOQ) et des bibliothèques qui font plus que le standard hibernate.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par barmic . Évalué à 3.
Bien sûr ! Et tout développeur un peu sérieux devrait écrire du code sans bug, jongler avec le procédural, l'objet et le fonctionnel, être fullstack, développer en BDD, maitriser une cinquante de langues (parce que bon le français, l'anglais, le mandarin, l'arabe et l'espagnol, c'est un peu limite), etc, etc
Dans la vraie vie, c'est pas le cas et augmenter la complexité de la maintenance de ton code, il faut que ce soit quelque chose de maitrisé et fait en connaissance de cause.
Il y avait un thread il y a quelques temps ici de gens qui comme toi (tu y avait peut être participé) prenaient de haut les développeurs qui avaient commis une faille (heartbleat ? gotofail ?…) et qui avaient pondu un code comme exemple de leur savoir faire. Bon il était bugué… :) Je vois pas à quoi ça sert de faire le fier à se croire excellent et à être élitiste. Ça pousse juste à faire n'importe quoi par excès de confiance (« non mais quelques centaines de go je sais faire », « mais il n'y a que les nuls qui tombent dans les pièges des langages », « apprendre un nouveau langage ? 1/2 journée maximum »,…).
Hors de leur bibliothèque standard ? En js il y a quelques trucs (comme jQuery) en go je ne sais pas.
Sincèrement tu semble être entrain de nous dérouler la planche publicitaire des microservices sans le moindre recul. J'ai beaucoup de retours bien moins glorieux sur des gens qui ont voulu s'y mettre et qui ont découvert que ça demande beaucoup de travail pour un gain très limité voir inexistant (ou tout juste potentiel).
Ça marche chez toi, c'est cool. Vous maitrisez tous je ne sais combien de langages/framework/bibliothèque, c'est parfait.
Mais de mon expérience c'est pas le cas de la majorité des développeurs que j'ai rencontré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par Sufflope (site web personnel) . Évalué à 4.
Je vais pas utiliser un framework web ou au moins une bibliothèque de routing, je sais faire des include ; je vais pas utiliser d'ORM/PDO je sais écrire des requêtes SQL et paf pastèque les injections.
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 3.
Ça va mieux ? Ça fait du bien ?
-_-'
Sérieux, soit j'ai vraiment écris de la merde soit tu as tout lu de travers.
A aucun moment je n'ai introduit la notion de microservices (c'est toi ici avec Se la jouer « on fait du microservice donc on peut faire ce qu'on veut » je te le laisse volontiers.) et l'app dont je parle n'est pas en microservices. Certaines briques sont extraites dans des services dédiés et ça, ça fait des années et des années que ça se fait. Ce n'est pas pour autant une archi à base de microservice. Mais extraire les parties qui posent problème c'est la base d'une archi web. C'est d'ailleurs ce que tu fais quand tu stock tes datas dans une base de donnée. Là c'est la même chose mais pour des unités de calcul, rien de magique là dedans, rien de microservicebullshit non plus.
Et franchement (oui je sais tu vas encore mal le prendre) faire un service Go de quelques centaines de lignes alors que tu sais écrire du Java/Ruby/PHP c'est vraiment dans le domaine du normal. C'est un peu le principe du développement. Personne ne demande à être hyper calé, ni à connaître sur le bout des doigts ce langage, cette plateforme. Par contre introduire des changements — genre langage — isolés, à la marge est une vrai méthode pour tester en condition réelle de nouvelles façon de faire, nouveaux langages, etc. Si ça ne marche pas il se passe quoi ? On passe une ou deux journées à réécrire en ruby et on aura appris déjà pas mal de choses. Et si ça marche on pourra augmenter la connaissance et l'utiliser plus la prochaine fois.
Le truc c'est que tu caricature à mort un discours qui était, je le rappel, de dire que c'est pas Java qui fait que ton appli va scaler mais ton design et qu'avec un bon design tu t'affranchis grandement des problématiques de langages, framework, plateforme ou autre.
Nan mais t'es sérieux ?
Oui je pense qu'un dev doit être en capacité d'apprendre d'autres langages, ne serait-ce que pour être meilleur dans son langage de prédilection. Ça ne veut pas dire que ça prend 1/2 journée, ni ne parle de nuls ou autre.
[^] # Re: migre
Posté par barmic . Évalué à 4.
Ce dont je suis tout à fait d'accord.
Je dis juste qu'il ne faut pas multiplier les techno n'importe comment (ce que tu semblais faire quand j'ai lu « Go parce que c'est le fun, du js parce que j'avais pas envie de python et que la version java était carrément trop lente. »). La maitrise de ses dépendances ça fait aussi partie du boulot d'architecture.
Parce que la notion de microservice c'est un nom à la mode pour parler de quelque chose qui se faisait déjà avant en plus poussé (comme tout ce qui est réactif).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 3.
Cool :-)
Ok, compris le prob. En fait la seule qu'on a introduite c'est Go. On est sur une app web, finalement Java et Python auraient été encore plus loin, alors que js on l'utilise déjà (ok non, coffee).
Toutafé.
D'ailleurs, là j'explique le résultat, dans les étapes c'est pas ça.
Pour l'histoire, au début une bonne partie de nos traitements (miniatures par ex) était dans notre app Rails (monolithique on peut dire). Puis quand ça a fait mal, plutôt que de chercher à scaler une app juste pour une portion très identifiable, on a sorti cette portion et on s'en est occupé à côté : changer de langage (ruby -> js) et de plateforme d'exécution (rails -> AWS Lambda).
C'est ainsi que ça devrait toujours être fait, il ne faut juste pas avoir peur de sortit des briques. Mais c'est différent que de vouloir absolument tout sortir et de ne plus être capable de gérer la communication. C'est un peu la même histoire que linux vs minix d'ailleurs :-D
[^] # Re: migre
Posté par ckyl . Évalué à 7.
Juste pour remettre 2€ dans le bastringue qui n'ira jamais nul part vu le sujet :)
Ça dépend de la taille de tes structures. Du O(N) qui fait marcher à fond le prefetch et le pipeline marche souvent mieux que du log(N) blindé d'accès non prévisibles et de branches aléatoires sur les tailles courantes de structures.
Typiquement une recherche linéaire explose une bissection jusqu'à quelques centaines d'éléments. C'est quoi le taille moyenne de tes structures ?
J'adore ces threads sans sujet ou chacun peu donner son avis sur n'importe quoi !
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 5.
C'est quand même la base pour répondre à un troll, non ? :-D
[^] # Re: migre
Posté par barmic . Évalué à 3.
C'était pour ne pas m'attarder là dessus, mais ce n'est pas toujours aussi simple (ou au contraire des fois c'est plus simple que ça).
Quand tu évalue la complexité algorithme, tu regarde le nombre de fois que tu fais une opération. Si cette opération coûte seulement quelques cycles d'horloge pas de problème. Quand elle nécessite un accès à ta base de données alors c'est une autre paire de manche. Et c'est quelque chose que j'ai rencontré l'an dernier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par lasher . Évalué à 5.
Je suis d'accord avec toi sur le principe, mais même avec une grosse structure de données, si on suppose un accès régulier (du genre le traitement examine toujours les mêmes champs de la structure), alors O(N) ou O(N log N) ne devraient différer qu'en termes de complexité non?
Ensuite, c'est sûr qu'après quelques itérations de ton algo en O(N log N) tu risques de te retrouver avec un jeu de données suffisamment petit pour tenir en cache, et là il peut être plus avantageux de passer à un algorithme en théorie moins performant du point de vue complexité, mais qui en pratique tire parti de l'architecture cible. Un bon exemple est le tri fusion, où on fait du diviser et régner jusqu'à atteindre un certain niveau de récursion, pour ensuite utiliser un tri rapide ou par insertion car l'algo a un meilleur comportement avec les caches (ne serait-ce que parce qu'ils trient sur place).
Mais lorsqu'on parle de comportement hors caches (communications inter-nœuds de calcul par ex), je ne vois pas vraiment de raison pour ne pas utiliser l'algo avec la complexité la plus basse, vu que les données devront être copiées sur le réseau de toute manière (je ne sais pas si je suis clair).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: migre
Posté par nlhss (site web personnel) . Évalué à 1.
La complexité n'est pas le seul facteur. Souvent un algo en log(N) prendra plus de mémoire, ou sera moins robuste/plus long à implémenter, ou encore en moyenne ce sera du O(log(N)) donc dans la plupart des cas satisfaisants.
Dans tous les cas les algos linéaires ne sont pas tellement des problèmes, ce sont plutôt les algos en O(n²) dont il faut se méfier.
[^] # Re: migre
Posté par lasher . Évalué à 2.
Alors ça j'aimerais avoir une source. :) Oui, il faut prendre en compte à la fois la complexité en espace et en temps, mais au contraire, mon expérience est qu'un algo en O(N log N) peut gagner en temps parce qu'il stocke plus d'état que son équivalent O(N).
Les histoires de robuste/plus long à implémenter, je ne vois pas trop ce que ça a à faire ici : je connais des algorithmes qui en théorie sont pires que d'autres en temps ET en espace, mais parce que les jeux de données pour lesquels ils sont utilisés dépassent rarement (voire jamais) une taille déterminée, la complexité n'entre pas en compte, et justement tout l'intérêt de cet algo est qu'il est plus simple à implémenter malgré son temps d'exécution asymptotique plus grand.
[^] # Re: migre
Posté par Aluminium95 . Évalué à 1.
Je suis peut-être fatigué, mais
O(N log N)c'est plus lent (asymptotiquement) queO(N)… Du coup je ne vois pas comment il peut « gagner du temps ».[^] # Re: migre
Posté par nlhss (site web personnel) . Évalué à 0. Dernière modification le 15 juillet 2016 à 12:15.
C'est une histoire de complexité asymptotique, de pire cas VS cas moyen VS cas favorable, etc.
Par exemple, sur un tableau déjà trié, un algo asymptotiquement en O(n2) peut être plus efficace qu'un algo en O(Nlog(N)) car ce dernier va faire des tas d'accès inutiles, voire même éventuellement déplacer des éléments alors que ce n'était pas nécessaire.
En gros le tri par insertion, malgré sa plus grande complexité que le quick sort, est plus efficace sur des ensembles déjà trié ou partiellement triés.
[^] # Re: migre
Posté par Aluminium95 . Évalué à 1.
Je répondais à
Du coup c'était sous entendu qu'il utilisait des « petites valeurs de N » ?
Enfin, dans les arguments je pense qu'il faut différencier les particularités du jeu de données (pire cas VS cas moyen VS meilleur cas) des optimisations faites par la machine (qui peuvent réellement fausser l'étude de complexité moyenne par exemple) comme l'utilisation de caches, prédictions de branches et autres.
[^] # Re: migre
Posté par lasher . Évalué à 2. Dernière modification le 18 juillet 2016 à 19:19.
EDIT: Oups. J'étais bien fatigué, mais ce message est aussi inutile…
[^] # Re: migre
Posté par barmic . Évalué à 4.
Comme dis plus tôt, la complexité indique comment se comporte un algo quand tu va augmenter la quantité de données en s'intéressant au nombre de fois que l'on exécute l'opération importante. Souvent on parle d'une opération qui est négligeable en temps d'exécution (une comparaison). Dans ces cas là OSEF. Si ton opération c'est une IO, là c'est important.
Je l'ai régulièrement vu…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par nlhss (site web personnel) . Évalué à 0.
Et tu finis avec un gros cluster de trucs totalement hétérogènes. N'oublie pas que la communication entre services est aussi coûteux du point de vue de la maintenance et de l'architecture. Tu avances un modèle « bazar » alors que Java permet de construire des applications complexes de manière nettement plus sûre et surtout dont les performances à l'exécution sont meilleures que nombre de langages de script.
[^] # Re: migre
Posté par El Titi . Évalué à 2.
Tu as raison, c'est pour ça que Java prend enfin le virage de la programmation réactive avec RxJava car il se fait poutrer par du Node à tire larigot.
C'est pour ça que vert.x essaie péniblement de décoller et qu'Oracle va se recentrer sur les microservices (cf. mon post un peu plus bas)
[^] # Re: migre
Posté par barmic . Évalué à 2.
Ouai alors les microservices en terme de bullshit ça se place à peu prêt au même niveau que les composants réutilisables, hein ?
C'est nécessaire dans des cas très particuliers que presque personne ici ne rencontrera jamais et ça demande surtout en plus de techno qui vont bien, d'avoir une organisation du travail et un management qui puisse gérer ça.
Alors ouai c'est hype, tu as pleins de conférence sur le sujet, mais IRL tu connais combien de développement :
Quand tu n'arrive plus à maintenir ton logiciel, généralement tu ne t'en sortira pas mieux avec des microservices.
Après j'adore Rx et Vertx (sachant que ces 2 là n'ont pas une goute de JavaEE dans leur code). Ils permettent de faire du développement réactif. C'est différent des microservices (disons que les microservices est une façon de faire de la programmation réactive ou par agent).
Note que Vertx a comme alternative ratpak ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par groumly . Évalué à 5.
Et ensuite, tu vas recevoir ta facture aws, et ton boss va te dire "ca va pas, faut que tu me coupes cette facture en deux", et tu vas te retrouver con.
L'avantage de ce genre d'approche, c'est l'élasticité. Des mecs comme Netflix voient leur traffic monter en flèche le soir et disparaître aussi vite en fin de soirée, alors forcément, ouais, ils ont un gros intérêt à avoir un infra qui grossit et maigrit à volonté.
Si t'as un traffic predictible et qui change pas radicalement en qq minutes, c'est pas forcément un bon calcul.
Si tu gères un gros traffic, pareil.
Bref, ça dépend.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: migre
Posté par CrEv (site web personnel) . Évalué à 3.
Même pas non, c'est bien moins cher que d'avoir des serveurs. Je ne dis pas par contre que ça marche partout et pour tout, je dis juste que dans notre cas c'est la bonne solution (avec des piques de plusieurs milliers de demandes par user dans un temps très court et rien pendant longtemps).
Bien entendu ça dépend. Mais ce que je veux montrer c'est qu'on ne peut pas juste penser en terme de framework/langage.
[^] # Re: migre
Posté par G.bleu (site web personnel) . Évalué à 4.
Python propulse Youtube, Dropbox, Hipchat et Reddit
PHP : Facebook et Wikipedia
Ruby : Heroku et Twitter
node.js : Paypal (qui remplace Java d'ailleurs)
T'es plus en 2005, les gens ont arrêté de croire que parce que y'a que java qui a une « édition entreprise » les autres technos sont des trucs pour gamins qui scale pas.
[^] # Re: migre
Posté par barmic . Évalué à 8.
Pas vraiment, non. Ils ont quitté PHP il y a longtemps. Ils ont toujours du code PHP, mais soit il est compilé en C++, soit il tourne sur HipHop. Une partie se fait réécrire en Hack.
Facebook est l'exemple même de celui qui a eu des déboire avec PHP (et qui contrairement à ce que dit crev1 ne pouvait pas contenter de multiplier les machines indéfiniment).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: migre
Posté par Elfir3 . Évalué à 4.
Il semble que twitter est passé de Ruby à la JVM justement. Sans doute pour des raisons de scalabilité.
Lire http://carlosbecker.com/posts/twitter-drops-ruby-bullshit/ qui donne une explication sympathique bien que non officielle.
[^] # Re: migre
Posté par wilk . Évalué à 3.
Dropbox utilise maintenant Rust et Go pour scaler.
Ca ne veut pas dire que Python soit un truc de gamin ni que Java soit la seule alternative, mais je crois qu'on constate tous que les problèmes d'échelles sont de plus souvent résolus en utilisant la techno qui va bien pour chaque problème donné.
[^] # Re: migre
Posté par G.bleu (site web personnel) . Évalué à 4.
Je répond à barmic, Elfir3 et wilk d'un coup : mon post cherchait à mettre en avant des projets qui ont eu une croissance monstrueuse et sans que leur technologie sous-jacente ne leur mette (trop) de batons dans les roues.
Une fois ces projets devenus les monstres qu'on connait, ils ont cherché à améliorer leur existant, l'optimiser faire des expérimentations. Bref occuper les ouatmilles ingénieurs surqualifiés qu'ils avaient embauché (genre twitter qui fait son framework Java à la place de J2E, Facebook qui fait Hack etc.). C'est dans ce context qu'ils ont réalisé les évolutions de leur stack de base.
Car soyons franc : si la définition de scalé est « être capable de gérer un service de la taille de Facebook out-of-the-box », alors aucune technologie ne scale !
# Fausse alerte
Posté par El Titi . Évalué à 4.
http://www.nextinpact.com/news/100588-oracle-veut-rassurer-developpement-java-ee-8-continue.htm
Il semble surtout qu'Oracle ait compris que l'avenir n'était plus au monolithe mais aux micro-services.
[^] # Re: Fausse alerte
Posté par wilk . Évalué à 3.
Du coup plus d'interopérabilité avec d'autres technos ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.