Go et Rust sont deux langages qui sont souvent comparés l'un à l'autre. Et cela vient en partie du fait qu'ils sont tous les deux des langages vus comme des remplaçants du C et du C++. Pourtant, ces deux langages sont relativement différents et n'ont pas empruntés les mêmes caractéristiques au C et au C++.
Sur le plan philosophique, C est souvent vu comme un langage assez simple (peu de mots-clés, peu de concepts compliqués comme la surcharge d'opérateurs, un rythme d'évolution assez lent) alors que le C++ est vu comme un langage puissant, avec plein de fonctionnalités avancées (l'héritage multiple, les templates, les espaces de noms, etc.) décrites dans les milliers de pages de la spécification. Vu comme ça, Go a clairement repris la simplicité (peut-être en partie imaginée) du C, et Rust partage cette recherche de puissance avec des abstractions sans coûts (en termes de performances) avec le C++.
Mais si on passe sur l'usage, on peut assez facilement arriver à l'inverse. Go a été écrit au départ pour remplacer le C++ tel qu'il est utilisé chez Google, c'est-à-dire pour écrire des services réseaux. Et pour ce cas d'usage, le facteur limitant est plutôt les entrées-sorties que la recherche de performances absolues (mémoire, CPU). Les créateurs de Go ont ainsi pu choisir d'avoir un Garbage Collector et des threads légers, les goroutines.
À l'inverse, les développeurs de Rust ont choisi d'avoir un runtime très léger. Cela pourrait permettre à Rust d'être utilisé sur des domaines souvent réservés au C et où Go a peu de chances d'arriver : système d'exploitation (redox-os), bibliothèques pouvant être utilisées dans de nombreux langages, extensions pour d'autres langages (python, ruby). En bonus, cela a permis à Rust d'être transpilé vers du Wasm plus tôt que Go, et sans peser quelques centaines de ko pour un Hello World.
Au final, j'ai l'impression que Go et Rust n'attirent pas le même public : plutôt haut-niveau pour Go et bas-niveau pour Rust. Par exemple, pas mal de développeurs de langages de scripts (Ruby, Python, NodeJS) sont passés à Go pour les performances et la concurrence. À l'inverse, Rust me semble très compliqué à aborder sans un bagage technique conséquent et au moins une expérience dans un langage bas-niveau (souvent le C ou au moins des notions de C++).
Ni Go ni Rust ne remplaceront complètement le C et le C++, mais ils ont chacun un chemin où ils peuvent être couronnés de succès. Pour Go, c'est déjà le cas de part son utilisation massive dans les services réseaux et les outils devops. Pour Rust, la marche est plus haute mais s'il parvient à avoir moins de failles dans des éléments critiques de notre informatique au quotidien (noyau, bibliothèques largement utilisées à la OpenSSL ou Image Magick, navigateurs web, etc.), ça serait formidable.
# Aucun !
Posté par rewind (Mastodon) . Évalué à 10.
C est là depuis longtemps et occupe une place qu'aucun autre langage ne peut prendre. C est la lingua franca des langages de programmation puisque quasiment tous les autres peuvent appeler une fonction C alors que l'inverse est très souvent faux. C a un écosystème énorme comparé à Go ou Rust. C est omniprésent dans l'embarqué et le premier compilateur présent sur une nouvelle architecture est quasiment toujours un compilateur C. Bref, vouloir prendre la place de C, c'est un doux rêve. Ce qui ne veut pas dire que ces langages (Go et Rust) n'ont pas un intérêt propre.
[^] # Re: Aucun !
Posté par gaaaaaAab . Évalué à 10. Dernière modification le 10 septembre 2018 à 02:02.
ça, c'est juste de l'interface. On peut imaginer un monde dans lequel tous les langages comprennent et sont capables de fabriquer un truc compatible C, sans qu'il n'y ait une seule ligne de C nul part.
oui, mais comme tu viens de le rappeler, (quasi) tous les langages sont capables d'appeler du C. Ils peuvent hériter (sous certaines conditions) d'une grande partie de l'écosystème du C.
Je ne pense pas qu'un seul langage puisse venir remplacer le C sur tous ses domaines d'usage. Par contre, j'arrive à imaginer que le C soit remplacé au fil de l'eau par des langages spécialisés sur de nombreux domaines, et dans d'étranges éons, sur tous.
[^] # Re: Aucun !
Posté par Yth (Mastodon) . Évalué à 10.
« That is not dead which can eternal compile, And with strange aeons even C may die »
[^] # Re: Aucun !
Posté par Renault (site web personnel) . Évalué à 9.
Je pense qu'il y a toujours un domaine où le C sera difficile à remplacer même pour un langage dédié : langage d'assembleur plus haut niveau (ou abstrait).
Car le C a un avantage indéniable sur le sujet qui le rend toujours aussi attractif dans le milieu et que son éventuel remplaçant devrait conserver (et donc en faire un C à peine modifié). Le C est en effet un langage très simple (mais difficile à maitriser). Peu de mots clés, abstraction très légère, norme peu contraignante laissant de grandes libertés aux compilateurs et aux OS sur ses cas limites. Tout cela permet en C d'être facile à porter sur une nouvelle architecture matérielle. Et la taille de sa norme (environ 800 pages contre le double pour le C++) est également un atout en ce sens.
Pour bénéficier de cet avantage, son remplaçant devrait être aussi concis et simple à mettre en oeuvre. Et je doute que cela permette l'émergence d'un langage suffisament intéressant pour le remplacer.
[^] # Re: Aucun !
Posté par robin . Évalué à 5.
Pour moi les IR des compilateurs ont exactement ce rôle. Si je fabrique une nouvelle plateforme, j'ai le choix entre créer un nouveau compilateur C de toute pièce, ou de créer uniquement un back-end llvm/gcc/… et ainsi porter gratuitement un grand nombre de langage sur ma nouvelle plateforme. Idéalement tout les compilateurs partageraient le même IR (pour n'avoir qu'un seul back-end à écrire).
bépo powered
[^] # Re: Aucun !
Posté par Renault (site web personnel) . Évalué à 3.
Sauf qu'en vrai beaucoup de petites / nouvelles architectures reposent sur des solutions maisons. Car contribuer à GCC ou LLVM c'est un savoir faire qu'ils n'ont souvent pas et c'est assez complexe car le code est gros avec un gros historique.
Du coup tu te retrouves avec des petits compilateurs C (d'ailleurs rarement compatible avec la norme du C mais avec un sous ensemble). Bien avant que les gros compilateurs multi-langages en tirent parti. Et entre temps cela a permis de porter des applications en C et d'en écrire avant que le moindre code C++ puisse être portée.
[^] # Re: Aucun !
Posté par Gof (site web personnel) . Évalué à 10.
Rust à aussi ses chances en temps que language d'assembleur de haut niveau.
"simple" n'est pas très objectif, et est aussi assez limitant. D'ailleurs, le brainfuck est encore plus "simple" (et difficile à maitriser). Pourtant il ne prendra jammais la place du C.
Rust a moins de mot clés que C (35 mot clé en Rust, 44 en C)
Pareil pour Rust.
Mais rends la tâche du programmeur extrêmement difficile car il est quasiment impossible de faire un programme un peu complexe qui n'a pas une « undefined behavior ».
En effet. Mais comme il a été déjà dit, écrire un frontend pour LLVM n'est pas très dificile non plus.
[^] # Re: Aucun !
Posté par robin . Évalué à 2.
Un back-end ;) Les front-ends c'est pour les nouveaux langages !
bépo powered
[^] # Re: Aucun !
Posté par David Delassus (site web personnel) . Évalué à 1.
Je vais avoir besoin de savoir ce que tu appelle programme un peu complexe et aussi d'exemple d'undefined behavior qu'on ne peut éviter.
Pour info, voici la liste des undefined behavior en C99 : https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1
J'ai pas tout lu (par flemme j'avoue) donc je vais parler de mémoire. Il me semble que les undefined behavior du C correspondent à des cas très précis et le plus souvent documenté par l'implémentation.
Quand on fait du bas niveau, il ne faut pas se limiter à la spec du langage, mais il faut aussi se servir de la spec du compilo et du hardware. Ne pas le faire, c'est se tirer une balle dans le pied (après, j'avoue qu'il y a beaucoup d'unijambiste dans le monde du dev).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Aucun !
Posté par Aluminium95 . Évalué à 2.
Bah, ça ressemble drôlement à des "undefined behaviours" de C ce que tu décris là… Ou alors ton compilateur ne respecte pas le standard. Ça doit d'ailleurs répondre à ton propre questionnement : "Je vais avoir besoin de savoir ce que tu appelle programme un peu complexe et aussi d'exemple d'undefined behavior qu'on ne peut éviter."
[^] # Re: Aucun !
Posté par Anthony Jaguenaud . Évalué à 5.
Ce n'est pas forcément un non respect du standard, j'ai eu le cas d'une fifo hardware indexée avec un 16 bits.
Je récupérais la valeur du pointeur comme suis :
l'adresse du registre étant
volatile, etc.Mais le CPU sur lequel j'étais, faisait des accès 8 bits. Compilé de cette façon :
Au début, le registre contient
0180donc on lit d'abord la partie basse (little endian) ==>val == 80Le registre devient
0210car le hard à reçu un message, donc on extrait02pour obtenirval == 0280. Ca n'arrivais pas souvent, mais aléatoirement entre 5 minutes et 1h30.J'ai fini par écrire ça :
C'était pourtant un CPU 32bits, mais configuré avec des accès mémoire 8bits. Grrrr. Sur ce genre de problème, je ne suis pas certain que Rust ou Go apporte quelque chose. Ai-je tort ?
[^] # Re: Aucun !
Posté par Gof (site web personnel) . Évalué à 3. Dernière modification le 12 septembre 2018 à 15:07.
C'est le registre qui doit être volatile. Pas son adresse.
En faisant
(uint16*)(adresse_registre)tu enlève le volatile du registre.Le code correct serait peut-être:
(Ton code pourrait encore avoir le problème si tu a la même race condition deux fois de suite)
[^] # Re: Aucun !
Posté par Anthony Jaguenaud . Évalué à 2.
Je n'ai volontairement pas remis la définition.
Ne t'inquiète pas, le code tourne, c'était un exemple refait de tête… Juste pour dire qu'on ne peut pas toujours s'affranchir de savoir comment ça se passe en bas… dans ce cas, c'est juste le compilateur qui décide de faire deux accès car le CPU peut faire des accès 8bits ou 32bits.
[^] # Re: Aucun !
Posté par Gof (site web personnel) . Évalué à 5.
Un programme un peu complexe c'est à dire tout programme un peu plus utile que hello world.
Et des undefined behavior c'est, par exemple, overflow de signed integer, ou déréférence d'un pointeur invalide, ou un cast sur un mauvais type, ou une data race.
Ne pas confondre « undefined behavior » et « implementation defined behavior ».
Si tu fait du C, la spec du hardware n'a aucun intérêt, sauf si tu utilise des extension genre
asmou autre intrinsics. Et en particulier, si tu crois que la spec du hardware rends les undefined behavior prévisible, tu fait une belle erreur.À lire: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
[^] # Re: Aucun !
Posté par Gof (site web personnel) . Évalué à 2. Dernière modification le 11 septembre 2018 à 23:22.
Bon, je me reponds à moi même pour préciser que la spec a quand même un intérêt pour faire du code performant. Il faut avoir une idée de la taille des cache et tout ça. Mais c'est inutile pour éviter les undefined behaviour.
Undefined behavior ça corresponds a une interdiction dans le code de la route. Tu pourras tant que tu veux dire a l'agent qui t'arrête après avoir rouler à 180 km/h ou brûler un feu rouge, que tu as étudié le manuel de ta voiture et que il n'y avait personne, mais tu te prendra quand même une amande.
[^] # Re: Aucun !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Une amande ou une prune ?
[^] # Re: Aucun !
Posté par groumly . Évalué à 10.
Le problème c’est pas tant que les undefined behavior soient documentés ou pas, mais que:
- il y en a beaucoup, trop pour tout se rappeler de mémoire (191 si j’en crois le lien donne au dessus)
- il sont parfois particulièrement subtile et facile à rater
Par dessus ca, rajoute le côté très “tu fais vraiment ce que tu veux, mais c’est toi qui tient la tronçonneuse” du C, même sur des choses documentées, et effectivement, il est pratiquement impossible d’ecrire un programme non trivial qui n’ait pas un bug ou deux critique.
Si tu me crois pas, regarde juste le nombre de faille de sécurité critique qui se résume à un simple “ah, ben zut, on a merde sur une ligne de code, c’est con mais c’était pas facile à voir” ces 10 dernières années.
Et comment tu fais le jour ou le compilo change sa spec sur les undefined behavior?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Aucun !
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
https://www.graalvm.org/ ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Aucun !
Posté par gaaaaaAab . Évalué à 4.
je pensais plus aux langages qui produisent du code natif. Pour les langages interprétés ou ayant une VM, c'est plus beaucoup facile.
Je ne connaissais pas graalvm. Ça pourrait être intéressant. Dommage qu'Oracle ait ses sales pattes dedans …
[^] # Re: Aucun !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Intéressant apparemment ; mais ça semble être pour les langages interprétés ou créant du code virtuel (byte-code) non ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Aucun !
Posté par barmic . Évalué à 2.
[^] # Re: Aucun !
Posté par nico4nicolas . Évalué à 1. Dernière modification le 10 septembre 2018 à 11:21.
Ce commentaire est très juste et je pense que le choix du titre est mal choisi. Question vocabulaire, "concurrent" aurait été un peu plus juste que "remplaçant" mais il y a certainement mieux. En tout cas, le contenu rectifie cette erreur d'expression en allant dans le sens du commentaire :
[^] # Re: Aucun !
Posté par liberforce (site web personnel) . Évalué à 10. Dernière modification le 10 septembre 2018 à 12:01.
Le monde a changé. La sécurité informatique prend de plus en plus d'importance. La semaine dernière au JT de France 2 on parlait de sécurité informatique dans les appareils médicaux type pacemakers, d'hôpitaux piratés avec demande rançon pour ne pas dérégler les pompes à morphine, etc. On parle de multiplication d'objets connectés, on ne peut plus fier aux données qui rentrent dans un système (par exemple pour un parser), les vecteurs d'attaque se multiplient, et les failles de sécurité avec.
Ensuite, le matériel a changé: tu as plus de coeurs, il faut réussir à paralléliser les traitements pour tirer le maximum de performances du matériel utilisé, tout cela sans provoquer de fuite mémoire, de deadlock, d'écrasement de tampon, etc. En C tu peux tout faire, mais tu peux aussi coder comme un goret, et ignorer les valeurs de retour.
Alors bien sûr, tu peux faire du fuzzing, de l'analyse statique de code, passer du valgrind, du ASAN sur ton code C… Mais ça prend du temps, des ressources (que les projets libres souvent n'ont pas). Alors si un langage te promet d'attraper les erreurs les plus communes à la compilation plutôt qu'à l'exécution ou pendant d'hypothétiques phases de check que tous les développeurs sont loin de mettre en place, bin personnellement je pense que C a du soucis à se faire. Certes, on fera encore du C pendant longtemps, mais se dire que parce qu'il est établi, il ne craint rien, c'est se bercer d'illusions à mon avis.
On pourrait dire que ce qui va freiner, c'est la migration, parce qu'il faut tout réécrire d'un coup, mais même pas. Librsvg est migrée de C à Rust petit bout par petit bout depuis quelques mois. Une partie est en C, une autre en Rust, pas besoin de tout réécrire en une seule fois. Je lisais encore ce matin un article d'un gars qui se met à écrire mtpng, un encodeur png plus parallèle. Entre C, C++ et Rust… Bin il a choisi Rust.
Bref, que ce soit Rust, go ou autre chose, il y a un vrai besoin d'un langage qui permette de relever les défis des décennies à venir. Le C te permet de tout faire, y des atrocités, volontaires ou pas. Et je pense qu'il y a pas mal de gens qui attendent la relève.
[^] # Re: Aucun !
Posté par _seb_ . Évalué à 5.
Le monde a changé parce que l'informatique a changé (ou l'inverse ?).
De mon point de vue, la langage est une chose, son utilisation une autre.
J'attends de l'utilisation d'un langage de programmation tout un écosystème qui me permette aisément de me concentrer sur ce que je souhaite faire avec ce langage.
Rust possède un système de dépendance plutôt sympa (Cargo). Le nombre de biblothèques en Rust augmente petit à petit.
Cargo permet d'introduire dans son projet pas mal d'outils tiers (https://github.com/rust-lang/cargo/wiki/Third-party-cargo-subcommands) qui facilite la vie de développeur.
Cargo permet de lancer les tests unitaires.
Cargo permet de générer la documentation.
Cargo permet de spécifier les options de compilation.
La configuration de Cargo est réunie au sein d'un même fichier.
etc.
Cargo me semble beaucoup plus simple qu'un fichier de type pom.xml (Maven) que l'on retrouve dans le monde Java ou package.json dans le mode JS Node.
L'adoption du langage passera sans nul doute par la possibilité d'avoir un éditeur (IDE) digne de ce nom. C'est une demande forte de la communauté en 2017 (https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html - Areas for Improvement) et le sera aussi, je pense, en 2018.
Des avancées sont déjà en place mais j'attends mieux de la part de la communauté: un IDE qui intègre le debuggeur, l’analyse statique (en partie faite par le compilateur), la coloration syntaxique, l’auto-complétion, la documentation sous forme de tooltip dans le code, la possibilité de faire du refactoring facilement, etc.
Bref, uniformiser l'écosystème du langage me semble primordial pour la réussite de l'adoption de Rust.
[^] # Re: Aucun !
Posté par Sufflope (site web personnel) . Évalué à 4.
Du très peu que j'en ai vu, IntelliJ IDEA + le plugin Rust fait bien le boulot.
[^] # Re: Aucun !
Posté par xcomcmdr . Évalué à 3. Dernière modification le 10 septembre 2018 à 17:03.
Rust avec la puissance de Visual Studio… Le rêve !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Aucun !
Posté par xcomcmdr . Évalué à -6.
Contenu pertinent (ça parle de Rust) mais on parle de VS : ça moinsse.
Vous êtes pathétiques.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Aucun !
Posté par totof2000 . Évalué à 10. Dernière modification le 10 septembre 2018 à 17:11.
Si c'était aussi simple, ADA aurait remplacé le C depuis longtemps.
[^] # Re: Aucun !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 11 octobre 2018 à 17:02.
Tiens, Ada le fait ça. Mais Ada n'a pas bénéficié du marketing de Go ou Rust. Bon, ceci dit les quatre ne sont pas comparables (on peut leur trouver des points communs ou des différences, des avantages ou des inconvénients comparatifs, faire des choses plus facilement et rapidement, faire les mêmes choses avec des degrés d'effort différents, etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Aucun !
Posté par reno . Évalué à 4.
De toute manière au niveau langage, un remplaçant du C ça serait plutôt Zig que Go (qui a un GC) ou Rust (qui est un langage très complexe qui concurrence plutôt le C++ que le C).
Il y a Jai qui devrait être intéressant aussi vu l'expertise de son concepteur mais bon ça il faut encore attendre pour avoir du concret.
[^] # Re: Aucun !
Posté par Tit . Évalué à 1. Dernière modification le 10 septembre 2018 à 14:46.
pourrais-tu en dire plus sur zig ?
d'après https://www.scriptol.fr/programmation/liste-langages-programmation.php
c'était une blague ?
[^] # Re: Aucun !
Posté par reno . Évalué à 3.
J'ai envoyé le lien sur zig, mais voici un lien plus précis https://andrewkelley.me/post/intro-to-zig.html
Il ne s'agit en aucun cas d'un langage "humoristique": son concepteur a arrêté son travail pour se consacrer à ce language..
[^] # Re: Aucun !
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Tout comme SamWang a arrêté son traitement pour se consacrer à Zino !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Aucun !
Posté par reno . Évalué à 2.
? Euh, tu parles de quoi?
[^] # Re: Aucun !
Posté par EchoPapaMike . Évalué à 1.
Le site web de Zig , https://ziglang.org .
Il faut savoir que le compilateur Zig repose actuellement sur LLVM .
Si vous utilisez Zig je vous invite a devenir mécène a travers sa page Patreon https://www.patreon.com/andrewrk/ ou sa page Liberapay
https://en.liberapay.com/andrewrk/ .
[^] # Re: Aucun !
Posté par plr . Évalué à 10. Dernière modification le 10 septembre 2018 à 16:12.
Je suis d'accord en grande partie avec Bruno car il précise bien que le C ne disparaîtra pas mais je trouve qu'il omet un grand pan de l'industrie.
Pour rajouter un élément à la réflexion, dire que le langage C va être remplacé sans y mettre plus de bémol peut indiquer un manque de connaissance du marché global et des applications du langage C.
Pour celà, je vous laisse regarder les parts de marché/volumes des microcontrôleurs(uC) 8/16bits vs 32bits et même l'ensemble des microcontrôleurs vs processeurs (x86, server, etc) pour comprendre que le C n'est pas prêt de disparaître: c'est actuellement environ 50% embarqué vs processeurs pour PC/serveurs.
Le prix d'un uC 8/16bits étant < 1$, on ne voit pas pourquoi mettre des uC ou processeurs dont le coût des composants est > 10/15$ (car il faut rajouter de la ram, le pmic, du stockage…); sur des volumes de >10k pièces, celà ne se justifie pas. De plus, même avec des uC 32bits, on réduit le coût du produit en réduisant les tailles des mémoires, dont exit les langages qui ne génèrent pas du code ultra-optimisé, et ceux qui ne peuvent permettre les certifications de sécurité (e.g. SIL)
Et pour ces raisons (mais pas que), le langage C est encore le plus rencontré dans l'embarqué: plus rapide à développer qu'en assembleur et le footprint est plus réduit qu'avec des langages plus "évolués" (je préfère utiliser les termes "adaptés"). Du temps de mes études (fin des années 90), on nous disait que les processeurs/langage Java allaient envoyer le C aux oubliettes… ok, pourquoi pas… :D
Dans la plupart des machines à laver (les entrées/milieux de gamme), ce sont encore des uC 8/16bits, dans les capteurs des 8/16bits, dans les compteurs du 16bits, etc.
Par contre, dans d'autres applications, je suis assez d'accord avec le constat, la meilleur indication que j'ai à mon échelle est que j'ai appris successivement le perl, le python (et bientôt go?) pour générer du code sur les plateformes non-embarquée; Que j'embarque du linux plus rapidement/facilement sur les plateformes embarquées qui font de l'agrégation de données avant de les envoyer vers des serveurs… euh… ha oui, drivers toujours en C ;-)
[^] # Re: Aucun !
Posté par flavien75 . Évalué à 5. Dernière modification le 10 septembre 2018 à 16:38.
La comparaison 16bits vs 32bits n'est plus d'actualité depuis un moment, en particulier depuis l'arrivée des Cortex-M0 (compter 1 à 3 € acheté par 100)
Pour reprendre le vocabulaire de ARM, il faut plutôt comparer les CPU applicatifs (Cortex-A, Intel Core-i, …) destinés à faire tourner un système d'exploitation et les microcontrôleurs intégrant la totalité de la mémoire nécessaire (Cortex-M, 68HC12, AVR, … d'autres dont même le jeu d'instructions est sous NDA)
Enfin ça ne retire rien au fond de ton propos loin de là.
Les vrais naviguent en -42
[^] # Re: Aucun !
Posté par plr . Évalué à 5. Dernière modification le 10 septembre 2018 à 17:14.
alors oui, entièrement d'accord pour la partie ARM.
Par contre, là où je ne suis pas d'accord avec toi, 16bits vs 32bits, si, si, je persiste, je signe, je prouve et je m'en félicite… euh, je m'emballe là, non? :D
Microcontrôleurs 16bits qui sont plus intéressants que les cortex 32bits: gamme des MSP430 chez TI, chez microchip, il y a les équivalents: ils intègrent des fonctions ADC/CAN/bus/etc plus adaptées que sur leur gamme ARM. On les utilise dans le comptage (eau, gaz, élec) par exemple, Linky étant une exception (ils utilisent un STM10 qui est un 32bits).
Pour des applications plus générales, je pense que les cortex sont intéressants. Dans une sous-partie de mon domaine (automates programmables), c'est une solution "batard" que les uC 32bits: trop chers/complexes pour des fonctions simples, pas assez de possibilités pour des fonctions plus évoluées.
Par exemple, on a des produits ou il doit y avoir une isolation électrique avec des bus d'échange donc 2 uC (au minimum), on va ajuster au minimum la puissance/taille/consommation/coût/complexité car sinon on multiplie par 2 ces critères là et ça ne passe pas le marketing.
Mais la discussion de la disparition des uC 8/16/32bits est un vieux loup de mer!
[^] # Re: Aucun !
Posté par flan (site web personnel) . Évalué à 3.
Et du coup, dans 200 ans, nous devrions être encore au C ?
Bien évidemment qu'un jour le C sera remplacé (même s'il y aura certainement quelques usages résiduels, tout comme on peut encore trouver du Windows 3.11 de nos jours).
Au passage, le C sera peut-être remplacé par le Swift, en tout cas chez Apple. Il a en tout cas été créé sur mesure pour ce faire.
[^] # Re: Aucun !
Posté par totof2000 . Évalué à 6.
Bah, si le C, malgré tous ses défauts, est suffisamment adapté pour développer, on utilisera encore le C.
Personnellement, je constate que la plupart des "défauts" et reproches que l'on fait au C peuvent être également des points forts : tout dépend dans quel domaine on l'utilise.
Les pointeurs par exemple : personne n'aime les pointeurs en général, sauf les développeurs très ba s niveau qui auraient du mal à faire sans. Mais je comprends que le développeur d'un service web ne veuille pas s'en soucier. Idem pour l'allocation de la mémoire devant être gérée par le développeur : c'est certes une contrainte, mais cette contrainte se révèle parfois un atout. Tout dépend à quel niveau on se place.
# Je crois qu'il manque un morceau de phrase
Posté par Anonyme . Évalué à 10.
J'ai eu du mal à comprendre cette tournure. Il semble manquer un verbe du genre "raisonner à l'inverse", non ?
[^] # Re: Je crois qu'il manque un morceau de phrase
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Effectivement, j'ai eu un raté. J'ai corrigé la phrase en :
[^] # Re: Je crois qu'il manque un morceau de phrase
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Ça amène la question suivant : faut-il remplacer le français par une langue moins susceptible d'erreur, d'oubli et autres ratés ?
</troll># Machine virtuelle ?
Posté par MrBidon . Évalué à 0.
Je m'intéresse a ces deux nouveaux langages, car je pense qu'ils ont un avenir radieux dans ce monde virtuel où l'on paye au nombre de core et de RAM consommées.
Bref, je ne me suis pas encore attardé sur Rust, et plutôt intéressé a Go. J'étais tombé sur un benchmark où l'on mettait en évidence la "lourdeur" de la VM de go vs le c. Quid de Rust dans ce cas ?
[^] # Re: Machine virtuelle ?
Posté par Boiethios (site web personnel) . Évalué à 6. Dernière modification le 10 septembre 2018 à 09:24.
Go n'utilise pas de VM : https://stackoverflow.com/a/31281706/4498831 pas plus que Rust.
Go a un garbage collector que n'a pas Rust, et c'est sans doute là-dessus que se faisait le benchmark.
[^] # Re: Machine virtuelle ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Pas de VM au sens « environnement d'exécution d'un langage », mais VM au sens « hyperviseur ». Le message auquel tu réponds fait juste remarquer qu'un langage efficace à l'exécution réduit la facture d'hébergement cloud. Bon, au final, dans un environnement pas virtualisé, on payait aussi au CPU et à la RAM parce qu'un gros serveur coûtait plus cher qu'un petit, hein … ;-)
[^] # Re: Machine virtuelle ?
Posté par Clément David (site web personnel) . Évalué à 5.
Effectivement, Go comme Rust sont des langages compilés ciblant le processeur. On parle alors simplement de
runtimeplutôt que deVirtual Machine. Une VM (comme la JVM ou CLR) possède aussi unruntimemais interprète (ou JIT) à l'exécution le code en ciblant le processeur sur lequel la VM est lancé et ajoute parfois d'autres contraintes (authentification du code, mode d'exécution limité, protection mémoire, etc…).Comme bien précisé dans le journal, tout les langages ont un
runtimequi fournit plus ou moins de choses. Par exemple, le C offre très peu de fonctions par défaut et la stdlib (comme la libm) est désactivable ce qui en fait un langage très pratique dans le petit embarqué (certains processeurs gère très mal l'allocation dynamique très utilisé pour les chaines de caractères par exemple).[^] # Re: Machine virtuelle ?
Posté par MrBidon . Évalué à 2. Dernière modification le 10 septembre 2018 à 17:13.
Désolé pour le mauvais terme, je parlais bien du garbage collector (pas taper :)) est-ce que Rust possède aussi un runtime de ce genre en tache de fond ?
[^] # Re: Machine virtuelle ?
Posté par Bruno Michel (site web personnel) . Évalué à 6. Dernière modification le 10 septembre 2018 à 17:28.
Non, Rust n'a pas de Garbage Collector.
# Domaines différents
Posté par Lucky Seven . Évalué à 6. Dernière modification le 10 septembre 2018 à 08:33.
Je vois bien Rust remplacer C++, mais je vois plutôt Go entre C++ et Python.
Le cas d'usage de Go, je pense, c'est lorsque l'on veut un langage simple avec un large choix de librairies comme pour Python, mais que l'on a besoin de plus de performances ou que l'on veut distribuer un binaire sans se soucier de ce qui est déjà installé sur la machine cible.
Par contre, je n'imagine pas que l'on puisse écrire des outils pour Gnu/Linux écrits en Go et mis en repo, simplement parce qu'ils sont compilés statiquement et que le plus petit pèse au moins 6Mo.
[^] # Re: Domaines différents
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Dans ma dépêche Des alternatives à grep, ls et find, on m'a fait remarqué que certains outils en ligne de commande écrits en Go ont un certain succès :
[^] # Re: Domaines différents
Posté par Lucky Seven . Évalué à 2.
Oui, mais du coup on n'est plus dans une approche minimaliste. D'ailleurs dans ceux que tu cites, seul fzf est disponible dans le repository de ma distribution.
Pour fzf, je regarde les infos du paquet :
taille 886k. Étonné, je l'installe ; après un petit ls sur le binaire il fait 2,9M, ce qui est déjà particulièrement bien optimisé pour du Go. En tout cas il semble intéressant, je vais peut-être le garder :-)# Go -> Rust
Posté par Ririsoft . Évalué à 8.
Après avoir adoré Go je suis passé au Rust et je n'ai aucune envie de revenir en arrière, pour les raisons suivantes :
Rust est plus compliqué (Gestion de la mémoire, Generics, …) mais passé la barrière on se rend compte à quel point Go est trop simple, trop ennuyeux: une fois passé la magie de Go, mes programmes ont tendance à tous se ressembler, j'avais l'impression de toujours faire la même chose. C'est bien du point de vue industriel, mais c'est barbant du point de vue artisanal.
Le mode de développement de Rust est très ouvert, comme Mozilla sait si bien le faire. On retrouve le même esprit que l'on peut avoir dans de nombreux projets libres. Go, quoiqu'on en dise, est verrouillé par Google. La barrière pour contribuer à Rust est beaucoup moins élevée que celle pour contribuer à Go.
Le champ d'application de Go me semble plus restreint que celui de Rust, entre autre à cause du garbage collector et de la librairie standard embarquée. Alors que je vois bien Rust corroder les noyaux et l'user space dont les environnement de bureaux (Gnome y songe).
[^] # Re: Go → Rust
Posté par barmic . Évalué à -10.
MDR rust est le premier projet que Mozilla arrive a gérer. Le nombre de techno qu'ils n'ont pas sut tenir communautairement est affolant (XUL, gecko,…). C'est génial qu'ils arrivent à le faire avec rust, mais c'était pas gagné au départ.
[^] # Re: Go → Rust
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Il est beau ce FUD qualité OR.
Au sujet de Gecko, il y a eu certes une période où la communauté était moins prise en compte, c'était pendant la période du développement de FirefoxOS, dû a des problèmes de politique de management en interne. M'enfin cette période est terminée depuis pas mal de temps. En tout cas, ils n'ont jamais empêché quiconque de contribuer.
Au sujet de XUL : si tu parles du langage ou de XulRunner, je ne vois pas de quoi tu parles. XUL a plus de 20 ans, maintenant dépassé par le HTML (beaucoup d'innovations de XUL ont été migré en HTML, et sont devenus le shadow DOM, les WebComponents, Flexbox model en CSS et j'en passe). Ils avaient bien essayé de le proposer au W3C il y a une dizaine d'année mais les autres membres ont refusé parce que chacun avait un langage similaire et concurrent (XAML pour MS, cheupluquoi du coté de Adobe Air etc..).
Quoi qu'il en soit, jusqu'à la décision d’arrêter la prise en charge des extensions réalisées en XUL, il n'y a jamais eu de problème à contribuer sur le XUL ou de l'utiliser. Et si maintenant XUL est mort, c'est pas parce "qu'ils n'ont pas su tenir communautairement", mais parce qu'il y a eu des décisions de changements d'architecture, qui vont dans le bon sens. Ok, ça a fait râler quelques devs d'extensions (moi le premier), parce que il y a des choses que l'on ne peut plus faire dans les webextensions (lire ou écrire des fichiers par exemple), mais bon, c'est mieux pour l'utilisateur quand même (coté sécurité et coté compatibilité avec les autres navigateurs) et je le comprends tout à fait.
[^] # Re: Go → Rust
Posté par barmic . Évalué à 1.
Très peu de projets sont sortis de Mozilla et on eu une vie en dehors de Mozilla. XUL a très peu pris, gecko aussi, le maff, Persona, Firefox OS,… Tous ces trucs ce sont des choses qui n'ont pas réussi à prendre leur envole. Je ne parle pas d'avoir une gouvernance ouverte, mais d'avoir une vie en dehors de Mozilla.
Mozilla a vraiment du mal a faire des choses qui soient véritablement utilisées ailleurs que chez eux, mais ils s'en sortent de mieux en mieux et je trouve ça génial. C'est juste qu'en parler comme si ça coulait de source, je trouve ça rigolo. Mozilla c'est une suite de projets qui on eu pas mal de mal (et qui pour beaucoup en sont mort) et quelques projets à succès (voir gros succès).
Je ne dis pas ça contre Mozilla, j'aime vraiment ce qu'ils font et je suis généralement d'accord avec leur choix.
[^] # Re: Go → Rust
Posté par Bruno Michel (site web personnel) . Évalué à 10.
On peut quand même citer PDF.js, asm.js (et donc web assembly) et emscripten comme projets nés chez Mozilla et qui ont eu une vie ailleurs.
[^] # Re: Go → Rust
Posté par Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 11 septembre 2018 à 10:01.
Note quand même que ta première réaction faisait écho à "Le mode de développement de Rust est très ouvert, comme Mozilla sait si bien le faire."
On attend toujours que tu nous expliques en quoi un mode de développement ouvert est synonyme de "réussite systématique".
[^] # Re: Go → Rust
Posté par Olivier . Évalué à 7.
Pour lire, tu peux utiliser XMLHttpRequest.
Pour écrire, tu peux tricher et utiliser l’API “downloads”. Tu crées un Blob en mémoire que tu vas télécharger depuis la mémoire.
Voilà par exemple ce que j’utilise pour ce faire :
export: function () {
let xBlob = new Blob([ JSON.stringify(oObject) ], {type: 'application/json'});
let sURL = URL.createObjectURL(xBlob);
browser.downloads.download({ filename: "nom_de_fichier.json", url: sURL, saveAs: true });
}
Ça m’a valu des utilisateurs soupçonneux qui se demandaient pourquoi j’avais besoin de l’API downloads, mais ça fonctionne. ;)
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Oui, et la manière dont dep a été écarté au profit de vgo l'a très clairement montré. Cf https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html entre autres.
[^] # Re: Go -> Rust
Posté par wilk . Évalué à 0.
Je trouve au contraire que l'approche go module est beaucoup plus compatible avec ce que souhaitait la communauté que Dep d'une part et a beaucoup évolué par rapport aux nombreux retours (plutôt très positifs) de la communauté.
Je me souviens très bien qu'au départ de Dep il y a eu une grande frustration dans la communauté de voir qu'on abandonnait la philosophie Go de chercher la simplicité sans forcément faire comme les autres. Au point de carrément décréter qu'il n'y aurait qu'une seule "expérimentation officielle", fusse-t'elle organisée par des personnes de la communauté. Qui plus est sous forme de réunions privées comme ton lien le montre… Je pense que l'erreur est partie de là alors qu'on avait à l'époque tout un tas d'expérimentations diverses beaucoup plus propices à faire émerger des idées nouvelles.
Chacun peut se faire son opinion sur les issues github, d'une manière plus transparente que les retours de discussions privées où il y a eu beaucoup de contradictions assez stériles.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Je ne critique pas le résultat. C'est possible que les modules Go (la suite de vgo) soient très bien, je ne les ai pas encore utilisés. Par contre, je ne me fais guère d'illusions sur le processus de décision : c'est Google qui décide, un point c'est tout.
Je note que ton commentaire laisse entendre que la réflexion autour de Dep s'est faite lors de discussions privées, alors que les réflexions autour de vgo se sont faites dans les issues github. Pourtant, c'est bien le contraire qui s'est passé. Le dépôt dep a toujours été accessible, avec une licence libre. Il y a eu des discussions dans les issues et sur un slack (OK, ce n'est pas forcément le meilleur outil). Les principaux contributeurs ont même tenu des réunions ouvertes à tout le monde. Les seules réunions privées étaient celles organisées par Russ Cox (Google) qui devait faire le suivi de l'expérimentation et rapporter les avancements à un comité de Google.
À l'inverse, Russ Cox (Google) a travaillé sur vgo seul dans son coin. Puis, il a présenté vgo à un petit comité (Google) et leur a demandé de trancher entre dep et vgo. Ce comité a tranché pour vgo (la proposition interne de Google). Et c'est seulement plus tard que la proposition a été rendue publique et que la communauté a pu faire des retours dessus.
[^] # Re: Go -> Rust
Posté par wilk . Évalué à 3.
Russ à fait des propositions à l'équipe de Dep qui les a refusée (à l'été 2017 puis en décembre 2017 sauf erreur). Donc comme on dit chez nous "show me the code". Ce qu'il a fait en 15j, non pas parce qu'il est plus fort que les autres mais parce que son idée est juste très simple (minimal version selection) et plus facile à implémenter qu'à démontrer en discussion. Ceci fait il l'a rendu publique en février. Tout le monde a pu en discuter, l'essayer, faire des remarques, l'amender (./vendor) qui ont abouties à une proposition officielle en mars (462 pour 8 contre). Cette proposition n'a été accepté officiellement qu'en mai (je pense que tu fais une erreur dans ta chronologie). Bref rien de spécial par rapport à n'importe quel projet libre, surtout Go où les fonctionnalités sont restreintes par principe et où on ne peut pas se permettre d'avoir des chevauchements d'outils comme en Python par ex.
Le premier jet de gestionnaire de version de Rust a été éjecté d'une manière beaucoup plus radicale que ça sans que ça n'émeuve qui que ce soit. Est-ce qu'un seul langage n'a pas connu de remous concernant sa gestion des packages !?
Google en tant qu'entreprise n'a que peu à voir la dedans (c'est ce qu'on leur reprochait jusque là d'ailleurs) pour le coup, je ne suis même pas sûr qu'ils utilisent les modules vu qu'ils ont leur fonctionnement propre avec un dépôt général et des forks de toutes les dépendances.
Ceci dit je n'ai aucune doute comme toi sur le fait que Google aurait le dernier mot si besoin ! Mais en l'occurrence je ne le vois pas à ce sujet.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Russ Cox a dit qu'il avait présenté un premier brouillon de ses travaux fin 2017 au "package management group" et ce groupe a voté pour que dep intègre ses travaux (ou disparaisse). L'équipe derrière dep était en désaccord avec cette décision prise par un petit groupe (et c'est cette décision que je qualifie de prise par Google). Et c'est cette étape qui a clairement marqué la fin de dep.
Alors, oui, derrière, on peut dire qu'il y a une proposition officielle des go modules et qu'il n'y a jamais eu de proposition officielle pour dep (l'équipe de dep n'aurait pas demandé mieux, mais Russ Cox n'a jamais pris la peine de leur dire comment dep aurait pu s'intégrer aux go tools, qui était une étape obligatoire pour faire cette proposition). Et une fois que Russ Cox a publié ces papiers en février et que l'équipe de Dep était devenue complètement démotivée, ça n'a plus été très compliqué de faire approuver la proposition officielle.
[^] # Re: Go -> Rust
Posté par wilk . Évalué à 2.
Toujours est-il qu'en fin de compte on se retrouve avec une version communautaire qui n'est pas très appréciée par la communauté, voir complètement rejetée, et une version non communautaire très largement plébiscité par la communauté !
Si on regarde les contributeurs respectifs des deux côtés on a essentiellement deux personnes. Un qu'on appelle communauté, un qu'on appelle Google :-)
Bon j'arrête là, voyons plutôt ce que va donner le résultat.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . Évalué à 3.
C'est une affirmation très arbitraire. dep a plus de 10 000 étoiles sur github, ce qui ne correspond pas vraiment à une version complètement rejetée par la communauté. Je pense que la plupart des développeurs Go s'en fiche du choix de l'un ou l'autre, l'important pour eux est qu'il y est enfin un outil officiel pour faire ça.
[^] # Re: Go -> Rust
Posté par woffer 🐧 . Évalué à 2.
Pour avoir utiliser les deux (dep et mod). Et bien, je suis contant que Russ ait imposé la vision de la gestion des dépendance qui beaucoup plus simple et suffisamment puissant.
C'est aussi un outil qui va nettoyer les logiciels qui adoptent des mauvais comportements (je pense à toi k8s qui change son API sur chaque nouvelle version mineure) car ils devront enfin respecter la gestion sémantique
# Lequel est le remplaçant de Ruby?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Tu prépares une nouvelle refonte disruptive de linuxfr?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Lequel est le remplaçant de Ruby?
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Non, il n'y a rien de prévu dans ce style pour le moment.
Ceci dit, il y a du Go en production sur LinuxFr.org depuis quelques années, avec epub et img. Et ça ne me déplairait pas de faire un autre daemon dans ce style en Rust si le besoin se présente.
# Il faut savoir troller bordel !
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
GO domine clairement le marché des langages pour kékés (265k repos sur github contre 44k pour Rust). Après Chrome, Google écrase encore une fois Mozilla.
Il faut dire que Go est largement plus abordable que Rust. Gon c'est le C sans avoir besoin de comprendre comment fonctionne un ordinateur. C'est un peu comme le whisky par rapport au cognac, le poker par rapport au tarot, une vulgarisation extrême, le snapchat de la programmation.
Rust c'est plutôt comme le Bridge, le Gin, les vacances en Bretagne ou la recherche du temps perdu, un truc pour briller en société, mais que personne n'aime vraiment.
Voilà
[^] # Re: Il faut savoir troller bordel !
Posté par Lutin . Évalué à 2.
Rust est surtout beaucoup plus jeune, la métrique du nombre de repo github ne semble pas pertinente.
[^] # Re: Il faut savoir troller bordel !
Posté par Lucky Seven . Évalué à 1.
Mouis… d'après wikipedia, Novembre 2009 pour Go, Juillet 2010 pour Rust.
[^] # Re: Il faut savoir troller bordel !
Posté par NicolasP . Évalué à 7. Dernière modification le 10 septembre 2018 à 21:38.
Les dates que tu donnes sont les dates d'annonce de ces langages. Si on regarde la date des premières versions stables, l'écart est plus important.
Pour Go :
Pour Rust :
J'imagine que la plupart des gens attendent la première version stable d'un langage avant de faire un projet Github dessus. Ça doit pouvoir se vérifier (ou non) sur Github, mais je n'ai pas trouvé.
[^] # Re: Il faut savoir troller bordel !
Posté par Astaoth . Évalué à 5.
Bah moi, j'aime bien le Gin
Marrant, j'aime bien le tarot et le cognac, mais je déteste le whisky et le poker. J'vais ptetre me mettre au Rust finalement !
Emacs le fait depuis 30 ans.
[^] # Re: Il faut savoir troller bordel !
Posté par Mr Kapouik (site web personnel) . Évalué à 10.
Perso j'aime bien passer mes vacances a Bagdad, du coup je fais du perl.
[^] # Re: Il faut savoir troller bordel !
Posté par David Marec . Évalué à 1. Dernière modification le 11 septembre 2018 à 11:26.
P
*a
J'aimerais bien visiter plus au sud, à Babylone, Lagash ou Ur.
Du coup j'appelle des scripts
awkdans des scripts en#!/bin/sh..
*qq
[^] # Re: Il faut savoir troller bordel !
Posté par robin . Évalué à 1.
Je ne sais pas quelle version de ed tu utilise, mais chez moi
*qqne marche pas, je dois fairePour faire un force quit.
Et tant qu'on y est, à quoi sert
P?Et peut être que tu pourra me renseigner, pourquoi
^,$pn'affiche pas tout le fichier, quelle est la sémantique de^? Certes, je peux utiliser%pou1,$pou encore%n, mais dans tout les cas, seul quelqu'un ayant des problèmes de mémoires a besoin d'afficher la totalité du contenu de ses fichiers.bépo powered
[^] # Re: Il faut savoir troller bordel !
Posté par David Marec . Évalué à 1. Dernière modification le 11 septembre 2018 à 17:26.
Oui, c'est bien
q, lancé deux fois et nonqq.Il affiche l'invite, penser aussi à ajouter
Hpour indiquer les erreurs.ou, plus court:
Si je ne me trompe pas, c'est l'équivalent de
-, soit la ligne précédente.On peut la combiner avec un nombre pour remonter n lignes.
[^] # Re: Il faut savoir troller bordel !
Posté par robin . Évalué à 1.
Super, je vais pouvoir briller en soirée maintenant ! ;)
Plus sérieusement, tu as des cas d'usage de ed non couvert par vim/sed/awk/grep/sh ?
bépo powered
[^] # Re: Il faut savoir troller bordel !
Posté par David Marec . Évalué à 1. Dernière modification le 13 septembre 2018 à 00:03.
J'ai encore des machins qui n'ont qu'une liaison série pour affichage.
Je l'utilise surtout dans des scripts sinon.C'est efficace pour travailler avec des blocs de textes, joindre ou casser des lignes.
Mais, par rapport à sed, ça manque de hold buffer, même si on s'en sort avec les backreferences.
Et puis pour prendre des notes à la volée, c'est assez efficace.
[^] # Re: Il faut savoir troller bordel !
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 13 septembre 2018 à 00:18.
Moi pour briller en société je ne sors jamais sans
https://docs.freebsd.org/44doc/usd/13.viref/paper.pdf
Oui et c'est facile: vim est interactif alors qu'on peut utiliser ed pour du traitement par lots. Ensuite sed, awk et grep sont très forts pour faire des traitements en une passe, mais pour des traitements multi-passes il n'y a plus personne. Enfin le shell sert à exécuter des programmes, je ne vois pas trop ce qu'il vient faire dans ta liste.
[^] # Re: Il faut savoir troller bordel !
Posté par jyes . Évalué à 3.
On peut aussi l’appeler avec la commande ex ou vim -e qui en fait un très bon remplaçant de ed.
[^] # Re: Il faut savoir troller bordel !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Bon remplacement si on a besoin de tout ce qu'il y a en plus…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Il faut savoir troller bordel !
Posté par robin . Évalué à 2.
Justement pour combiner plusieurs appel à sed/grep/awk pour faire du traitement multi-passes. Et comme l'a dis jyes on peut utiliser
vim -epour passer utiliser les commandes vim de manière non-interactive.bépo powered
[^] # Re: Il faut savoir troller bordel !
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 13 septembre 2018 à 00:25.
Pfff, Bagdad c'est surfait, autant aller à Perl directement, en plus Apach est juste à côté, à un jet de common gateway interface.
[^] # Re: Il faut savoir troller bordel !
Posté par Christophe B. (site web personnel) . Évalué à 2.
Comme disait Coluche : les coups et les douleurs cela se discutent pas …
# .
Posté par Sufflope (site web personnel) . Évalué à 10. Dernière modification le 10 septembre 2018 à 13:43.
C'est marrant que tu dises que Rust plait aux codeurs bas niveaux. Chez nous, on fait du Scala, pas spécialement "langage bas niveau", et on est très intéressés par Rust. Il arrive à mon goût à allier le confort qu'on aime chez Scala : types optionnels, itérateurs, presque de la programmation fonctionnelle…, et aussi cargo tellement mieux qu'un Makefile, la sureté mémoire (même si c'est un peu plus coton qu'en JVM, notamment les différents types de chaîne, mais en contrepartie pas de GC…). On se tâte même à réécrire certains morceaux critiques en Rust, c'est dire.
# Et encore une fois...
Posté par gUI (Mastodon) . Évalué à 10.
… on peut vérifier la loi des titres selon Betteridge : quand un article pose une question en titre, on peut ne pas lire l'article et répondre par "non" (et gagner du temps).
Titre : Go et Rust, lequel est le remplaçant du C ?
Conclusion : Ni Go ni Rust ne remplaceront complètement le C et le C++ [mais…]
(je ne me moque pas de l'auteur de l'article, ni même de cette pratique journalistique omniprésente et involontaire, c'est juste que c'est un truc que j'ai découvert il y a peu, et que ça se vérifie tout le temps en fait…)
Et c'est compréhensible : si l'auteur du journal avait, selon lui, trouvé dans l'un de ces deux langages un digne successeur du C, il aurait intitulé "Après le C, le Go" ou "Pourquoi Rust remplacera le C et pas le Go", mais n'aurait pas posé de question.
Voilà, vous pouvez reprendre la lecture des autres commentaires, ils sont bcp plus constructifs en général :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Et encore une fois...
Posté par claudex . Évalué à 3. Dernière modification le 10 septembre 2018 à 20:28.
Je dirais qu'à la différence d'un article de journal, un article ici invite à la discution et demande justement à ce que les gens donnent leur avis dans les commentaires. Parce en plus, le sujet sur ce site fait que les gens ont la compétence pour donner leur avis.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et encore une fois...
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 10 septembre 2018 à 22:29.
Avec le web 2.0 les "journaux" traditionnels cherchent clairement à "engager l'audience" (et monitorent ce KPI pour report le taux d'engagement au board) donc clairement ils ont la même attente.
[^] # Re: Et encore une fois...
Posté par claudex . Évalué à 4.
C'est bien pour ça que je dis que les gens ont la compétence de donner leur avis, contrairement à un journal random qui titre "La cure contre le cancer enfin découverte ?"
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# C puis Python
Posté par wilk . Évalué à 4.
Personnellement j'ai commencé par réécrire des bouts de code C en Go car j'avais besoin de garder de la rapidité tout en ayant de plus en plus de besoins en réseau et multiproc.
La réécriture de ces petits algos en C a quasiment consisté à un copier-coller.
Ensuite j'ai trouvé ça tellement facile et pratique que j'ai démarré une appli web qui ne nécessitait rien de tout ça et aurait très bien pu être écrite en Python.
Pour une première appli comme ça j'ai mis beaucoup plus de temps qu'en Python. En revanche le résultat est beaucoup plus solide dans le sens où la maintenance est beaucoup plus facile grace au typage statique et l'absence de magie. Le déploiement est également beaucoup plus simple et économique en ressource.
J'étais pourtant un fervent défenseur du typage dynamique. Du coup j'ai compté pour être sûr ! J'ai compté le nombre de fois où je faisais une erreur de type en Python, détecté au test. Énorme. Énorme mais je ne m'en rendais pas compte car les erreurs de types en Python sont très vite corrigées donc on oublie rapidement le problème.
Depuis je n'utilise plus que Go et je réécris progressivement tout ce que j'ai en Python. C'est juste trop facile et je ne peux plus me passer de vim-go. Le nouveau Go module clos le seul bémol qui restait.
[^] # Re: C puis Python
Posté par flan (site web personnel) . Évalué à 3.
Concernant les erreurs de type, qu'utilisais-tu comme IDE ?
Depuis que je suis passé à PyCharm (en l'aidant parfois un peu avec les annotations), ça ne m'arrive plus qu'exceptionnellement. Entre vim et PyCharm, j'ai dû diviser par plus de 10 les erreurs de typage.
[^] # Re: C puis Python
Posté par wilk . Évalué à 2.
Vim
Je n'ai jamais utilisé PyCharm mais oui c'est ce qu'on retrouve, un tas d'outils très pratique pour contrôler et naviguer à travers le code. Refactoriser, éliminer le code mort etc.
Du fait de l'absence de code dynamique c'est par contre beaucoup plus efficace et fiable (mais strict du coup). J'ai quand même mis pas mal de temps à passer de Python à Go car j'utilisais beaucoup le côté dynamique. Du coup maintenant quand je refais du Python je m'interdit beaucoup de chose ! Y a pas photo, Go est rébarbatif et ennuyeux, c'est un avantage et un défaut…
[^] # Re: C puis Python
Posté par flan (site web personnel) . Évalué à 2.
En fait, je pense que c'est surtout l'inférence de type, très efficace même s'il faut parfois l'aider un peu, qui m'est le plus utile au quotidien.
Sans attendre la qualité d'un langage statiquement typé, on s'en rapproche fortement.
# Rust, de gros prérequis ?
Posté par StyMaar . Évalué à 10.
C'est marrant, moi je n'ai pas du tout eu cette impression en me mettant à Rust: pour moi, qui n'avais fait que du web professionnellement (PHP -> Java -> Nodejs), Rust c'était justement un moyen d'aborder le bas niveau sans avoir à me plonger dans les emmerdes du C ou C++ (j'avais seulement eu un cours de C en école, et les segfault en veux-tu en voilà, ça m'avait un poil agacé, sans compter que l'ensemble de l'écosystème paraissait ultra-archaïque).
Avec Rust, j'ai pu m'intéresser au bas niveau en ayant un compilateur vigilant et pédagogue sur le dos, pour m'éviter de faire n'importe quoi, et je mis suis mis super bien. La communauté sur le net, notamment sur irc aide aussi énormément.
Et quand je vois la communauté Rust, sur Reddit notamment, je suis loin d'être le seul dans ce cas: il y a vraiment beaucoup de développeurs avec un background web, sans aucunes connaissances en C, qui se sont mis à Rust pour faire du bas niveau sans revenir aux années 80.
En tout cas moi ça m'a plutôt bien réussi: je bosse aujourd'hui sur de l'embarqué (un robot) avec un code essentiellement en Rust.
[^] # Re: Rust, de gros prérequis ?
Posté par liberforce (site web personnel) . Évalué à 5.
Salut, c'est quoi comme robot qui embarque du Rust, si c'est pas trop indiscret ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.