Mais oui je te rejoins sur cette volonté de classer, d'être numéro 1, de dépasser les autres,… Il y a des synergies entre concepteurs de langages mais ils n'ont pas besoin de ce genre d'octogones pour ça.
Les deux sont des véhicules mais pas conçus pour les mêmes objectifs, et ne sont pas interchangeables. Du coup ça ne sert à rien de les comparer.
De mon avis une comparaison Go/Ada, comme celle qui est plus ou moins passée sur Lnuxfr ces derniers temps a déjà plus de sens, car les deux langages ont des approches parfois différentes pour répondre aux mêmes objectifs, mais ne pas oublier que même dans ce cas, la comparaison n'est pas non plus toujours pertinente, car les deux langages n'ont pas non plus les mêmes raisons d'etre.
Cela dit … j'aimerais bien que certains concepts Ada soient repris dans Rust. Ce que je trouve intéressant dans Ada par exemple, c'est que chaque type doit être redéfini et dérivé des types de bases avec contraintes (ça fait un bail que j'ai plus fait d'Ada donc je ne me rappelle plus des termes exacts, n'hésitez pas à corriger ou préciser).
On peut dériver (et faire comme une surcharge) les types …non de base. Les deux ont beaucoup de points commun, sauf que ce n'est pas la même démarche ni façon de faire : c'était l'objet de mon dernier journal;-)
Par contre, pas sympa pour Rust de le comparer à 38T mais c'est un suber beau camion :-)
Au fait, peux-tu me pointer vers les comparaisons Go/Ada ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Non, je ne suis pas d'accord, pour certains la comparaison Go/Rust ne se pose pas mais ce n'est pas toujours le cas.
Ce qui m'agace, c'est la phrase de l'article : "tous les langages de programmation offrent un ensemble de compromis" ou "Chaque langage est optimisé pour des choses différentes". C'est faux, il y a des langages qui sont dépassés, il y a des langages qui ont été des tentatives qui n'ont pas abouti… Ce qui est vrai par contre c'est qu'il n'y a pas de langages parfait.
Et en ce sens Go, comme Rust sont des langages aboutis performants compilés relativement productifs, avec une bonne communauté, un bon ensemble de librairies qui les rendent polyvalents… d'ailleurs, à la base ils étaient concurrents direct pour remplacer C. Aujourd'hui Rust est un bon candidat (le meilleur pour moi) pour remplacer C pas vraiment Go. Pour autant Go peut remplacer C dans un certains nombres de projets un peu moins critiques en performances et ayant un plus grand besoin en facilité de développement/déploiement (Je pense aux applications sur serveurs ou GUI)…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Faut faire attention avec ça. Parce qu'un langage ne s'évalue pas tout seul. On regarde l'outillage, l'écosystème l'existant, la communauté, la doc etc. Quand on s'intéresse aux langages, on a vite fait de trouver tel langage dépassé alors que tel langage qui paraît tellement mieux. Mais dans la réalité, l'énorme majorité de ses langages super ne vont qu'à peine survivre face à des langages qui ont une communauté folle. On peut s'en plaindre, mais c'est un élément qui fait parti du langage.
Et en ce sens Go, comme Rust sont des langages aboutis performants compilés relativement productifs, avec une bonne communauté, un bon ensemble de librairies qui les rendent polyvalents…
C'est très subjectif tout ça. Tu as très peu de développeur go ou rust du coup la productivité… Tu as très peu de bibliothèques pour chacun d'eux. Il y a de quoi s'en sortir, mais c'est très faible face au C, javascript, python ou java et ça n'est pas anodin.
Alors site moi un intérêt de développer un logiciel en Basic, en Lisp, Cobol, PL/I. La seul raison que je vois est de maintenir des application existantes pas encore redevelopées. Mais il y a plus ridicule, des langages qui n ont jamais percés.
Les langages ont tout de même évolué et si certains disparaissent c est pour de bonnes raisons.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
En fait, c'est comme Ada et d'autre ici https://www.quora.com/What-are-some-truly-dead-programming-languages : des gens qui n'utilisent pas, ou ne sont pas dans un milieu où on leur en parle, pensent que c'est mort. Ça me rappelle une personne de mes connaissances qui me soutenait mordicus que Linux était mort et qu'il n'y a pas d'entreprise sérieuse qui l'utilise.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
La vérité c'est que c'est mort, ceux qui tournent sont pour faire tourner des vieux système ou parce qu'il y a des gens qui y croient encore, parce que l'on essaye de le moderniser… Mais fondamentalement, le système Mainframe est mort. Après cela ne veut pas dire qu'il ne peut pas y avoir de la place pour un gros serveur sous Linux…
C'est comme tout, il y a toujours une certaine utilisation résiduelle pour des questions historique (voire juste par passion historique juste pour le fun). Il n'empêche ça meurt. Ca peut aussi revenir, tout peut arriver. C'est comme dans le monde réel, le cheval de trait, la lampe à pétrole ne sont pas mort, des gens l'utilisent… (Ca représente 0.01% des utilisateurs et 0.0001% du travail)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
Des languages qui sont là pour tuer leur père on en voit arriver 3 par jour. L'énorme majorité tu n'en entendra jamais parler. Parmi ceux dont on entend parler tu en as une part importante qui n'arriveront pas à créer la dynamique pour véritablement croître et les quelques uns qui restent vivront d'une petite communauté. Et ceux qui dépassent leur prédécesseur ? C'est statistiquement inexistant.
On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.
Je crois aussi qu'on a pas idée de la masse que représente les langages installés. Regarde l'almanach du web pour t'en convaincre. Le hype driven développement c'est rien par rapport à la la masse de logiciels produit.
Les langages ont tout de même évolué et si certains disparaissent c est pour de bonnes raisons.
D'un point de vue purement logique. C a vu passer des dizaines d'années de langages conçu pour le tuer, il ne va pas disparaître parce que Marco a sorti un nouveau langage qu'il est beau. Aucun des langages dont tu parles n'est mort et n'importe quel nouveau langage a statistiquement bien plus de chances de mourir.
On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
Bien sûr mais quand tu regarde en pratique beaucoup de développeurs C ont une expérience Rust et beaucoup de développeurs Java ou autre ont une expérience Go et les libraires sont tout de même bien présentes au moins par wrapping d autres langages.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
beaucoup de développeurs C ont une expérience Rust et beaucoup de développeurs Java ou autre ont une expérience Go
Non. Les développeurs ce n'est pas juste quelques milliers de personnes, hein ? Et beaucoup ne pratique ça qu'au boulot et dans un cadre industriel. Ils arrivent pas le lundi matin en expliquant qu'il faut refaire les choses en ocaml parce que ça corrigerai le dernier bug qu'il a trouvé.
les libraires sont tout de même bien présentes au moins par wrapping d autres langages.
Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose. Mais c'est chiant de se maintenir un binding, ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage) et tu as très peu de bindings. La masse de bibliothèque c, java, python et js est absolument délirante Mézières tu trouve ce que tu cherche. À l'époque où je m'étais amusé avec go faire de l'amqp ça ne se faisait pas trop avec la dernière version du langage.
Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage)
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
La masse de bibliothèque c, java, python et js est absolument délirante
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
À l'époque où je m'étais amusé avec go faire de l'amqp ça ne se faisait pas trop avec la dernière version du langage.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
C clair mais perso ça ne m'empêche pas de penser la même chose (mais en un peu plus nuancé par contre. Le C ne disparaîtra pas du jour au lendemain, vu la quantité de code existant, mais pour moi c'est le seul langage suffisamment crédible pour prendre sa place au fil du temps).
Mais bon … Il me semble que derrière l'implémentation "officielle" Rust, c'est LLVM, et que LLVM supporte de plus en plus d'architectures et de processeurs. Puis si les compilos C/C++ proprios sont bien faits, les éditeurs ne devraient pas avoir trop de mal à les adapter quand le marché le demandera.
même quand on a besoin de faible latence, la plupart des jeux écrit avec Unity, Godot, Java, Javascript en témoigne ;
ont fait l'objet de beaucoup d'optimisations ses dernières années.
La mauvaise réputation des GC vient des premières implémentations "stop the world" notamment celles des vieux Java.
A côté les smart pointers de C++ et Rust sont intéressants, mais plus pénibles et ne gèrent pas tous les cas (à tel point que l'ajout d'un GC en Rust a été envisagé).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
La mauvaise réputation des GC vient des premières implémentations "stop the world" notamment celles des vieux Java.
Hors mis Azul, qui n'est pas libre, (et noop, mais il compte pas) tous les autres GC de la plateforme font du stop the world c'est juste qu'ils en font moins voir que la durée de la pause n'est pas corrélée à la taille de la heap.
Je ne dis pas que les gc sont un problème (au contraire), mais que le sujet n'est pas avec/sans gc.
Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.
A côté les smart pointers de C++ et Rust sont intéressants, mais plus pénibles et ne gèrent pas tous les cas (à tel point que l'ajout d'un GC en Rust a été envisagé).
Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas … Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.
Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé. Il y a un historique important d'applications en C, mais elles pourraient (et le sont parfois) être réécrite avec des langages à GC.
Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas …
Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
Attention, je crois que certains ont mal compris … je ne dis pas que c'est impossible, je n'ai juste aucune idée de comment on peut faire ça en dehors d'une machine virtuelle style JVM (et ça m'intéresse de savoir)
Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).
90% des applications ne sont pas écrites dans un langage avec GC
Alors là clairement non, la GC, est le 1er élément de "virtualisation" possible. Alors tous les langages interprètés, tous les langages avec compilation JIT et bien sûr les langages avec JVM l utilisent. En compilé je vois Go et Ada à ma connaissance. En fait les seuls langages sans encore utilisé sont Cobol, Pascal, C, C++… bref des langages utilisé que dans des services très critiques niveau perfs, pas la majorité du code écrit chaque jour.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Euh… stackoverflow.com/questions/1691059 (ta connaissance du langage Ada, utilisé pour des trucs critiques, n'est pas en accord avec celle de gens qui l'utilisent…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'est dommage, pour moi le Go est très bon quand je travaille pour des applications back-end qui font principalement de l'entrée/sortie (exposant/consommant une API, BDD …) et qui tournent dans des pod très contraints en ressources (quelques dizaines de milli-cpu ou centaines de Mo de RAM). Ce qui représente la majorité de mon travail depuis plus de 5 bonnes années.
Dans ce contexte, Go me permet très facilement d'avoir une application performante et cela sans aucune configuration.
Rust, pour moi, est plus délicat à mettre en œuvre dans ce contexte. Il faudra nécessairement gérer les entrées/sorties en asynchrones car je ne peux pas bloquer mon thread car il a bien d'autres choses à faire que d'attendre :)
Posté par xcomcmdr .
Évalué à 1.
Dernière modification le 09 décembre 2021 à 22:19.
J'ai un langage qui me va très bien.
Il a commencé sa vie sous le nom de COOL (C like Object Oriented Language) aujourd'hui entièrement libre et multiplateforme, et avec la compilation native en vue il est encore plus cool.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Rust versus Go : round 1, fight !
Posté par Maderios . Évalué à -9.
Moi, ce qui me lasse, c'est la banalisation d'un terme insultant et racoleur pour remplacer l'expression "piège à clic"
[^] # Re: re: Rust versus Go : round 1, fight !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
racola-clic ou racoloclic on avait dit.
Ben du coup je vais aller le lire cet article (le titre aguicheur m'avait dissuadé de suivre le lien…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: re: Rust versus Go : round 1, fight !
Posté par barmic 🦦 . Évalué à 3.
Aucun des 2 n'est mort, hein ?
Mais oui je te rejoins sur cette volonté de classer, d'être numéro 1, de dépasser les autres,… Il y a des synergies entre concepteurs de langages mais ils n'ont pas besoin de ce genre d'octogones pour ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: re: Rust versus Go : round 1, fight !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Notons qu'il n'existe pas d'octorustnes pour se battre !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 6.
Les deux sont des véhicules mais pas conçus pour les mêmes objectifs, et ne sont pas interchangeables. Du coup ça ne sert à rien de les comparer.
De mon avis une comparaison Go/Ada, comme celle qui est plus ou moins passée sur Lnuxfr ces derniers temps a déjà plus de sens, car les deux langages ont des approches parfois différentes pour répondre aux mêmes objectifs, mais ne pas oublier que même dans ce cas, la comparaison n'est pas non plus toujours pertinente, car les deux langages n'ont pas non plus les mêmes raisons d'etre.
Cela dit … j'aimerais bien que certains concepts Ada soient repris dans Rust. Ce que je trouve intéressant dans Ada par exemple, c'est que chaque type doit être redéfini et dérivé des types de bases avec contraintes (ça fait un bail que j'ai plus fait d'Ada donc je ne me rappelle plus des termes exacts, n'hésitez pas à corriger ou préciser).
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 08 décembre 2021 à 18:56.
On peut dériver (et faire comme une surcharge) les types …non de base. Les deux ont beaucoup de points commun, sauf que ce n'est pas la même démarche ni façon de faire : c'était l'objet de mon dernier journal
;-)Par contre, pas sympa pour Rust de le comparer à 38T mais c'est un suber beau camion
:-)Au fait, peux-tu me pointer vers les comparaisons Go/Ada ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 2. Dernière modification le 09 décembre 2021 à 09:31.
:) Je ne compare ni Rust ni Go à un 38 tonnes :) Autre illustration: c'est comme comparer A et B sous prétexte que ce sont deux lettres de l'alphabet.
Quel crétin je fais …. Ct pas Go/ada ton journal Rust/Ada :). Est-ce quer l'équipe de modération pourrait corriger SVP (avec le lien en prime ?).
Merci d'avance.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Je te taquinais pour le trente-huit tonnes
:-)OK, du coup, on pourrait faire le même type de mise en parallèle entre Go et Rust… Si quelqu'un s'en sent le courage.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3.
Non, je ne suis pas d'accord, pour certains la comparaison Go/Rust ne se pose pas mais ce n'est pas toujours le cas.
Ce qui m'agace, c'est la phrase de l'article : "tous les langages de programmation offrent un ensemble de compromis" ou "Chaque langage est optimisé pour des choses différentes". C'est faux, il y a des langages qui sont dépassés, il y a des langages qui ont été des tentatives qui n'ont pas abouti… Ce qui est vrai par contre c'est qu'il n'y a pas de langages parfait.
Et en ce sens Go, comme Rust sont des langages aboutis performants compilés relativement productifs, avec une bonne communauté, un bon ensemble de librairies qui les rendent polyvalents… d'ailleurs, à la base ils étaient concurrents direct pour remplacer C. Aujourd'hui Rust est un bon candidat (le meilleur pour moi) pour remplacer C pas vraiment Go. Pour autant Go peut remplacer C dans un certains nombres de projets un peu moins critiques en performances et ayant un plus grand besoin en facilité de développement/déploiement (Je pense aux applications sur serveurs ou GUI)…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par barmic 🦦 . Évalué à 6.
Faut faire attention avec ça. Parce qu'un langage ne s'évalue pas tout seul. On regarde l'outillage, l'écosystème l'existant, la communauté, la doc etc. Quand on s'intéresse aux langages, on a vite fait de trouver tel langage dépassé alors que tel langage qui paraît tellement mieux. Mais dans la réalité, l'énorme majorité de ses langages super ne vont qu'à peine survivre face à des langages qui ont une communauté folle. On peut s'en plaindre, mais c'est un élément qui fait parti du langage.
C'est très subjectif tout ça. Tu as très peu de développeur go ou rust du coup la productivité… Tu as très peu de bibliothèques pour chacun d'eux. Il y a de quoi s'en sortir, mais c'est très faible face au C, javascript, python ou java et ça n'est pas anodin.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
Alors site moi un intérêt de développer un logiciel en Basic, en Lisp, Cobol, PL/I. La seul raison que je vois est de maintenir des application existantes pas encore redevelopées. Mais il y a plus ridicule, des langages qui n ont jamais percés.
Les langages ont tout de même évolué et si certains disparaissent c est pour de bonnes raisons.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
https://www.bitdegree.org/tutorials/most-used-programming-languages/ par exemple me cite Visual Basic en troisième position… et ne mentionne ni Go ni Rust…
PL/1 reçoit de l'attention par rapport aux nouveaux truc https://github.com/guija/pl1
Et y en a encore qui en discutent (un mort bien plus vivant qu'il n'y parait) https://news.ycombinator.com/item?id=29351989
On nous disait déjà, avant de conclure, que PL/1 et COBOL sont immortels ; et juste avant que Lisp vaut toujours le coup sous sa nouvelle peau Clojure https://insights.dice.com/2014/09/08/unpopular-programming-languages-prove-lucrative/
Pour la route https://github.com/trending/common-lisp https://github.com/trending/clojure?since=daily https://github.com/trending/cobol?since=daily
En fait, c'est comme Ada et d'autre ici https://www.quora.com/What-are-some-truly-dead-programming-languages : des gens qui n'utilisent pas, ou ne sont pas dans un milieu où on leur en parle, pensent que c'est mort. Ça me rappelle une personne de mes connaissances qui me soutenait mordicus que Linux était mort et qu'il n'y a pas d'entreprise sérieuse qui l'utilise.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 2. Dernière modification le 09 décembre 2021 à 22:35.
Moi ça me fait penser également à la mort annoncée des mainframes depuis plus de 20 ans …
Pourtant ça vit encore, et même bien. On y fait même tourner du Linux et du kube via Openshift …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 22 décembre 2021 à 17:09.
La vérité c'est que c'est mort, ceux qui tournent sont pour faire tourner des vieux système ou parce qu'il y a des gens qui y croient encore, parce que l'on essaye de le moderniser… Mais fondamentalement, le système Mainframe est mort. Après cela ne veut pas dire qu'il ne peut pas y avoir de la place pour un gros serveur sous Linux…
C'est comme tout, il y a toujours une certaine utilisation résiduelle pour des questions historique (voire juste par passion historique juste pour le fun). Il n'empêche ça meurt. Ca peut aussi revenir, tout peut arriver. C'est comme dans le monde réel, le cheval de trait, la lampe à pétrole ne sont pas mort, des gens l'utilisent… (Ca représente 0.01% des utilisateurs et 0.0001% du travail)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 2.
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par barmic 🦦 . Évalué à 4.
Des languages qui sont là pour tuer leur père on en voit arriver 3 par jour. L'énorme majorité tu n'en entendra jamais parler. Parmi ceux dont on entend parler tu en as une part importante qui n'arriveront pas à créer la dynamique pour véritablement croître et les quelques uns qui restent vivront d'une petite communauté. Et ceux qui dépassent leur prédécesseur ? C'est statistiquement inexistant.
On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.
Je crois aussi qu'on a pas idée de la masse que représente les langages installés. Regarde l'almanach du web pour t'en convaincre. Le hype driven développement c'est rien par rapport à la la masse de logiciels produit.
D'un point de vue purement logique. C a vu passer des dizaines d'années de langages conçu pour le tuer, il ne va pas disparaître parce que Marco a sorti un nouveau langage qu'il est beau. Aucun des langages dont tu parles n'est mort et n'importe quel nouveau langage a statistiquement bien plus de chances de mourir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ou alors 100x plus mauvais comme PHP !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 2.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Bien sûr mais quand tu regarde en pratique beaucoup de développeurs C ont une expérience Rust et beaucoup de développeurs Java ou autre ont une expérience Go et les libraires sont tout de même bien présentes au moins par wrapping d autres langages.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par barmic 🦦 . Évalué à 3.
Non. Les développeurs ce n'est pas juste quelques milliers de personnes, hein ? Et beaucoup ne pratique ça qu'au boulot et dans un cadre industriel. Ils arrivent pas le lundi matin en expliquant qu'il faut refaire les choses en ocaml parce que ça corrigerai le dernier bug qu'il a trouvé.
Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose. Mais c'est chiant de se maintenir un binding, ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage) et tu as très peu de bindings. La masse de bibliothèque c, java, python et js est absolument délirante Mézières tu trouve ce que tu cherche. À l'époque où je m'étais amusé avec go faire de l'amqp ça ne se faisait pas trop avec la dernière version du langage.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 2.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par Lutin . Évalué à 3.
Va y avoir du boulot pour développer des compilos pour tous les microcontrôleurs.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
https://tinygo.org/ est bien parti :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . Évalué à 1.
C clair mais perso ça ne m'empêche pas de penser la même chose (mais en un peu plus nuancé par contre. Le C ne disparaîtra pas du jour au lendemain, vu la quantité de code existant, mais pour moi c'est le seul langage suffisamment crédible pour prendre sa place au fil du temps).
Mais bon … Il me semble que derrière l'implémentation "officielle" Rust, c'est LLVM, et que LLVM supporte de plus en plus d'architectures et de processeurs. Puis si les compilos C/C++ proprios sont bien faits, les éditeurs ne devraient pas avoir trop de mal à les adapter quand le marché le demandera.
# Le choix est simple
Posté par David Demelier (site web personnel) . Évalué à 0.
Tout sauf Go.
Plus détaillé :
En fait il y a trop de raisons, j'y suis encore jusqu'à midi. Je vous laisse chercher.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le choix est simple
Posté par Nibel . Évalué à 5.
Mais… mais… on est pas encore trolldi :(.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le choix est simple
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Ne craint pas la faucheuse !
Un ramasse miette :
La mauvaise réputation des GC vient des premières implémentations "stop the world" notamment celles des vieux Java.
A côté les smart pointers de C++ et Rust sont intéressants, mais plus pénibles et ne gèrent pas tous les cas (à tel point que l'ajout d'un GC en Rust a été envisagé).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le choix est simple
Posté par barmic 🦦 . Évalué à 2.
Hors mis Azul, qui n'est pas libre, (et noop, mais il compte pas) tous les autres GC de la plateforme font du stop the world c'est juste qu'ils en font moins voir que la durée de la pause n'est pas corrélée à la taille de la heap.
Je ne dis pas que les gc sont un problème (au contraire), mais que le sujet n'est pas avec/sans gc.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le choix est simple
Posté par totof2000 . Évalué à 0.
Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.
Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas … Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
[^] # Re: Le choix est simple
Posté par gorbal . Évalué à 3.
Je connais pas la technique, mais cela existe déjà en Objective C :
https://gcc.gnu.org/onlinedocs/gcc/Garbage-Collection.html
[^] # Re: Le choix est simple
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé. Il y a un historique important d'applications en C, mais elles pourraient (et le sont parfois) être réécrite avec des langages à GC.
https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/
https://github.com/rust-lang/rfcs/issues/415
Go est nativement compilé et a un GC :-)
Pour le C il y a https://www.hboehm.info/gc/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le choix est simple
Posté par totof2000 . Évalué à 1.
Attention, je crois que certains ont mal compris … je ne dis pas que c'est impossible, je n'ai juste aucune idée de comment on peut faire ça en dehors d'une machine virtuelle style JVM (et ça m'intéresse de savoir)
[^] # Re: Le choix est simple
Posté par totof2000 . Évalué à 1.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).
[^] # Re: Le choix est simple
Posté par barmic 🦦 . Évalué à 4.
Le fait que ça n'utilise pas de langage à gc n'indique pas que ce n'est pas un cas d'usage qui fonctionne avec un gc.
Parce que ça n'a rien à voir. On amalgame souvent machine virtuelle, compilation jit, garbage collector,… mais ce sont des choses différentes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le choix est simple
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Alors là clairement non, la GC, est le 1er élément de "virtualisation" possible. Alors tous les langages interprètés, tous les langages avec compilation JIT et bien sûr les langages avec JVM l utilisent. En compilé je vois Go et Ada à ma connaissance. En fait les seuls langages sans encore utilisé sont Cobol, Pascal, C, C++… bref des langages utilisé que dans des services très critiques niveau perfs, pas la majorité du code écrit chaque jour.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Le choix est simple
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Euh… stackoverflow.com/questions/1691059 (ta connaissance du langage Ada, utilisé pour des trucs critiques, n'est pas en accord avec celle de gens qui l'utilisent…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le choix est simple
Posté par woffer 🐧 . Évalué à 4.
C'est dommage, pour moi le Go est très bon quand je travaille pour des applications back-end qui font principalement de l'entrée/sortie (exposant/consommant une API, BDD …) et qui tournent dans des pod très contraints en ressources (quelques dizaines de milli-cpu ou centaines de Mo de RAM). Ce qui représente la majorité de mon travail depuis plus de 5 bonnes années.
Dans ce contexte, Go me permet très facilement d'avoir une application performante et cela sans aucune configuration.
Rust, pour moi, est plus délicat à mettre en œuvre dans ce contexte. Il faudra nécessairement gérer les entrées/sorties en asynchrones car je ne peux pas bloquer mon thread car il a bien d'autres choses à faire que d'attendre :)
[^] # Re: Le choix est simple
Posté par ff9097 . Évalué à 2.
Go a été conçu pour ça. Rust non
[^] # Re: Le choix est simple
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 09 décembre 2021 à 21:29.
Oui mais quand tu compare a Java ou il manque toujours une dépendance quand ce n est pas carrément la JVM qui est incompatible…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Ben pour ma part...
Posté par xcomcmdr . Évalué à 1. Dernière modification le 09 décembre 2021 à 22:19.
J'ai un langage qui me va très bien.
Il a commencé sa vie sous le nom de COOL (C like Object Oriented Language) aujourd'hui entièrement libre et multiplateforme, et avec la compilation native en vue il est encore plus cool.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Rust versus Go : round 1, fight !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
On ne pourrait mieux dire :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.