Reprise du message précédent :

 
Le null est pas tout à fait une question de type system en Java, mais même si on le considère comme tel, au lieu d'avoir un ensemble assez important d'erreurs de type au runtime, t'en as plus qu'un subset réduit (principalement les génériques si tu t'amuses à faire des trucs foireux). C'est toujours ça de moins.
 
Après à mon sens un des intérêts majeurs du typage fort et un minimum explicite, c'est que ça permet à ton tooling de faire des trucs un peu plus malins que de match des appels de méthode juste sur leur nom.

C'est bien le problème

Le problème c'est le ROI, après peut être que le java moderne a un ROI stratosphérique sa mère (je présume que les records & sealed interfaces ont amélioré les choses, même si apparemment t'as encore un fichier par type toplevel parce-que ???), ça fait 10 ans que j'en ai pas fait (et jamais j'en refait), mais mon XP de java (jusqu'à Java 6 je pense, ou ptet 5) c'est que l'overhead syntactique du langage te faisait payer énormément pour un retour minable (parce que le système de type est peu expressif). Et dans tous les cas t'as les exceptions qui viennent vomir dans ton aquarium.

Bof.

Un talk qui résonne un peu dans ce que tu dis  

https://www.youtube.com/watch?v=88_LUw1Wwe4

 
Je sais bien    
 

 
Le ROI s'est amélioré sensiblement depuis Java 8 et Java 11.
Après quand t'as goûté à des type systems plus expressifs c'est un peu limité oui. Mais aujourd'hui dans les codebase Java le problème c'est plutôt les gens qui stringly type absolument tout plutôt que le type system.
 

 
Je sais pas, y a encore quelque années je voyais des devs JS bosser j'avais l'impression qu'ils bossaient avec des cailloux et des bouts de bois.

 
il me semble avoir appris à un moment (peut etre pendant des cours de voile, ou en essayant de comprendre les vents sur le lac léman) que près des montagnes y'a des vents spéciaux qui descendent de la montagne par je sais plus quel effet, et que étant dans une vallée étroite, tu peux très bien avoir ce type de vent qui vient de nulle part ailleurs que du fait qu'il y ait une montagne devant toi.

Le foehn ?

 
 
Mon XP me dev me dit que Node + VSCode >>>>> Idea + Java perso (ne parlons pas d'éclipse ou netbeans )
 
Donc le tooling m'a pas l'air trop foiré meme en interprété.
 

 
Encore une fois consideres-tu ce tradeoff comme positif ?
 
Tu as Java, qui par exemple n'enleve pas le soucis des nulls, mais en corrige certains. Est-ce une balance a ton avantage ou pas ?
 
Moi perso en Java j'ai surtout vu des devs, pas forcément les plus mauvais d'ailleurs, bypassé toutes les sécus du langage parce que c'est chiant, du genre tester que ta string est null ou pas avant d'essayer de la substring, ou alors caster comme un gros porc et osef de la remonté d'exception. Par dessus Java reste plus lent a coder que disons PHP.
 
Donc le deal est-il encore sur la table dans ces cas la? Parce que ces cas la c'est plus la norme que l'exception. On a toujours une deadline ou faut aller vite et on prend des raccourcis foireux.
 
Meme rust il y a moyen d'y aller au ? et unwrap de partout et osef de comment ca se comporte.
 
 
 
Et ca c'est la premiere partie du soucis. A quel moment ca:
 

 
est le coeur de ton soucis ?
 
Navré mais ca c'est surtout toi qui aimerai avoir une journée plus cool, qui ne se pose pas la question de ce que cela implique de changer de language pour un plus strict, et du temps de l'ensemble (code + bug resolu). Au final tu verras que tu as une journée un peu moins chiante, mais du temps de perdu. Parce que le language t'a forcé a prendre en compte des non-problemes, via du cast systématique - par exemple. Et parfois meme t'a forcé a faire une erreur avec un cast foireux.
 
A moins que tu passes ta vie entiere a corriger des NoneType mais j'ai pas encore vue une équipe dédiée a ca nulle part
 
Et de toute facon ca ne corrige pas le coeur de l'ensemble du probleme: quand ca pete, la plupart du temps c'est quelque chose de compliqué, et qui dit compliqué, les tests n'ont jamais eu lieu sur cette partie, et le casting ne rentre pas la dedans la plupart du temps...
 
Donc une bonne partie de l'écosysteme moderne consiste j'ai bien l'impression a perdre du temps sur des choses intuiles, en ayant toujours autant de probleme a la fin, parce que les gens ne testent tout simplement pas ce qui devrait etre testé.
 
Pour donner une idée, je ne fais pas de tests U/intégration la ou je suis, mais si j'avais une équipe pour ca, mon premier test serait pas de savoir si l'endpoint fait ce qu'on lui demande, se serait:
  - si l'endpoint arrive a se démerder avec la moitié des services non disponibles (genre BDD ou API)
  - si la sécurité est assurée, pas de porte dérobée ou autre.
 
Si ca t'a bon, t'a fait la plupart des tests unitaires qui vraiment valent quelque chose. Les autres c'est de l'applicatif, et on peut toujours corriger l'applicatif si ca ne va pas.
 
 
Sur ce j'ai recu un nouveau synthé donc je vais disparaitre pour quelques jours, bonne journée/soirée a vous!

Je pense que c'est totalement faux.
 

J'espère que tu charges pas tout in-memory
 

Y'a d'autres façons de faire mais il faut être prudent.
 

C'est quoi le tooling pour toi ?  
Donne du concret car sinon je réponds juste mon xp de dev me dit Idea + Java >>>>>> n'importe quoi + vscode
D'ailleurs Clojure + Emacs >>> the rest
 

Tu peux faire ce genre de saloperies dans tous les langages.  
En PHP j'ai meme vu des gens utiliser des dynamic variable, ou tout un tas de merdes que laisse faire PHP (comparer des int / string, de la reflection comme en Java, ...).
En JS on va même pas aborder le sujet tant la mongolance du langage est assumée.
 
T'arrètes pas de parler de casting car c'est ton souvenir de vieux Java, c'est plus le cas aujourd'hui, c'est vraiment très rare.
 

Au final t'as plein de probs dans ta codebase car tu les as dev soit disant plus vite, et pas grave on les fixera plus tard, nice
 

 
Oui, c'est ça

C'est une métrique foireuse le temps perdu. Certains coûts sont intangibles, c'est des neurones mobilisés sur la vérification que le type est correct alors qu'ils seraient mieux à résoudre le problème métier. Le temps de concentration ça n'est pas fongible, quand on perd du temps sur des conneries on en fait d'autres.

Ptin 8h de train en 2 jours, j'en ai ras le bol
 
Bon au moins, même si c'est pas du tout mon kiff, j'ai serré des paluches intéressantes

Ben c'était pas des bons devs alors.

Et si tu as besoin de caster souvent ça peut aussi être un signe de conception de merde.

Après avec les Optionals (java 8, 2014), les nullcheks et même les cast peuvent disparaître de la syntaxe et devenir des trucs du genre :

Caster.cast(machin, Truc.class).Map(Truc::faisUnBidule).ifPresent(Bidule::pouet).orElse(prout);

Et en java 17 ou 18 il y a du pattern matching.

Donc ton expérience perso est datée, et pue un peu du fion.

Ça faisait longtemps, une guerre des langages.

De toute façon, Dart über alles.

 
C'est relou les déplacements pro ... Avec le temps ça me saoule de plus en plus  
 

 
J'ai implémenté un parseur SAX avec rendu XLST je suis pas fou non plus    
 
 

 
 
Je ne vois pas en quoi c'est mieux, j'ai vu des gens rater des tests (plus que du code d'ailleurs) et se prendre la tete avec tout pareil.
 
Donc autant se concentrer sur ce qui merde plutot que sur de l'hypothétique.
 

 
Je ne vois pas le tooling java etre suppérieur a aucun autre sur le marché a vrai dire, les toolings sont clairement équivalent, mais au moins vscode se lance vite
 
Mais en debug, lire, breakpoint, modifier la variable, le code, tout ca ca passe sur tous les languages majeurs (a part rust ou Clion le faisait pas de souvenir, juste breakpoint et lecture).
 

 
On parlait de l'efficacité et de la vitesse de dev je crois non ?    
 
Le bordel pour caster un pauvre truc et gerer un if/else si ca foire    
 

 
Non, en tout cas dans le web c'est nien, si tu as pas une flexibilité sur l'input tes clients vont gueuler. Ou alors vous avez pas de gros produits bien velu et peu de clients, mais des que tu atteinds une certaines taille t'a interet a accepter un peu tout en entrée.
 
 

 
 
Ca n'aurait pas été marrant sans ca.
 
 
 
Pour le reste: comme dit j'ai recu le synthé A dans quelques heures minimum

Bin disons qu'à partir du moment où une portion significative (et de plus en plus importante au fur et à mesure des années qui passent) du temps total de ton équipe est passée à fixer des bugs ou des erreurs Sentry (ou whatever l'outil utilisé pour remonter les bugs en prod), oui ça devient un soucis et pas du tout que pour les devs. Quand une feature qui devrait prendre 1 mois à sortir en prend 3 parce que l'équipe est sans arrêt "interrompu" (ca peut être du bug fix planifié hein, c'est pas forcément une "urgence" en prod) par ces petites corrections/modifications annexes, ça impacte toute la boite et pas que "la journée plus cool" du dev.

Et tu parles de non-problème, mais mon expérience après 15 ans c'est que globalement, avec une appli en prod suffisamment longtemps, bin tous les "non problèmes" dont tu parles (ou en tous cas une bonne partie), tu finiras par les rencontrer. Et du coup ça t'obligera à te pencher 1, 2 ans plus tard dans du code que, au mieux toi tu as écris, au pire un bouzin immonde écrit par un mec qui a quitté la boite depuis. Alors après Rust c'est pas magique on est bien d'accord non plus, mais au moins au moment où tu écris ton code, bin ça te force à "taper" ton "?" pour dire "si ça pète là je m'en fous". Au moins c'est explicite. Et peut-être que dans N% des cas le dev se dira au moins "ah mais attend si ce truc est Null, je fais quoi ? Ah bin tiens je peux fallback gracefully sans faire péter une 500 en faisant ça" (peut être que je rêve OK).

Pour moi le seul "vrai" handicap que je vois à Rust (en dehors de l'écosystème encore jeune ofc) c'est celui évoqué par masklinn: j'ai du mal à voir comment une appli un peu importante en Rust peut facilement gérer un pivot majeur de la startup tous les 6 mois et donc avec les modifications profondes du code et le besoin d'avoir rapidement un truc up & running qui vont avec.

 
? c'est "je peux pas gérer je file à papa", "si ça pète là je m'en fous" c'est unwrap ("c'est pas censé pêter là", c'est expect).

Après par contre tu peux remplacer le train d'atterrissage en vol et ça peut passer (selon l'impact).
 
