IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'éditeur RisingWave explique pourquoi il a réécrit son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++ :
Faut-il arrêter d'initier de nouveaux projets en C++ et passer à Rust ?

Le , par Patrick Ruiz

89PARTAGES

16  0 
Faut-il arrêter d’initier de nouveaux projets en C++ et passer à Rust ? Oui, d’après Mark Russinovich de Microsoft qui recommande le langage Rust plutôt que le C ou C++. Les raisons : la parité en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec une sortie de la startup RisingWave. Elle s’est lancée dans un projet de mise sur pied d’un SGBD Cloud natif avec le langage C++. 7 mois après son lancement le projet en C++ a été abandonné pour une réécriture en Rust. L’éditeur donne ses raisons.

Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire. Celui de la startup RisingWave ne s’en écarte pas et souligne que :

« Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe. »

Néanmoins, Bjarne Stroustrup s’inscrit en faux avec le fait que les comparatifs entre Rust et C++ limitent la notion de sécurisation des logiciels à celle de sécurisation de la mémoire : « Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique. » Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.


L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

Code Rust : Sélectionner tout
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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
  
                 pub enum Components { 
		#[clap(name = "minio")] 
		Minio, 
		Hdfs, 
		PrometheusAndGrafana, 
		Etcd, 
		Kafka, 
	@@ -77,6 +78,7 @@ impl Components { 
		pub fn title(&self) -> String { 
		match self { 
		Self::Minio => "[Component] Hummock: MinIO + MinIO-CLI", 
		Self::Hdfs => "[Component] Hummock: Hdfs Backend", 
		Self::PrometheusAndGrafana => "[Component] Metrics: Prometheus + Grafana", 
		Self::Etcd => "[Component] Etcd", 
		Self::Kafka => "[Component] Kafka", 
	@@ -97,6 +99,10 @@ impl Components { 
		match self { 
		Self::Minio => { 
		" 
		Required by Hummock state store." 
		} 
		Self::Hdfs => { 
		" 
		Required by Hummock state store." 
		} 
		Self::PrometheusAndGrafana => { 
	@@ -169,6 +175,7 @@ Required if you want to create CDC source from external Databases. 
		pub fn from_env(env: impl AsRef<str>) -> Option<Self> { 
		match env.as_ref() { 
		"ENABLE_MINIO" => Some(Self::Minio), 
		"ENABLE_HDFS" => Some(Self::Hdfs), 
		"ENABLE_PROMETHEUS_GRAFANA" => Some(Self::PrometheusAndGrafana), 
		"ENABLE_ETCD" => Some(Self::Etcd), 
		"ENABLE_KAFKA" => Some(Self::Kafka), 
	@@ -188,6 +195,7 @@ Required if you want to create CDC source from external Databases. 
		pub fn env(&self) -> String { 
		match self { 
		Self::Minio => "ENABLE_MINIO", 
		Self::Hdfs => "ENABLE_HDFS", 
		Self::PrometheusAndGrafana => "ENABLE_PROMETHEUS_GRAFANA", 
		Self::Etcd => "ENABLE_ETCD", 
		Self::Kafka => "ENABLE_KAFKA", 
		Self::Pubsub => "ENABLE_PUBSUB", 
		Self::Redis => "ENABLE_REDIS", 
		Self::RustComponents => "ENABLE_BUILD_RUST", 
		Self::Dashboard => "ENABLE_BUILD_DASHBOARD_V2", 
		Self::Tracing => "ENABLE_COMPUTE_TRACING", 
		Self::Release => "ENABLE_RELEASE_PROFILE", 
		Self::AllInOne => "ENABLE_ALL_IN_ONE", 
		Self::Sanitizer => "ENABLE_SANITIZER", 
		Self::ConnectorNode => "ENABLE_RW_CONNECTOR", 
		} 
		.into() 
		} 
  
		pub fn default_enabled() -> &'static [Self] { 
		&[Self::RustComponents] 
		} 
		} 
  
		fn configure(chosen: &[Components]) -> Result<Option<Vec<Components>>> { 
		println!("=== Configure RiseDev ==="); 
  
		let all_components = all::<Components>().collect_vec(); 
  
		const ITEMS_PER_PAGE: usize = 6; 
  
		let items = all_components 
		.iter() 
		.map(|c| { 
		let title = c.title(); 
		let desc = style( 
		("\n".to_string() + c.description().trim()) 
		.split('\n') 
		.join("\n "), 
		) 
		.dim(); 
  
		(format!("{title}{desc}",), chosen.contains(c)) 
		}) 
		.collect_vec(); 
  
		let Some(chosen_indices) = MultiSelect::new() 
		.with_prompt( 
		format!( 
		"RiseDev includes several components. You can select the ones you need, so as to reduce build time\n\n{}: navigate\n{}: confirm and save {}: quit without saving\n\nPick items with {}", 
		style("↑ / ↓ / ← / → ").reverse(), 
		style("Enter").reverse(), 
		style("Esc / q").reverse(), 
		style("Space").reverse(), 
		) 
		) 
		.items_checked(&items) 
		.max_length(ITEMS_PER_PAGE) 
		.interact_opt()? else { 
		return Ok(None); 
		}; 
  
		let chosen = chosen_indices 
		.into_iter() 
		.map(|i| all_components[i]) 
		.collect_vec(); 
  
		Ok(Some(chosen)) 
		} 
  
		fn main() -> Result<()> { 
		let opts = RiseDevConfigOpts::parse(); 
		let file_path = opts.file; 
  
		let chosen = { 
		if let Ok(file) = OpenOptions::new().read(true).open(&file_path) { 
		let reader = BufReader::new(file); 
		let mut enabled = vec![]; 
		for line in reader.lines() { 
		let line = line?; 
		if line.trim().is_empty() || line.trim().starts_with('#') { 
		continue; 
		} 
		let Some((component, val)) = line.split_once('=') else { 
		println!("invalid config line {}, discarded", line); 
		continue; 
		}; 
		if component == "RISEDEV_CONFIGURED" { 
		continue; 
		} 
		match Components::from_env(component) { 
		Some(component) => { 
		if val == "true" { 
		enabled.push(component); 
		} 
		} 
		None => { 
		println!("unknown configure {}, discarded", component); 
		continue; 
		} 
		} 
		} 
		enabled 
		} else { 
		println!( 
		"RiseDev component config not found, generating {}", 
		file_path 
		); 
		Components::default_enabled().to_vec() 
		} 
		}; 
  
		let chosen = match &opts.command { 
		Some(Commands::Default) => { 
		println!("Using default config"); 
		Components::default_enabled().to_vec() 
		} 
		Some(Commands::Enable { component }) => { 
		let mut chosen = chosen; 
		chosen.push(*component); 
		chosen 
		} 
		Some(Commands::Disable { component }) => { 
		chosen.into_iter().filter(|x| x != component).collect() 
		} 
		None => match configure(&chosen)? { 
		Some(chosen) => chosen, 
		None => { 
		println!("Quit without saving"); 
		println!("========================="); 
		return Ok(()); 
		} 
		}, 
		}; 
  
		println!("=== Enabled Components ==="); 
		for component in all::<Components>() { 
		println!( 
		"{}: {}", 
		component.title(), 
		if chosen.contains(&component) { 
		style("enabled").green() 
		} else { 
		style("disabled").dim() 
		} 
		); 
		} 
  
		println!("Configuration saved at {}", file_path); 
		println!("========================="); 
  
		let mut file = BufWriter::new( 
		OpenOptions::new() 
		.write(true) 
		.truncate(true) 
		.create(true) 
		.open(&file_path) 
		.context(format!("failed to open component config at {}", file_path))?, 
		); 
  
		writeln!(file, "RISEDEV_CONFIGURED=true")?; 
		writeln!(file)?; 
  
		for component in all::<Components>() { 
		writeln!(file, "# {}", component.title())?; 
		writeln!( 
		file, 
		"# {}", 
		component.description().trim().split('\n').join("\n# ") 
		)?; 
		if chosen.contains(&component) { 
		writeln!(file, "{}=true", component.env())?; 
		} else { 
		writeln!(file, "# {}=true", component.env())?; 
		} 
		writeln!(file)?; 
		} 
  
		file.flush()?; 
  
		println!( 
		"RiseDev will {} the components you've enabled.", 
		style("only download").bold() 
		); 
		println!( 
		"If you want to use these components, please {} in {} to start that component.", 
		style("modify the cluster config").yellow().bold(), 
		style(RISEDEV_CONFIG_FILE).bold(), 
		); 
		println!("See CONTRIBUTING.md or RiseDev's readme for more information."); 
  
		Ok(()) 
		}


La sortie de l’éditeur RisingWave intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » 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 de langages comme le C ou le C++.

Sources : RisingWave

Et vous ?

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 12/02/2023 à 14:55
Citation Envoyé par denisys Voir le message
Mais, ce langage de programmation, va continuer d’évoluer.
Donc, ne pas raté la marche du progrès !!!
Très mauvais argument. Il y a plein de technologies qui ont été annoncées comme la prochaine révolution et qui n'ont jamais percé.
Choisir une technologie ne doit pas être fait sur ce genre de spéculation qui se révèlent souvent fausses.

Citation Envoyé par Anselme45 Voir le message
Et quand apparaîtra un successeur à Rust qui sera bien évidemment "plus mieux, super génial, à la mode" que Rust, ils feront quoi? Réécrire de zéro leur produit?
Mettre à la poubelle un projet mature et fonctionnel pour le recommencer de zéro dans un autre langage est par définition une... connerie!
Ils feront probablement la même chose que quand ils se sont posé la question de passer ou non au Rust : une analyse du coût de la transition comparé au gain attendu.

Clairement pour un grand nombre de projets C++ historiques, une réécriture complète en Rust, juste pour être à la mode, ça serait idiot, et même s'il y a des gains à espérer les coûts seront probablement trop élevés. Mais pour le cas donné en exemple, même s'il faudrait plus d'informations pour statuer vraiment, ça ne me parait pas forcément une mauvaise idée. Ils semblent avoir de vrais soucis sur des problématiques auxquelles Rust apporte des solutions, et comme il s'agit d'un projet encore récent, le coût du portage ne devrait pas être si élevé que ça.

Citation Envoyé par ParseCoder Voir le message
Abandonner un vieux projet en C++ qui a mal vieillit pour partir sur du Rust, pourquoi pas, ça peut se justifier. Mais démarrer un projet en C++ et laisser tomber 7 mois plus tard seulement ça paraît être un beau gachis.
Je dirais plutôt que c'est le contraire. Si le projet est prévu pour durer des années, mieux vaut recommencer tôt sur de bonne bases tant que le code n'est pas trop complexe et que les équipes qui l'ont réalisé n'ont pas encore trop bougé. Plus le projet aura accumulé d'historique, plus le changement sera complexe.

Citation Envoyé par ParseCoder Voir le message
Le fait que Rust offre des garanties garanties en termes de sécurité mémoire, ils le savaient sûrement 7 mois avant. On dirait plutôt qu'ils n'avaient pas les devs C++ capables de faire le job.
Et en effet, le choix des technologies dépend aussi des compétences des développeurs que l'on a à disposition. Parce que les développeurs C++ capable d'être efficace sur des gros projets avec du multi-threading complexe, c'est pas courant, Rust peut avoir un réel intérêt.

Citation Envoyé par Padget Voir le message
le langage c++ évolue encore énormément. rien n'empêcherait de rajouter ce qu'il faut pour prévenir le data race et la sécurité mémoire à la compilation ( même si une partie du boulot est fait avec les smartpointer)
Si c'était aussi simple ça serait fait depuis longtemps mais la rétrocompatibilité empêche de faire tout ce que l'on veut avec un langage. La prévention des data race en Rust se fait par un ensemble de fonctionnalités qui sont au mieux difficile a adapter au C++, voire impossible sans mettre au rebut une partie des fonctionnalités du langage.
6  2 
Avatar de prisme60
Membre régulier https://www.developpez.com
Le 14/02/2023 à 12:16
le langage c++ évolue encore énormément. rien n'empêcherait de rajouter ce qu'il faut pour prévenir le data race et la sécurité mémoire à la compilation ( même si une partie du boulot est fait avec les smartpointer)
Pour les data races, il faut utiliser des protections à base de Mutex. Les smart pointer permettent juste une libération automatique de la mémoire quand le compteur de référence arrive à zéro, cette opération ne peut être faite qu'à l'exécution. Il ne protège en rien des accès concurrentiels.
Par ailleurs, en C++, rien ne t'oblige à utiliser des fonctionnalité t'assurant de la bonne gestion mémoire comme les smart pointers, alors que le Rust ne permettra pas d'utiliser un objet dont la vie n'est pas valide. On évite obligatoirement les dangling pointers.

Comme il est écrit dans le présent article, des ingénieurs google ont tentés de mettre en place des protections similaires à celle de Rust, mais le langage et les types ne s'y prêtent pas, le langage C++ ne sera jamais bulletproof.
3  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 11/02/2023 à 12:27
Est ce que le véritable intérêt de rust ne serait pas que pour arriver au même résultat de qualité/perf/sécurité il faut moins de temps et/ou expérience et donc inévitablement ça coûte moins cher ?
3  2 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 11/02/2023 à 21:17
Je pense que ça ne sera pas le seul cas comme ça où des habitués de C ou C++ sont confrontés à du débogage difficile sur du multi-threading et passeront sur Rust... peut être lié à la connaissance de l'équipe de du C/C++ (et quand on connais bien un langage on ne veut pas forcément en changer car on bascule dans une position moins confortable).
2  1 
Avatar de thamn
Membre averti https://www.developpez.com
Le 14/02/2023 à 4:06
Citation Envoyé par Padget Voir le message
le langage c++ évolue encore énormément. rien n'empêcherait de rajouter ce qu'il faut pour prévenir le data race et la sécurité mémoire à la compilation ( même si une partie du boulot est fait avec les smartpointer)
Il y a bien du travail sur les "sanitizers", mais ça n'est pas du tout une panacée. A l'usage, ça aide parfois pas mal, mais comme toujours c'est pas forcement bien supporté par tous les compilateurs, ça donne pas mal de faux positifs pour certains sanitizers, et c'est parfois salement plus lent, et c'est de l'analyse dynamique dans le sens ou tu dois faire tourner ton programme pour detecter les erreurs, ça amene une petite saveur Javascript qui rend l'experience assez dégueulasse.
Et aussi, il existe des trucs pour faire de l'analyse de code statique, comme Coverity, Cppcheck et d'autre encore, et c'est pas non plus la panacée.

Alors non, il semblerait qu'il y ait pas mal de choses qui empêche de rajouter ce qu'il faut au C++ pour juste s'approcher de ce que Rust propose.
1  0 
Avatar de selmanjo
Membre régulier https://www.developpez.com
Le 20/02/2023 à 10:20
C'est pas un problème !
Passer à Rust ne veut pas dire ne plus utiliser c++ !
En entreprise, on ne prend pas des décisions à la légère !
1  0 
Avatar de ParseCoder
Membre averti https://www.developpez.com
Le 11/02/2023 à 23:11
Abandonner un vieux projet en C++ qui a mal vieillit pour partir sur du Rust, pourquoi pas, ça peut se justifier. Mais démarrer un projet en C++ et laisser tomber 7 mois plus tard seulement ça paraît être un beau gachis. Le fait que Rust offre des garanties en termes de sécurité mémoire, ils le savaient sûrement 7 mois avant. On dirait plutôt qu'ils n'avaient pas les devs C++ capables de faire le job.
2  2 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 14/02/2023 à 22:34
Citation Envoyé par prisme60 Voir le message

Comme il est écrit dans le présent article, des ingénieurs google ont tentés de mettre en place des protections similaires à celle de Rust, mais le langage et les types ne s'y prêtent pas, le langage C++ ne sera jamais bulletproof.
Pour la gestion de mémoire, il existe au moins une solution. Et cette solution existe depuis la création de MacOS. Sur la Mac, vous réservez des de l'espace mémoire au démarrage du programme. Et chaque que vous utilisez de la mémoire par le biais d'un speudo-pointer, le système soustrait le contenu de votre réserve de mémoire. Cela ressemble beaucoup a un système à ramasse-miette. Mais ce système n'est pas au niveau du langage, mais du SO.

Ces speudo-pointeurs sont en réalité des doubles pointeurs. Le programmeur réserve et libère de la mémoire avec les pointeurs primaires. Mais le SO fait la véritable libération de mémoire.

Si le sujet vous intéresse, rechercher "handle" dans le documentation sur MacOs. Les "handles" du Mac n'ont rien de comparable au "handle" de Microsoft".

Citation Envoyé par prisme60 Voir le message
Le langage C++ ne sera jamais bulletproof.


Pour des programmeurs qui ne sont pas capable des faire des destructeurs de conteneurs, c'est évident. Les objets ne sont pas autre chose que des "Struct" avec une désignation différentes. Donc tout ce qui est possible avec les structures en Rust peut-être implanté en C++.
0  0 
Avatar de denisys
Membre chevronné https://www.developpez.com
Le 10/02/2023 à 18:09
Faut-il arrêter d’initier de nouveaux projets en C++ et passer à Rust ?
Je ne sais pas !!
Mais ce dont je suis sur, c’est qu’il est préférable d’apprendre ce langage !!
J’ai apprit le C et le C++ , dans le passé .
Si aujourd’hui, je ne programme plus avec c’est langages de programmation,
il n’en reste pas moins que sans ces bases,
je ne comprendrais pas le langage Rust .
Qui pour moi a un fort héritage .C++ .
Mais, ce langage de programmation, va continuer d’évoluer.
Donc, ne pas raté la marche du progrès !!!
2  3 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 11/02/2023 à 10:37
Et quand apparaîtra un successeur à Rust qui sera bien évidemment "plus mieux, super génial, à la mode" que Rust, ils feront quoi? Réécrire de zéro leur produit?

Mettre à la poubelle un projet mature et fonctionnel pour le recommencer de zéro dans un autre langage est par définition une... connerie!

Pourquoi? Le développement d'une solution ne se limite pas à pondre des lignes de code, il y a un long cheminement d’identification et de correction du bugs jusqu'à obtenir une solution viable!

Pensée émue pour un client qui a été victime de son nouveau chef informatique: le mec arrive dans l'entreprise en mode "avec moi tout va changer", il décide qu'il faut refaire de zéro LE produit de l'entreprise avec Silverlight de Microsoft... Résultat final? Silverlight est officiellement abandonné par Microsoft 3 mois plus tard, le "monsieur je sais tout" abandonne son poste pour un poste mieux rémunéré (ne dit-on pas "quand les rats quittent le navire..."?) et l'entreprise en question? Elle a fait faillite!
5  6