Programmation : une étude révèle les langages les plus voraces en énergie

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/12/2021, 18h02
air-dex

Au delà de ça il y a aussi la qualité de l'implémentation et le talent du développeur qui la code. Rust, C, C++, ASM... ont beau avoir des prédispositions écologiques, si l'implémentation qui est faite dans ce langage pue la merde et est très mal optimisée, alors autant rester sur du JS ou sur du Python.

Citation:

Envoyé par Bruno

:fleche: « Coder en Rust serait difficile », qu'en pensez-vous ?

:fleche: Utilisez-vous le langage Rust ? Avez-vous essayé de l'apprendre ?

Rust est réputé plus dur parce que différent. Rust impose une certaine gymnastique d'esprit quand on code dans ce langage, parce qu'il faut réfléchir à des choses dont on ne se préoccupe pas ou moins dans d'autres langages plus grand public. Je pense là à l'immuabilité et surtout à l'ownership. Rust est la croisée de plusieurs paradigmes et ça se sent, surtout dans un monde où l'on a tendance à te "formater objet".

De même que Rust fait de l'objet sans en faire, sans l'assumer. T'as pas de classes, d'interfaces et d'héritage (tout aussi tabou qu'ailleurs visiblement), mais t'as des structs, des traits, l'implémentation de traits et de l'héritage de traits. Non, mais oui en fait. Ça me rappelle un vieux cours d'école d'ingé, très intéressant au demeurant, qui consistait à simuler le C++ avec du C, à faire de l'objet sans en faire. Du coup ça va forcément compliquer les choses pour des développeurs venant d'un monde où la POO est plus assumée, avec des choses (surtout de la syntaxe) qui y facilitent la POO

Citation:

Envoyé par Bruno

:fleche: Quel commentaire faites-vous de l'immense adoption de Rust par les Big Tech ?

Rust a surtout le mérite de se poser les bonnes questions, et de ne pas lancer un C-killer pour le plaisir de lancer un C-killer.
04/12/2021, 13h48
jpouly

Citation:

Envoyé par Bruno

https://www.developpez.com/public/im...ews/tble04.PNG
Résultat global normalisé pour le temps d'énergie et la mémoire

Ce qui m'étonne dans le tableau des temps d'exécution, c'est de voir le Java devant le C#. Parce que c'est pas trop ce que je constate dans la vrai vie.

Et de voir le Fortran et le Pascal derrière. Pour moi, en temps d'exécution, le Fortran et le Pascal sont à peu près équivalent au C. Encore faut il utiliser le bon compilateur :D.

Et pas coder comme une m....

Donc très bizarre ce tableau.
04/12/2021, 15h09
Guesset

Temps incertains

Bonjour AoCannaille,

Citation:

Envoyé par AoCannaille

...utiliser la commande time et celle-ci fait déjà la différence entre real (temps total ressenti), user(temps réel CPU accordé à l'utilisateur) et sys ( temps utilisé par les IO système)...

Peut être pas si simple. Il semble qu'ils aient choisi une exécution représentative du vrai monde et multiplié les exécutions pour avoir une moyenne plus stable. Ce qui peut se défendre mais reste sensible au changement de priorité.

En outre, comment le temps CPU est compté dans les multithreads (et il y en a) ? Temps CPU et durée peuvent être sensiblement différents. Par ailleurs, les changements de contextes (reprise d'un traitement d'un thread)) sont généralement à la charge du bénéficiaire ce qui signifie qu'une exécution chahutée sera plus longue - même en temps CPU - qu'une exécution plus zen.

J'ai toujours trouvé la mesure de temps très difficile et insatisfaisante. Et je ne parle même pas des processeurs qui s'amusent à faire évoluer leur vitesse.

Salut
05/12/2021, 14h19
koyosama

Ouais une monde de plus pour l'instant j'utilise encore le bon vieux PHP + JQuery, non changeons pas des trucs qui marchent :aie:. Et pour être franc, aucun utilisateur et clients feront la difference de tout façon.
Non le progrès est forcement dans nos genes, (plus la meme epoque je vous dis :calim2:).

Cela me rappelle une question que j'ai vu il y a pas longtemps "Pourquoi GitHub est toujours en Ruby et n'utilise pas NodeJS ?". Des réponses pour et contre, non c'est cool l’étude et franchement c'est pas rocket science, mais bon tu as le reel et la théorie. Et en fait c'est juste un problème de hipster et de riche.
05/12/2021, 17h28
MaximeCh