Genre sur un projet j'ai remplacé warp par axum, ça a pris un peu de temps (surtout pour les conversions de Path, j'avais pas compris comment ça marchait initialement mais c'est parce que j'avais lu le truc en diagonale) mais au final ce qui en a pris le plus je pense que c'était repasser sur les handlers pour les convertir en Result propre.

Les outils de refactoring, l'analyse de code, rien que ça déjà.

 
Surtout que des devs avec Lambo, y en a pas bcp

Tu chipotes
 
 
( mais je suis d'accord     )
 

Ouais mais est ce que les refacto purement "technique" c'est pas le cas le plus simple à gérer en Rust (voir même plus simple qu'avec beaucoup de langages dynamiques vu que l'IDE peut "facilement" t'aider sur pleins de trucs) ? J'avoue que j'avais plus en tête des pivots produits.

A ceux qui font du Rust vous avez aimez ça dès le début ?

Ça fait 3 fois que j'essaie de m'y mettre mais à chaque fois je finis par laisser tomber. C'est un peu laborieux je trouve et la syntaxe pas très lisible. J'ai l'habitude des trucs simples, je fais principalement du C et du Python.

Faudrais que je me trouve un vrai projet à réaliser pour me forcer un peu

perso je trouvais le rust était un peu saoulant, surtout essayer de tout mapper sur le borrow checker était un peu l'enfer.

