D’ailleurs, tout personne un minimum savante sait que 42 est la réponse à une unique question ! Alors que Python est la réponse à toutes les questions. On voit là un pouvoir supérieur, qui justifierai à lui seul la création d’une nouvelle religion.
Je pensais à un petit nom accrocheur comme « les adorateurs de py » (« the py worshippers » en anglais), mais j’ai peur que les anglophones nous prennent pour une secte exclusivement culinaire et que le nom français nous attire de la confusion avec les mathématiciens ou les protecteurs des animaux.
En vrai, c’est un peu dommage, parce que maintenant que Python est devenu bien mainstream, je vous parie qu’il va commencer à dégringoler dans les 5 années à venir : c’était il y a 5 ans qu’il fallait s’y intéresser, pendant le creux de la vague, puisqu’aujourd’hui ce n’est pas tant python que plus de 5 ans d’expérience en Python qui se vend comme des petits pains…
Je parle uniquement en termes de facilité pour trouver un job mieux rémunéré que la moyenne du marché, hein.
Aujourd’hui, mon nez me dit que les langages au creux de la vague sont Go et Rust, et la vague commence à sérieusement arriver pour Go (Rust, on n’y est pas encore, mais ça finira par venir).
Je sais pas si c’est un biais de perception lié à mon environnement ou autre, mais je n’ai pas du tout cette impression pour Go.
Qu’est-ce qui te fait penser ça ?
Je sais pas si c’est un biais de perception lié à mon environnement ou autre, mais je n’ai pas du tout cette impression pour Go.
Qu’est-ce qui te fait penser ça ?
Pour résumer très grossièrement, côté backend, la tendance de l’industrie ces 5 dernières années est d’adopter massivement des architectures basées sur des conteneurs : Docker (écrit en Go) les a massivement facilité et popularisé, et ils l’ont fait tellement bien qu’aujourd’hui ils sont limite dépassés par les événements (bugs critiques qui traînent depuis des mois, etc.) et se font remplacer par des technos compatibles, mais standard (voir plus bas). Il y a 4/5 ans on pouvait encore légitimement croire à un effet de mode, sauf que :
Google a poussé son orchestrateur Kubernetes (écrit en Go), qui a été massivement adopté par les fournisseurs de cloud, y compris ses concurrents (Microsoft, Amazon, IBM, RedHat avec OpenShift… tout le monde fait du Kubernetes !), et qui a notamment écrasé les orchestrateurs de Docker (que ce soit compose ou Swarm).
On commence à entendre du plus en plus parler aujourd’hui de l’OCI qui vise à standardiser les formats et les runtimes pour les conteneurs : tout le code de référence produit par l’OCI est en Go, de même que toutes les alternatives à Docker1.
La littérature est devenue complètement dingue sur le sujet (et à raison), parce que ces solutions d’infrastructure rendent les applications massivement distribuées plus intelligibles et compréhensibles : il est vachement plus simple de raisonner à leur sujet quand on réfléchit en utilisant le style d’abstractions que propose K8S (ou ses extensions).
Maintenant on pourrait se demander bah, pourquoi Go, puisque je peux utiliser n’importe quel langage dans mes conteneurs ? Eh bien dans le cas général, à cause de LA caractéristique qui a valu que tout le monde se foute de sa gueule au départ : parce qu’une appli en Go tient généralement dans un bête binaire standalone qu’il suffit d’embarquer dans une image "FROM scratch", alors que les technos de la génération précédente ont presque toutes besoin d’embarquer un environnement Python ou Ruby, ou une JVM, ou encore Mono (parce que les conteneurs Windows, ça existe mais… euh… enfin bref) qui alourdissent considérablement les conteneurs et les rend généralement plus coûteux à déployer dans un cloud, opérer, redémarrer, scaler… : l’image d’un serveur HTTP qui répond juste hello world va peser entre 350Mo et 1Go (!!!) en utilisant ces technos, contre 6.5Mo en Go. Ça peut sembler un peu con comme argument, mais il faut bien garder en tête que ces images vont tout le temps transiter sur le réseau, ou bien prendre de la place dans le cache local des noeuds qui les font tourner : mis bout à bout ça joue énormément !
Dans un éventuel avenir que j’appelle de mes voeux où les gens font autant attention à leur empreinte énergétique qu’à leurs coûts opérationnels (et le cloud nous autorise à y rêver puisqu’indirectement, on le paye déjà à la mesure de l’énergie que l’on consomme), ce genre de détail va peser de plus en plus lourd. Quand bien même ce ne serait pas une question de taille de l’image, Go est globalement aussi, voire plus confortable, safe et commode à utiliser que Python pour écrire des services (REST ou RPC ou autre), en plus de complètement l’éclater en termes de performances.
On est donc face à un langage qui dispose d’un sur-ensemble des qualités qui ont poussé l’adoption de Python, et pas seulement théoriques mais également du point de vue du confort, de la richesse de l’écosystème, et des coûts secondaires (le coût humain de former les gens qui est réduit, ou celui de développer et maintenir un service… qui est presque moindre qu’en Python), et qui a pour lui le fait qu’il soit déjà massivement présent dans les infrastructures modernes.
Par contre, ça ne sera probablement jamais le langage généraliste à tout faire de monsieur tout le monde : c’est juste qu’il est omni-présent dans un domaine dans lequel il va y avoir besoin de plus en plus de gens dans les années qui viennent, et tout porte à croire, avec un niveau raisonnable de confiance, que ça sera pour longtemps.
PS:
@Aabu : J’ai choisi de travailler avec parce que je pense ça, nuance.
Enfin ça ne m’étonnerait pas que quelqu’un ait aussi décidé de recoder Docker en Rust, vu que c’est le langage parfait pour recoder tout l’univers (oui, ceci est un troll, mais j’aime beaucoup Rust aussi hein…). Ah oui, tiens, oracle l’a fait.
A la maison j’ai deux écrans de 21pouces en Full HD. je me suis dit que j’allais me prendre un écran en 21/9 full HD pour plus de confort. Jen ai justement trouvé un sur Amazon à un prix incroyable.
Ecran 21/9, 2500 et quelques sur 1080px, et le tout, en 25 pouces !
25 pouces, cest grand. je le vois déjà avec mon écran de 21 pouces… enfin, cest ce que je croyais. car 25pouces avec ce format, cest pas si grand que ça… jai même l’impression qu’il est plus petit que mes deux écran de 21 pouces réuni (surtout en hauteur).
Bref, un peu déçu de mon achat. Heureusement que je ne lai pas payé très cher.
Aujourd’hui, mon nez me dit que les langages au creux de la vague sont Go et Rust, et la vague commence à sérieusement arriver pour Go (Rust, on n’y est pas encore, mais ça finira par venir).
Aujourd’hui, mon nez me dit que les langages au creux de la vague sont Go et Rust, et la vague commence à sérieusement arriver pour Go (Rust, on n’y est pas encore, mais ça finira par venir).
Clairement, Rust est LE langage pour aller presser la moindre goutte de perfs d’un programme.
Mais la comparaison n’est pas si importante que ça parce que les perfs (ou la safety) sont loin d’être les seuls critères à entrer en compte. Les deux langages ne brillent pas pour les mêmes choses, et les domaines dans lesquels ils sont applicables sont tellement vastes qu’ils ont largement de quoi partager leur terrain de jeu.
Pour moi, ce n’est pas vraiment pertinent de les opposer l’un à l’autre en fait.
PS : Pour clarifier le fond de ma pensée : l’usage que je vois de Rust est exactement celui que Discord en a fait. Ils avaient un service écrit en Go, et après avoir soigneusement profilé ce qui se passe pour leur 95e pourcentile, ils ont fini par déterminer que Go n’était plus suffisant et concéder l’effort d’une réimplémentation du micro-service en Rust. Ça a l’air presque facile dit comme ça, mais là où Go brille pour le commun des mortels, c’est précisément dans la facilité à développer la version initiale d’un nouveau service qui fait son job et passe à l’échelle en prod avec un niveau de performances acceptable (et raffiner son usage, son design, etc. pour le stabiliser, ce qui prend généralement de nombreuses itérations). Si Go est pour moi meilleur que Rust pour cela, c’est précisément parce que cette façon de bosser requiert un langage versatile : c’est une partie du travail qu’on oublie volontiers quand on choisit une techno, et pour avoir longuement joué avec, je trouve que la plus grosse faiblesse de Rust est qu’il ne permet pas vraiment de partir dans un code sans savoir où on va, ou plutôt, qu’il rend ça pénible et coûteux. Typiquement, Discord n’aurait jamais pu implémenter ce service en Rust qui déboîte du poney from scratch, s’ils n’avaient pas acquis une solide compréhension du problème à travers leur implémentation initiale (en Go) : son image de langage parfait pour recoder l’univers n’est pas juste un pun gratuit.
Une fois que le service, son API et son fonctionnement interne sont stables, si ses performances ne suffisent pas, alors cela vaut le coup de tout solidifier et consolider en le recodant en Rust, mais avant d’avoir besoin d’en arriver là, il faut quand même s’appeler Discord et gérer une charge de malade en régime constant : ce n’est pas le scénario le plus fréquent (qui est de coller son service en prod, le monitorer pour que ça clignote en rouge quelque part en cas de problème, et passer à autre chose).
Pour résumer très grossièrement, côté backend, la tendance de l’industrie ces 5 dernières années est d’adopter massivement des architectures basées sur des conteneurs : Docker (écrit en Go) les a massivement facilité et popularisé […]
À ce sujet, il y a truc que je n’ai jamais saisis c’est pourquoi cet engouement maintenant alors que c’était faisable depuis très longtemps ? Je veux dire, objectivement, quand tu creuses, un container docker c’est grosso modo un chroot (avec un système de fichier OverlayFS pour gérer les snapshots, mais bref) avec quelques facilités supplémentaires offertes out of the box par Docker comme la connectivité réseau.
Cependant, ce genre de truc est faisable depuis que les chroot existent. Dans le fond, un exécutable ELF étant exportable d’une distribution Linux à l’autre, fournir un tar.gz contenant le système de fichier du chroot était déjà possible. Pour l’aspect réseau, c’est également assez simple à l’aide d’interfaces virtuelles et de quelques règles iptables.
La littérature est devenue complètement dingue sur le sujet (et à raison), parce que ces solutions d’infrastructure rendent les applications massivement distribuées plus intelligibles et compréhensibles : il est vachement plus simple de raisonner à leur sujet quand on réfléchit en utilisant le style d’abstractions que propose K8S (ou ses extensions).
Tu peux développer ce point ? Parce que de mon point de vue c’est justement le contraire. Je ne trouve rien de plus inintelligible et d’inmaintenable qu’une chiée de containers docker qui sont censés communiquer entre eux.
Maintenant on pourrait se demander bah, pourquoi Go, puisque je peux utiliser n’importe quel langage dans mes conteneurs ? Eh bien dans le cas général, à cause de LA caractéristique qui a valu que tout le monde se foute de sa gueule au départ : parce qu’une appli en Go tient généralement dans un bête binaire standalone qu’il suffit d’embarquer dans une image "FROM scratch" […]
Je ne voudrais pas paraître rabat-joie, mais ça s’appelle un exécutable statique. C’est vraiment pas nouveau et certainement pas propre au Go.
C’est d’ailleurs assez marrant de constater que l’on y revient, à l’exécutable statique. Pour rappel, on l’a banni de manière générale pour des gains d’espace disque et de mémoire au profit des bibliothèques partagées. Le truc, c’est que comme maintenant chaque application vient avec son petit environment virtuel (coucou Python) et en conséquence ses propres versions de bibliothèques, bah l’argument initial tombe un peu à l’eau…
Édit :
Clairement, Rust est LE langage pour aller presser la moindre goutte de perfs d’un programme.
La littérature est devenue complètement dingue sur le sujet (et à raison), parce que ces solutions d’infrastructure rendent les applications massivement distribuées plus intelligibles et compréhensibles : il est vachement plus simple de raisonner à leur sujet quand on réfléchit en utilisant le style d’abstractions que propose K8S (ou ses extensions).
Tu peux développer ce point ? Parce que de mon point de vue c’est justement le contraire. Je ne trouve rien de plus inintelligible et d’inmaintenable qu’une chiée de containers docker qui sont censés communiquer entre eux.
Il me semble que le C est performant que dans les cas ou il est bien rédigé sauf que ce n’est aps souvent le cas, c’est dur de faire du code C bien propre et optimisé. Là ou Rust ne t’autorise pas souvent à faire une chose de manière dégeulasse(si le code est dégeu, ça se ressent sur le temps de compillation, il n’y aura pas ou peu d’impact sur la vitesse d’execution.)
À ce sujet, il y a truc que je n’ai jamais saisis c’est pourquoi cet engouement maintenant alors que c’était faisable depuis très longtemps ? Je veux dire, objectivement, quand tu creuses, un container docker c’est grosso modo un chroot (avec un système de fichier OverlayFS pour gérer les snapshots, mais bref) avec quelques facilités supplémentaires offertes out of the box par Docker
comme la connectivité réseau.
C’est juste qu’il y a une abstraction « simple » et un système de paquets autour de mécanisme. À partir de là, les gens suivent le chemin qui semblera leur demander le moins d’effort, à leur connaissance.
Que l’on pense à :
Chainer 5 modules npm au lieu d’écrire trente lignes de code
Chaîner des containers Docker plutôt qu’avoir une infrastructure sous une distribution unifiée
Faire une application pour bureau uniquement sous Electron plutôt qu’en utilisant un toolkit GUI natif
Utiliser un framework web client pour faire une application avec trois vues
Dans les quatre cas, ce sont des choses qui démultiplient et l’utilisation de ressources, et la complexité technique du projet, mais que les gens font quand même car ça leur donne l’impression de faire une économie cognitive (ils ont appris comme ça du fait de la standardisation des méthodes techniques et faire comme ça aussi la prochaine fois leur donnera peut-être l’occasion d’éviter d’avoir à apprendre quelque chose en plus, même si ça leur donnera des bugs qu’ils ne pourront pas comprendre et qu’ils seront forcés de le contourner un jour).
Typiquement, Discord n’aurait jamais pu implémenter ce service en Rust qui déboîte du poney from scratch, s’ils n’avaient pas acquis une solide compréhension du problème à travers leur implémentation initiale (en Go) : son image de langage parfait pour recoder l’univers n’est pas juste un pun gratuit.
C’est très vrai, et Rust ne sert pas qu’à recoder des serveurs, il permet aussi de recoder des scripts qui traîtent des gros fichiers CSV d’open data, des sondes qui traîtent de gros volumes de données…
En ce sens, il aurait surtout fait concurrence à C++ ou Java, au final. Et il faut reconnaître que son modèle objet est très, très propre (que ce soit les structures quasi-toujours imbriquées avec des champs nommés à plusieurs niveaux, les erreurs qui sont des valeurs de retour comme les autres…).
Go à mon sens fait concurence à Java. Même si pour l’instant il n’a pas été capable de s’installer dans nos ESNs.
C est un super langage. Avec lequel tu peux facilement te détruire le pied. C++ est sympa aussi mais tu peux t’exploser la jambe encore plus facilement. Le Rust, c’est cool mais si tu perds un orteille c’est vraiment que t’es pas doué.
Edit: J’abuse légèrement. Mais pas tant que ça. zz, un gars qui a participé au recodage de Docker en Rust (oci runtime de Oracle) dont parlait nohar quelques messages plus haut.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