Il n'est pas trop tard pour commencer votre Advent of Code en rust :

https://adventofcode.com/

https://github.com/search?q=aoc21
06/12/2021, 21h19
Astraya

Je vais faire une petite correction à tout ces titres :

Citation:

WASM peut-il sauver la planète?

Rust, C ou C++ on peut faire la même chose ( hormis quelques paradigme spécifique )
Dire que C est plus rapide que C++ ou Rust c'est du Bullshit.
C++ n'est pas que POO, c'est multi-paradigme, donc on peut faire du C dans un .cpp
Juste pour info le compilateur C chez Microsoft c'est un compilateur C++... Donc C++ fait du C avec optionnellement une couche objet.

Le plus gros problème est plus une question d’algorithmie que de langage
il y a différente d’implémentation de l'algo de fibonacchi

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
public class Fibo {

	public static void main(String[] args) {
		for (int i = 0; i < 20; i++) {
			print(i);
		}
		print2(50);
		print2(92);
		print2(93);

	}

	private static void print(int i) {
		System.out.println(
				"i=" + i + ", fibo=" + fibo(i) + ", fibo2 " + fibo2(i) + ", fibo3 " + fibo3(i) + ", fibo4 " + fibo4(i));
	}

	private static void print2(int i) {
		System.out.println("i=" + i + ", fibo2 " + fibo2(i) + ", fibo3 " + fibo3(i) + "+  fibo4 " + fibo4(i));
	}

	public static long fibo(int n) {
		if (n == 0) {
			return 0;
		}
		if (n == 1) {
			return 1;
		}
		return fibo(n - 1) + fibo(n - 2);
	}

	public static long fibo2(int n) {
		if (n == 0) {
			return 0;
		}
		if (n == 1) {
			return 1;
		}
		long a = 1;
		long b = 0;
		for (int i = 1; i < n; i++) {
			long tmp = a;
			a = b + a;
			b = tmp;
		}
		return a;
	}

	public static long fibo3(int n) {
		if (n == 0) {
			return 0;
		}
		if (n == 1) {
			return 1;
		}
		if (n == 2) {
			return 1;
		}
		int n_2 = n / 2;
		if (n % 2 == 0) {
			long r1 = fibo3(n_2);
			long r2 = fibo3(n_2 + 1);
			// fibo(2n)=fibo(n)*(fibo(n-1)+fibo(n+1);

			return r1 * (r2-r1 + r2);
		}
		long r1 = fibo3(n_2);
		long r2 = fibo3(n_2 + 1);
		// fibo(2n+1)=fibo(n)*fibo(n)+fibo(n+1)*fibo(n+1);
		return r1 * r1 + r2 * r2;
	}

	public static long fibo4(int n) {
		if (n == 0) {
			return 0;
		}
		if (n == 1) {
			return 1;
		}

		long l[] = recurseFibo4(n);
		return l[0];
	}

	public static long[] recurseFibo4(int n) {
		if (n == 0) {
			return new long[] { 0, 1 };
		}
		if (n == 1) {
			return new long[] { 1, 1 };
		}

		if (n == 2) {
			return new long[] { 1, 2 };
		}

		int n_2 = n / 2;

		if (n % 2 == 0) {
			long l[] = recurseFibo4(n_2);
			long r1 = l[0];
			long r2 = l[1];
			long a = r1 * (r2 - r1 + r2);
			long b = r1 * r1 + r2 * r2;
			return new long[] { a, b };
		}

		long l[] = recurseFibo4(n - 1);
		long r1 = l[0];
		long r2 = l[1];
		long a = r2;
		long b = r1 + r2;

		return new long[] { a, b };

	}

}

4 version de l'algo avec des complexite différente .
le 1 ° a une conplexite N²
le 2 ° a un complexite en N
le 3 ° en (log2) N *(log2) N
le 4° en log(2)N (le plus rapide )et qui est recursif peut etre exister aussi en non recursif => mais il sera encore moins lisible).

13/12/2021, 09h56
AoCannaille

Citation:

Envoyé par miaous

Le plus gros problème est plus une question d’algorithmie que de langage

4 version de l'algo avec des complexite différente .
le 1 ° a une conplexite N²
le 2 ° a un complexite en N
le 3 ° en (log2) N *(log2) N
le 4° en log(2)N (le plus rapide )et qui est recursif peut etre exister aussi en non recursif => mais il sera encore moins lisible).