https://digg.com/internet-culture/l [...] TyYGH02gR9  

 
Tu penses quand même pas qu'un des languages les plus utilisés au monde a des pbs de tooling quand même ?
 
De deux le besoin de refactor quand t'a pas des millions de classes devient tout de suite un bien moindre soucis; je dis ca je dis rien
 
Mais enfin oui le refactoring pas de soucis, l'analyse de code non plus... Que ce soit VSCode ou Storm, jamais vu de pb majeur aussi bien en JS qu'en typescript.
 
 
 

 
 
Comme a dit masklinn plus haut: Rust tu peux le tenter dans le cas d'un code critique que tu changes pas tous les jours. Dans cette situation ce sera du tout bon, par contre si t'a besoin de réécrire tous les 6 mois, ca s'annonce mal.
 
EDIT: et je te conseille de prendre une license CLion, ca aide pas mal; justement Rust fait parti des rares languages avec un tooling moyen, et CLion est encore le mieux sur ce language pour le moment (et même lui c'est pas parfait).
 
 
 
 
Sinon bordel le moog one  

Ce sont de simple faits, les outils d'analyse et de refacto dans VS Code par exemple pour le JS sont moins bon que ce qu'on trouve en Java.
 
Le refactoring ça se fait même en écrivant le code, pas toujours par après dans 10 ans.  
Je conçois que comme tu as perdu ton âme d'enfant en réunionite tu sois loin du spectre

Oui j'avais bien compris

L'IDE il a aidé sur rien du tout, rust-analyzer il sait pas remplacer des librairies et il pige pas grand chose quand les types ont aucun rapport C'est plus le cycle de changer un truc / check / fix, qui va bien et surtout est fiable, c'est un peu chiant dans la mesure où tu peux rien faire tant que tout n'est pas fixer (sauf à commenter des morceaux  complets) mais une fois fini ya de bonnes chances que ça marche.

C'est ce qui rend le pivot produit plus difficile, il est difficile d'être dans un état partiel (au mieux t'as des unwrap partout, et limite c'est chiant), donc l'exploratoire et le pivot sont difficile, dans ces cas tu t'en fous si la moitié du truc est pêté tu veux juste l'ignorer pour le moment, en rust faut tout commenter. D'ailleurs j'ai eu le problème récemment (enfin pas moi mais une lib tierce), 1.70 a enlevé une vieille feature de nightly, sauf que ça veut dire que c'est plus parsé, une dépendance avait ça dans un test derrière un cfg pour un vieux bricolage, ça compilait plus

Oui. Après ma rust-curiosité date d'avant la 1.0 (genre j'avais commencé à me renseigner avant le passage des itérateurs internes à externes) (edit: première mention ici en 2011, il y avait encore les typestates) donc j'avais au moins absorbé une partie de la syntaxe par osmose, et j'étais au courant de certains pièges / problèmes avant de vraiment me lancer dedans (même si le borrowck sauf si t'es un savant t'as nécessairement besoin d'un bon morceau de théorie suivi de pas mal de pratique).

Des langages que j'ai appris récemment (Dart, Go et Rust), je trouve que Rust est plus lisible que Go... tant que t'as pas à gérer les lifetimes
Sinon oui, j'ai aimé les promesses du langage et la façon de les implémenter.
 

VScode + Rust analyzer c'est pas mal du tout je trouve. Ou Neovide sinon.

Je pense qu'à un moment faut plus parler de code quand on n'y a plus touché depuis genre une décennie, ça devient embarrassant

Si on exécute le code depuis l'éditeur d'Omikron basic et qu'il plante la machine ou part en boucle infinie alors que le source n'a pas été sauvegardé : pas de souci, il suffit de faire un reset hard de la machine au bouton, le vecteur de reset est modifié par l'IDE pour retourner dedans, rien n'est perdu

Je code, au présent.

Je gère une code base spéciale, avec une façon de dev spéciale, je le sais, et ça n'est pas un problème.

Mon idée ici n'était pas de dire "j'ai raison taisez vous ", simplement je voulais amener a envisager que peut-être, une bonne partie de ce que vous (et moi il y a quelques années maintenant) considérez comme indispensable, est peut être en réalité parfaitement dispensable.

Mais vous êtes franchement obtus donc la discussion tourne court et maintenant on en est aux attaques perso

Je suis conscient aussi que chaque cas est unique, j'imagine bien que dans le cas d'une banque ce que je marque (zapper les test U par exemple), est grotesque. Mais tout le monde ne gère pas un pole sensible, a vrai dire, la majorité ne gère pas de pole sensible du tout. Et donc pour ces gens là, qui sont légions, ont leur a mis dans la tête que sans test U, point de salut, pour autant, l'inverse complet marche très bien.

Et l'ensemble de ce que j'ai marqué tournais autour plus ou moins de ce questionnement de chose pseudo-vérifié qui en fin de compte ne le sont pas du tout. Je ne vois pas moins de bugs depuis que les tests U se sont démocratisés en pagaille de partout, par exemple, ne parlons même pas des TDDs je vois 0 différence a l'existence de cette méthode. Et si la code base a grossi et que c'est la raison : et bien cela ne veut simplement dire que les tests U ne sont pas suffisant pour palier a cette augmentation, l'industrie du code aurait donc du aller a contre courant, n'ayant pas de solution a la grosseur des codes.

Pareil pour Java vs Node, je redis, aujourd'hui partir sur Java, n'a que peu de sens dans le web. Le nombre de langage mieux taillé pour le jobs sont légions, pick one. Si cela vous arrange: je n'irai jamais choisir node pour une desktop app, parce que là ou Node brille dans le web, il est inadapté au desktop (et certainement pas avec Electron et autre truc chelou). Suivant le job, ou ce qui est dispos sous un langage, je choisirais plus l'un que l'autre. Après tout je code tellement peu que je connais que 20 langages (j'ai pas fait le décompte mais ca doit être dans ces eaux là), si j'avais su que c'était le 21eme qu'il me manquait pour savoir de quoi je parle

