Je travaille en ce moment sur deux projets, un en Java/Kotlin pour des clients, un second en Rust pour des besoins internes, et j'ai réalisé la chose suivante :

• En Java/Kotlin, le langage est fait pour vous aider mais vous allez vous battre contre les frameworks.
• En Rust, les frameworks sont faits pour vous aider mais vous allez vous battre contre le langage.

C'est incroyable à quel point le borrow checker vous pousse à écrire du code procédurale et mécaniquement intestable. Dès l'instant où l'on souhaite passer par des traits tout devient ultra compliqué. Dernièrement je me suis faite avoir en utilisant des Rc et des RcCell sur un code qui allait devenir multi-thread #Horreur

Pour moi, casser le couplage entre deux composants via une interface/trait est IN-DIS-PEN-SABLE mais Rust pousse à définir des structures comme contrat d'interfaçage principal entre deux pans de code.

Forcément, le langage se transforme en enfer dès l'instant où l'on souhaite dépendre d'un trait et non d'une structure (c'est pourtant le 'I' de SOLID, dépendre des Interfaces mais pas des Implémentations).

En même temps je l'avais déjà dit par le passé, le paradigme fonctionnel pur est un cancer métastasé car l'expressivité de la syntaxe donne le sentiment que des tests ne sont pas nécessaires or c'est toujours faux.

Et j'ai suffisamment souffert de Java dans ma vie pour haïr le fait de devoir mocker/instancier/déclarer quarante-douze-mille trucs avant de pouvoir tester une simple fonction.

Bref, deux ans sur Rust à temps partiel et je me vois retourner dans le RustBook tous les 4 mois pour y chercher un truc #Pénible alors qu'en Kotlin ça ne m'arrive jamais.

Traduction / Résumé :
La Commission Européenne est un organe Exécutif qui détient également un pouvoir Législatif (sic), constituée de personnes non-élues (sic 2) et qui fait pression sur un organe Judiciaire en faisant appel d'une décision de la CJUE (à la limite why not ?) pour obtenir le jugement qu'elle souhaite afin qu'Apple soit bien imposée à 0,005 % et non 1% (sic 3 voire carrément WTF ?).

Sinon, en tant qu'indép :

• Je rends 20 % de toutes mes factures, c'est la TVA, je n'ai pas le plaisir d'une exonération de TVA à la sauce Irlandaise.
• Puis je paie environ 48 % de cotisations sur mon salaire brut (précisément je touche une indemnité de travailleur mandataire puisque je suis Présidente de ma SASU) en sachant que ce statut ne me donne pas le droit au chômage !
• Je pais aussi 33,33 % d'impôts sur les sociétés (le fameux IS sur les bénéfices) en fin d'exercice.
• Puis je paie 30 % de cotisations sociales sur ce qui reste après l'IS si je me verse des dividendes (ce que je fais et en contre-partie de ces 30 % seulement, l'argent des dividendes ne rentre pas dans le calcul de ma retraite).
• Et je suis enfin imposée sur le revenu sur l'ensemble de tout ce que j'ai touché.
• Ah oui, j'oubliais les 1 à 2 % de taxes diverses et variées, indexées sur le montant total des salaires versés incluant des petites merveilles de déclarations comme les taxes d'apprentissages (FAFIE, FAFIEC) et les frais de fonctionnement de la structure (comptable, bilan, banque, assurance RCE, dépôts administratifs, etc).

Et là, notre chère Commission Européenne n'est pas contente pour Apple parce que la CJUE demande à ce qu'Apple paie 1 % d'impôts au lieu de 0,005 % !!!

Je propose de noter l'Union Européenne à #DémocratureSur20...

Et après certains se demandent encore pourquoi je défends ardemment l'idée de quitter ce piège des peuples qui est aussi une structure mafieuse servant ses intérêts propres au détriment de tous les autres.

Pour les salariés et les clients de la firme de Cuppertino qui adorent s'offrir des iBidule, sachez que votre retraite part là, les écoles publiques de vos gosses perdent leurs financement là, la sécurité sociale est détruite à cause de ça, les hôpitaux publics manquent de subventions à cause de ça, les infrastructures routières, ferroviaires et aéronautiques sont privatisées à cause de ça, les investissements dans la recherche sont annulés à cause de ça... Alors s'il vous plaît, avant d'acheter un truc avec un pomme croquée, juste "Think Different" please, car payer c'est voter. Et pour ce qui est de l'Union Européenne, peut-être qu'un jour nous serons suffisamment nombreux à vouloir en sortir.

Je me souviens que je disais en 2010 à @Roger quelque chose du type :

La programmation fonctionnelle est un cancer.

Heureusement, dix ans plus tard j'ai quand même un peu changé d'avis sur la question, je dirais aujourd'hui :

La programmation fonctionnelle "pure" est un cancer.

La différence étant que je suis en mesure d'argumenter le ressenti inconscient que j'avais à l'époque. Depuis le bouquin sur les design-patterns du Gang of Four, nous avons eu une pléthore d'autres auteurs qui nous ont expliqué pourquoi il faut toujours dépendre des interfaces et jamais des implémentations. Le problème avec ça, c'est qu'une grande partie des développeurs ne comprennent pas bien ce que sont les implémentations et surtout pourquoi il ne faut pas dépendre d'elles.