Ce n'est pas vraiment un problème, les stats étant basées sur the benchmark game, qui accepte plusieurs implémentations pour un langage donné.
En exemple au pif, une implemetation de mandelbrot en C++/g++ et une autre

C'est pas pour rien que cela s'appelle "benchmarks game", si tu trouves l'implémentation dans ton langage favori mal optimisé, tente ta chance pour le faire monter dans les stats :)
06/02/2022, 23h31
Mimoza

Étude intéressante, mais tout le bénéfice d'un langage économe est perdu si le programme exécuté n'est pas aussi optimisé. Je dirais même qu'il est largement préférable d'avoir un bon dev Python, qu'un mauvais Rust ;-)
C'est sur que d'avoir un bon Rust serait encore mieux :-p
21/02/2022, 08h33
Patrick Ruiz

1 pièce(s) jointe(s)

« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C », d'après AWS

« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre »
D’après l’équipe AWS

Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on est d’avis que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, cette étude sur les langages les plus voraces en énergie établit que le langage C offre les meilleures performances sur les axes de l’efficacité énergétique et de la performance d’exécution.

Pièce jointe 614105

On en vient donc à se poser la question de savoir pourquoi tant de voix s’élèvent pour appeler à la venue d’un successeur au langage C. Il y a seulement que les rapports de chercheurs en sécurité s’enchaînent et ne cessent de mettre le doigt sur l’une des plus grosses tares que les langages C et C++ traînent : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abondent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

Ryan Levick de Microsoft souligne ces détails dans le cadre de sa présentation et coupe court : « Quels que soient les investissements que les entreprises de la filière du développement de logiciels peuvent mettre sur pied, le fait est que C++ [C] n’est pas par essence un langage fait pour la mise sur pied d’applications sécurisées. » Alex Gaynor – un ex contributeur de l’équipe sécurité du navigateur Firefox – émet un avis similaire : « Le C++ moderne ne nous sauvera pas, car il est moins sécurisé que les nouveaux langages [Rust, Swift]). »

https://www.youtube.com/watch?v=NQBVUjdkLAA

En 2012, Linus Torvalds a déclaré que « il n’y a rien de mieux que le langage C pour le développement de systèmes d’exploitation. » La sortie de Linus Torvalds était antérieure à la publication de la première version stable de Rust – le langage de programmation pressenti comme remplaçant du C sur le terrain du contrôle du hardware. En fait, au moment où Linus s’exprimait, Rust n’en était qu’au stade de l’enfance.

https://www.youtube.com/watch?v=CYvJPra7Ebk

Depuis, son regard sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. »

Source : Amazon

Et vous ?

:fleche: Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
:fleche: Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
:fleche: Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
:fleche: Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?
:fleche: Que cache l'immense adoption de Rust par les Big Tech ?

Voir aussi :

:fleche: Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

:fleche: Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

:fleche: Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

:fleche: Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
22/02/2022, 14h29
zecreator

L'argument écologique... mouais

Tous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.

Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.

Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.
22/02/2022, 15h14
esperanto

Logique éco

Donc, l'écologie aujourd'hui, c'est utiliser son pc puissant comme un simple terminal pour se connecter à une machine Azure, avec toute la lourdeur de l'interface Windows 10, lancer un IDE écrit en C# genre Visual Studio... mais programmer en C parce qu'il consomme 3 pour cent de moins que Rust, c'est bien ça?
22/02/2022, 15h41
herr_wann

Citation:

Tous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.

Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.

Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.

Ce n'est pas vraiment comme cela que je l'interprète ( jeu de mot pourri inside :aie: ). Rust a été conçu comme un C/C++ amélioré afin d'éviter les erreurs les plus fréquentes de gestion de la mémoire et de programmation asynchrone/parallèle, sans impacter les performances. Il est donc apprécié malgré la courbe d'apprentissage un peu raide par les programmeurs système, drivers, jeux vidéo et blockchain. Même si on peut tout faire, ce sont surtout ces domaines où il apporte le plus de valeur ajoutée. Il est donc censé remplacer un langage vieux de 40 ou 50 ans.

De plus il est très simple à installer, il est libre et gratuit, possède de bons utilitaires de gestion de packages, le compilateur est strict mais il apporte une grande aide pour résoudre les problèmes à la compilation et non après.
22/02/2022, 15h55
zecreator

Sincèrement, je n'en peux plus de ces environnements de programmation qui s'installent à partir du Terminal en X lignes de commandes qui foirent 1 fois sur 2 à cause d'une Lib qui n'est pas à jour ou d'un module en version beta dont le dev est totalement abandonné. Sans compter qu'il faut souvent recompiler les binaires depuis les sources pour que ça fonctionne.