Je gère une code base de 700k lignes. Sans être la plus grosse; je pense pouvoir aisément dire que si le re-facto était un soucis en JS (ou PHP ou whatever, je n'ai pas vu de refacto problématique depuis très longtemps), ca ferait longtemps que moi et mon équipe on aurait eu de gros soucis. Et oui, il y a certainement plus de bugs que en refacto Java, et alors ?

Au cas ou tu n'as pas remarqué, j'ai visiblement pas mal de temps libre pour écrire des pavés ici, preuve que niveau bug au final, malgré mes langages interprétés, mon absence de code décennale et ma foutue réunionite aiguë, ça va quand même pas trop mal

 
En étant passionné avec ces discussions j'en ai oublié le plus important
 
Tu as donc du code a moi qui tourne sur ton PC.
 
 
Have fun

Wait, t'as bossé sur Reaper ?

Heureusement. Par contre, vu que t'as tort, ça suffit

Dernière chose après j'arrête de te répondre, mais tu insistes là dessus alors je précise : Les tests unitaires c'est pas pour réduire le nombre de bugs, c'est pour gérer la complexité.

 
Bonnes vacances  
 

 
Je regrette l'arrivé de cet opérateur en PHP, depuis je le vois utilisé partout en mode balek

Utilisé correctement ça allège quand même vachement le code par endroits

ouais, comme le "continue 2" quoi

bah quand t'as genre un setter pour un champ nullable, tu préfères lire

$toto->setBiduleId($machin?->getBidule()->getId());

ou

$toto->setBiduleId(null === $machin->getBidule() ? null : $machin->getBidule()->getId());

 
Attention c’est pas du tout la même chose
 
En PHP (et dans la majorité des langages) ce sont des opérateurs de “navigation nullsafe”, en Rust c’est une structure de contrôle.
 
Après je sais pas si / comment ça interagit avec les types nullables, genre est-ce que tu peux passer ta base de code en non-nullable (par défaut) et que les opérateurs de navigation nullables vont pas compiler s’ils peuvent pas être utilisés sur des trucs non nullables?

…
 
Ça te dit au moins qui tu devrais arrêter de suivre?