En réalité, une implémentation embarque avec elle des attributs (et si un objet n'a pas d'attribut c'est que le développeur a codé en procédurale "pure", il n'a rien encapsulé, ça n'est pas objet du tout mais je m'égare). Le problème avec les implémentations ce sont justement les attributs qui deviennent visibles. Dit autrement nous commençons à devenir dépendant de la structure de données qui nous arrive et non plus d'un ensemble de fonctions (ie. méthodes) que nous pouvons exécuter. D'ailleurs nous sommes tellement dépendant des attributs que même s'ils sont privés, nous allons alors ajouter des getters/setters pour y accéder quand même.

Remonter à l'interface c'est casser ce lien explicite avec la structure de données embarquée dans une classe et alors un changement de structure ou de structure de la structure n'impactera pas le code utilisateur.

Mais alors quel est le problème avec la programmation fonctionnelle "pure" ?
C'est justement qu'elle pousse tous les morceaux de code à dépendre des mêmes structures. Changez la structure à un endroit et vous êtes partis pour changer toutes les fonctions qui s'appuient sur cette structure. Cela engendre fondamentalement un maillage global de tous les pans de code d'une application avec un couplage fort autour de cette ou de ces structures.

La seule condition pour y remédier c'est d'avoir "la bonne structure du premier coup"... lol quoi... Comment prévoir quelles données (et de quels types) nous arriveront demain ?

À l'inverse, retourner des implémentations d'interface autoboxé dans le type de cette interface (c-à-d. les fameux "messages" de la POO) garanti non seulement que les changements de structures n'auront pas d'impact, mais que les changements d'algorithmes non plus (ici "pas d'impact" est à prendre au sens où le contrat d'interfaçage n'est pas rompu et donc que le code continu de compiler).

Pourquoi est-ce que je vous parle de tout ça ?
À cause Rust et de mes quatre semaines d'immersion intense.

Soyons clair, je trouve que les concepts derrière le langage sont incroyables et ses performances merveilleuses (en tant que dev Java j'ai toujours détesté la JVM rien que pour ce sujet). Par contre le fait que Rust se soit tourné exclusivement vers le fonctionnel et la programmation en "structure-first" à la place de celle en "contract-first" car la majorité des devs ne parviennent pas à penser en objets avec l'encapsulation, cela fait de Rust un langage aussi immaintenable que C mais un peu plus fiable grâce à son meilleur compilateur.

L'API de Rust est digne de celle du C. Par exemple, prenons la méthodes HashMap::keys()de la stdlib de Rust. Celle-ci aurait pu retourner l'implémentation d'un trait Iterator mais non, elle retourne une structure Key qui contient une structureIter qui contient une autre structure base::Iter.

Changez un morceau de la chaîne et préparez-vous à gérer les impacts partout.

En résumé, et après être passée dans l'ordre par Java, OCaml, PHP, C, ASM, Bash, CSH, Python, JavaScript (ES5 à ES7), Anubis, Haskell, Ruby, Groovy, TypeScript, Scala, Go, Kotlin et enfin Rust (ndr. je bidouillais en Rust depuis quelques années), je peux vous assurer que :

1. Rust est techniquement un super langage avec l'un des meilleurs compilateur du marché.
2. Rust a une API aussi pourrie que celle de C, encourageant le couplage et augmentant l'immaintenabilité. Je crois qu'il doit exister un moyen d'outre-passer cela, mais je ne sais pas encore comment faire et ça me fruste pas mal.

Enfin, je sais que certains dev vont être fâchés de lire ce que j'écris alors permettez-moi de vous proposer un test car j'ai le sentiment que si c'est le cas, c'est que vous n'avez jamais pensé en OOP - et donc que vous ne pouvez pas encore comprendre ce que je dis. Il s'agit d'un exercice que @Kysofer a imaginé pour ses entretiens d'embauche afin de savoir si un candidat "expert Java" savait penser et programmer en orienté objet.

Prenez ces deux classes :

class Person {
    private final String name;
    private final String firstName;
    private final int age;

    public Person(String name, String firstName, int age) {
        this.name = name;
        this.firstName = firstName;
        this.age = age;
    }
}

class Car {
    private final String brand;
    private final String name;

    public Car(String brand, String name) {
        this.brand = brand;
        this.name = name;
    }
}

Objectifs :

• Sans violer l'encapsulation, c'est-à-dire sans jamais accéder aux attributs des deux classes depuis l'extérieur de ces deux classes.
• Sans ajouter des getter ou des setter.
• Sans mettre les attributs en public, package ou protected.
• Sans implémenter les algorithmes de conversion à l'intérieur des deux classes elles-mêmes.

=> Écrivez une architecture qui soit capable de convertir en JSON ou en XML ces deux objets.

Indice : Quand on pense en objet, c'est évident, très facile même. Quand on ne pense qu'en procédurale ou son évolution en fonctionnel, cela paraît impossible.

Et dans tout ça je ne compte pas arrêter Rust pour autant mais je fais appel à mes amis pour qu'ils m'aident à trouver une façon "clean" de coder dans ce langage.