Comment voulez-vous que des débutants soient motivés quand déjà l'installation demande le niveau de connaissance d'un ingénieur informatique. C'est tout le problème des outils codés par des développeurs pour des développeurs. Y a plus aucun raisonnement.

Hé Ho, on est en 2022, c'est fini l'époque du terminal. Bientôt on va revenir à la disquette et au disque-dur en cire d'abeille.
22/02/2022, 16h09
eclesia

Citation:

Envoyé par zecreator

Tous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.

Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.

Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.

C'est vrai que Rust n'est pas simple, mais reste plus simple que du C/C++ et encore bien plus si tu ajoutes les outils qui vont avec.
Pour moi qui vient du monde Java, je n'ai jamais réussi a vraiment comprendre la logique et toute la misère autour des templates,génériques,preprocessing de C/C++
mais Rust je n'ai pas eu de soucis, c'est tellement plus carré.

Pour dire vrai, c'est le seul language que je trouve supérieur à Java (j'inclus l'environnement).
J'ai commencé en Java 1.4 il y a quoi presque 15ans ? c'est mon premier vrai changement de language.

Faire un build, lancer des tests, gérer les dépendances, la génération de la doc, le déploiement... bonne chance avec cmake, ant ou autre.
l'outil Cargo est un petit bijou, et surtout tous les projets Rust sont dessus, c'est une sorte de Maven+++.

Bref ce n'est que mon avis, Rust est un bon cheval.
22/02/2022, 16h27
esperanto

IDEes

Citation:

Envoyé par zecreator

Sincèrement, je n'en peux plus de ces environnements de programmation qui s'installent à partir du Terminal en X lignes de commandes qui foirent 1 fois sur 2 à cause d'une Lib qui n'est pas à jour ou d'un module en version beta dont le dev est totalement abandonné. Sans compter qu'il faut souvent recompiler les binaires depuis les sources pour que ça fonctionne.

Et moi je n'en peux plus de ces EDI qui après s'être, certes, installés correctement en trente secondes (le temps de décompresser le zip) vont mettre deux minutes à chaque démarrage avant d'être opérationnels parce qu'il faut attendre d'avoir chargé les 350 plugins un par un
Qu'il faut reconfigurer sans cesse parce que les collègues ont poussé leur configuration dans le git, évidemment différente d'un dev à l'autre...

Si une lib n'est pas à jour, c'est peut-être aussi parce que ça fait belle lurette que l'éditeur ne l'utilise plus réellement mais que le développeur a eu la flemme de la supprimer et tant pis si le zip à télécharger fait 150 mégas même pour une mise à jour!
22/02/2022, 16h44
zecreator

Citation:

Envoyé par esperanto

Et moi je n'en peux plus de ces EDI qui après s'être, certes, installés correctement en trente secondes (le temps de décompresser le zip) vont mettre deux minutes à chaque démarrage avant d'être opérationnels parce qu'il faut attendre d'avoir chargé les 350 plugins un par un
Qu'il faut reconfigurer sans cesse parce que les collègues ont poussé leur configuration dans le git, évidemment différente d'un dev à l'autre...

Si une lib n'est pas à jour, c'est peut-être aussi parce que ça fait belle lurette que l'éditeur ne l'utilise plus réellement mais que le développeur a eu la flemme de la supprimer et tant pis si le zip à télécharger fait 150 mégas même pour une mise à jour!

Personnellement, mon outil de dev préféré c'est Notepad++ :).
Je te rejoins sur les IDE qui ont besoin de 2Go de SDK et de plugins pour t'afficher un simple "Hello world" qui pèse 60 Mo à l'arrivée. Les usines à gaz à la Eclipse et Visual Studio, j'ai du mal à croire que l'on arrive encore à être productif avec de telles marmites.

Pour le problème du git que tu rencontres avec tes collègues, c'est juste un problème de formation des individus sur les bonnes pratiques. Rien à voir avec les outils.

Avec de tels langages de programmation, il faudra s'attendre à ce que bientôt, les entreprises se tournent de plus en plus vers le no-code. Les langages coûtent chers en formation, et sont de moins en moins stabilisés. Les bons développeurs se font de plus en plus rare, et ils coûtent de plus en plus chers.

Il va être temps de penser à créer des langages qui soient simples d'utilisation et performants, accessibles même aux non-développeurs.
22/02/2022, 18h08
Uther

