Re: Go

C'est bien pour ça que j'insiste sur un des avantages des micros frameworks qui est de pouvoir être changés facilement au cas où ça tournerait mal (ou que l'app évolue dans un sens différent), ce qui est loin d'être évident avec un plus gros et qui entraîne d'énormes problèmes pour faire évoluer le framework lui-même. Alors oui, le gros framework ne casse pas la compatibilité, mais pour cause, il n'évolue plus et au bout d'un moment on change tout, le langage avec l'eau du bain !

Je ne suis pas d'accord avec cette dichotomie. CDI qui est un énorme framework (on parle de Java EE des familles) est très peu intrusif, par exemple. Rx qui est relativement petit va lui lourdement impacter ton code.

Pour moi il ne faut pas dire, « je prends un framework minimaliste parce que je peux le changer », mais je sais où j'ai mes adhérences et tu as quelques cas :

• le code dont tu ne peux te passer (hibernate es-tu là ?)
• le code dont tu peux te passer facilement (bonjour dagger)
• le code dont l'interface est normalisé (PEP, JSR voir IETF/what ever)

Chercher à être hors de toute dépendance, n'a pas grand intérêt AMHA.

On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.

Le langage qui intègre un serveur web dans sa bibliothèque standard ? Ouai :)

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)