CrEv a écrit 4577 commentaires

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.

J'adore ces threads sans sujet ou chacun peu donner son avis sur n'importe quoi !

C'est quand même la base pour répondre à un troll, non ? :-D

mais que pas grand monde utilise, ça s'appelle Ada

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 !

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

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.

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.

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.

je suis certains que tu en fait un peu trop à fin de souligner ton propos

C'est un vrai exemple dont je parle, pas d'un truc exagéré pour souligner mon propos…

tu n'es pas entrain de dire que le langage n'est pas important tu dis que tu t'intéresse au langage uniquement dans les parties critiques (ce qui est très différent)

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 :-)

Tous les clients, demandeurs, décideurs n'ont pas un compte Amazon/Google/Azure leur permettant de faire tout et n'importe quoi

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 ;-)

Les prix de ces choses là est relativement important

Mouai, pas tant que ça par rapport à des serveurs hébergés en interne/infogérés avec les sys admin qui vont bien…

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).

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.

De ce que je vois dans tous les autres langages chaque framework fais à sa sauce

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.

Pour la scalabilité, Python (et probablement ruby et PHP) sont à la ramasse au bout d'un moment

-_-'

Ha, on est toujours dans le troll ? Nan parce qu'on est samedi, mais je sais plus en fait.

scalables se résolvent par de l'architecture, aussi bien côté code qu'infra

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ù ?

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.

quel est le reproche fait à la généricité de Java ?

Rien de spécial, je pense juste que ce n'est pas un argument contre Go :-)

Go n'a pas de généricité.

L'espace d'un instant j'ai cru que tu présentais des arguments contre Go.

pour un daicideur, quelles sont les alternatives à Java EE qui pourraient permettre de migrer leurs applis sans trop de problèmes ?

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…)

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).

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.

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)

J'ai pas compris, c'est un argument en faveur ou en défaveur de java ça ?

C'est toujours mieux : http://openui5.org/

Histoire de bien comprendre la remarque, un lien vers l'autre occurrence ?

Ben c'est autant intéressant si ce n'est plus que ce commentaire d'une ligne et quelques qui n'apporte lui aucune info, non ?

Je pense que c'est pour ça que RWD est présenté sous forme d'un lien wikipedia entre autre.

Ce qui me gène dans ce message, ce n'est pas la demande de précision sur le contexte (pourquoi en C ?), c'est de dire, illico, sans le connaitre, bah le perl aurait convenu

Mouai, ce n'est pas ce qui est dit, faut pas tout prendre de travers. Et d'ailleurs la réponse de Babelouest ne donne pas l'impression de l'avoir pris de la sorte.

Il n'est pas dit "bah le perl aurait convenu" il est dit "pour notre projet on utilise perl et c'est suffisant sur du petit matos" ce qui est en lien avec un point souvent présenté sur "pourquoi C" qui est de l'utiliser pour être proche du matos et donc meilleur en terme de perf.

Je pose la question parce je fais partie d'une équipe qui développe professionnellement un serveur domotique en Perl depuis plus de 5 ans, et jamais on a atteint les limites du hardware, bien plus faible qu'un Raspberry Pi. L'appli passe son temps à attendre des évènements.

Si tu veux un 80m² dans un centre de grande ville avec un bureau un jardin un garage pour 300€/mois, il va falloir redescendre sur terre

Sauf que ça il n'y a que toi qui le dit, à aucun moment je ne parle d'argent, juste de taille/usage.

Nan mais au fond je suis d'accord avec 30m2 c'est possible pour vivre, par contre ce n'est pas surdimensionné comme tu le dis dans ton premier message, c'est autant n'importe quoi que de dire que c'est un clapier.

Je pense que tu exagères quand même, ne serait-ce que dans l'oscillation entre "suffisant" et "surdimensionné". Dire que 30m2 est suffisant pour une personne, ok, surdimensionné faut pas déconner non plus.
Et de rajouter que c'est tellement variable en fonction de ce que tu fais / veut faire de ta vie chez toi (genre tu veux un bureau pour télétravail, un atelier, un endroit pour recevoir des amis, etc, à moins que tout ça soit que du luxe). Idem pour l'histoire de vivre à deux, il suffit que l'un des deux ait des horaires décalées pour que ce soit bien lourd.
Bref c'est triste de prendre des cas simples pour généraliser (sans pour autant défendre la formule de clapier pour 30m2, j'aurais quand même vu ça pour 9…)

Une voiture au ralenti ça ne fait pas de bruit.
Une moto au ralenti ça fait vibrer les murs.

Si tu ne veux pas discuter sérieusement tant pis pour toi, arrête juste de raconter n'importe quoi.
Des voitures qui font trembler les murs au ralenti (et qui font du bruit) ça existe, c'est pas un problème. Mais tu notera que j'évite de généraliser n'importe comment.
Certaines moto au ralenti peuvent faire vibrer les murs. Mais c'est pas parce que tu avais un voisin débile que généraliser sert à quelque chose.
Le jour où tu arrivera à faire trembler les murs avec la majorité des motos je veux bien que tu me montres. Que ce soit au ralenti ou en accélérant. Et oui, tout le monde n'a pas une harley ou un truc du genre qui tremble. Comme tout le monde n'a pas une dodge avec un moteur de 6-8l qui tremble.

A ma connaissance non, je ne crois pas que ça existe. Mais si c'était le cas j'apprécierais vraiment. Et au fond c'est agréable pour tout le monde, même dans une voiture c'est agréable. Du peu que j'ai roulé avec (une honda hybride) c'était très agréable à conduire et je veux bien la même chose sur ma moto (ben oui, c'est pas parce qu'on a une moto qu'on est forcément fermé à ce genre de choses).

ça fait un boucan vraiment infernal une moto.

Certaines moto ou certains conducteurs, faut pas généraliser non plus.
Et oui il y a des réglementations contre le bruit, ça n'empêchera jamais les cons.

Après des kékés qui vont faire les malins à faire chauffer leur moteur 10 minutes pour 5 minutes de trajet ça existe, en moto, en voiture, en ce que tu veux, le problème n'est pas l'engin mais le cerveau du kéké… (qui plus est ça ne sert pas à grand chose, à moins d'avoir un véhicule pas bien récent avec une marche à suivre bien précise).

Ha… Heu… Ok.
Et tu as une deadline ?
Parce que bon je rejoins pas mal les critiques déjà faites, même en sachant comment ça marche je n'y comprend rien (et le style graphique très blanc - fil de fer n'aide pas du tout).

qu'il te faudrait faire une BD bien plus longue dont les planches ici seraient parmi les dernières.

Je sais, mais c'est impossible.

J'ai du zaper un truc mais pourquoi ?