Citation:

Envoyé par zecreator

Tous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.

C'est pas parce qu'il y a un nouveau langage disponible, que qui que ce soit va imposer qu'on l'utilise partout.

Citation:

Envoyé par zecreator

Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.

Rust est en effet complexe a apprendre, mais au contraire, quand on le connait, il est très facile a installer et utiliser grâce aux divers outils (build, dépendances, test, doc, ...) très bien intégrés.
Après si tu veux un langage ultra simple que les non développeurs peuvent apprendre en un rien de temps, en effet Rust ne sera certainement pas ton premier choix, et ça tombe bien, il y a Python ou Go pour ça.

Citation:

Envoyé par zecreator

Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.

Je connais pas d'entreprise qui marchent comme ça. On ne change pas de langage en fonction du sens du vent, ça n’empêche pas de se renseigner sur l'existant pour ne pas vivre dans le passé non plus.

Citation:

Envoyé par esperanto

Donc, l'écologie aujourd'hui, c'est utiliser son pc puissant comme un simple terminal pour se connecter à une machine Azure, avec toute la lourdeur de l'interface Windows 10, lancer un IDE écrit en C# genre Visual Studio... mais programmer en C parce qu'il consomme 3 pour cent de moins que Rust, c'est bien ça?

Heu non, l'écologie, c'est d'utiliser une solution performante quand on a besoin de performance et ne pas compenser une solution logiciel mal optimisée en utilisant des solution matérielles surdimensionnées. Ça peut malheureusement être tentent de nos jours avec les solutions cloud avec lesquelles c'est facile d'obtenir immédiatement plus de puissance de calcul.
Ça ne veut pas non plus dire qu'il faut utiliser Rust ou C partout, juste là ou ça fait sens. Les performances de calcul brutes ne sont pas toujours le facteur le plus important.
22/02/2022, 20h18
zecreator

A la finalité qu'est-ce qui fait un bon développement ? Le langage ou le développeur ?

On peut avoir le langage le plus performant et eco-responsable du Monde, si tu codes comme un barbare, ça s'annule.
Alors peut-être qu'au lieu de nous inventer des langages plus relou chaque année, on devrait commencer par prendre le temps de bien former les développeurs en école.
22/02/2022, 20h32
Pyramidev

Citation:

Envoyé par zecreator

Sincèrement, je n'en peux plus de ces environnements de programmation qui s'installent à partir du Terminal en X lignes de commandes qui foirent 1 fois sur 2 à cause d'une Lib qui n'est pas à jour ou d'un module en version beta dont le dev est totalement abandonné. Sans compter qu'il faut souvent recompiler les binaires depuis les sources pour que ça fonctionne.

Citation:

Envoyé par Uther

Rust est en effet complexe a apprendre, mais au contraire, quand on le connait, il est très facile a installer et utiliser grâce aux divers outils (build, dépendances, test, doc, ...) très bien intégrés.

Comparé à ce que j'ai subi avec d'autres technos, Rust a été facile à installer sur Ubuntu.
Il reste une marge de progression, mais ce ne sera pas du côté de Rust tout seul.
Quand j'avais téléchargé et compilé des outils en ligne de commande via des commandes de la forme cargo install nom_de_crate, il y a quand même des fois où la compilation avait échoué parce que j'avais besoin d'installer en amont des dépendances, par exemple, via APT, build-essential et libssl-dev.
Dans l'écosystème du développement de logiciel, en règle générale, pour avoir des installations qui marchent vraiment, il faudrait pouvoir lancer facilement des installations reproductibles.
À une époque, je m'étais brièvement intéressé au gestionnaire de paquets Nix, qui avait été conçu dans ce but. Mais, comme la documentation n'était pas à jour, ça m'a vite agacé et j'ai laissé tomber.
Il existe aussi le gestionnaire de paquets GNU Guix qui est un concurrent direct de Nix, mais avec une communauté plus petite.
Du coup, j'attends de voir si l'un de ces deux va gagner ou s'ils seront remplacés par un troisième.
Pour les installations, il y a bien un problème de fond auquel il faut encore répondre.
Par contre :

Citation:

Envoyé par zecreator

Hé Ho, on est en 2022, c'est fini l'époque du terminal.

Là, tu te trompes de problème. Ce n'est pas parce qu'une installation peut être lancée dans un terminal qu'elle a moins de raison de marcher que depuis une GUI.

Voir 40 message(s) de cette discussion en une page