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 2023-02-10 17:17:06, par Patrick Ruiz, Chroniqueur Actualités
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.
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
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 : |
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 ?
Voir aussi :
-
UtherExpert éminent séniorTrè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.
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.
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.
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.
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.le 12/02/2023 à 14:55 -
prisme60Membre régulierle 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)
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.le 14/02/2023 à 12:16 -
grunkModérateurEst 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 ?le 11/02/2023 à 12:27
-
smartiesExpert confirmé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).le 11/02/2023 à 21:17
-
thamnMembre avertiIl 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.le 14/02/2023 à 4:06 -
selmanjoMembre régulierC'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 !le 20/02/2023 à 10:20 -
ParseCoderMembre avertiAbandonner 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.le 11/02/2023 à 23:11
-
MadmacMembre extrêmement actifPour 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".
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++.le 14/02/2023 à 22:34 -
denisysMembre chevronnéFaut-il arrêter d’initier de nouveaux projets en C++ et passer à Rust ?
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 !!!le 10/02/2023 à 18:09 -
Anselme45Membre extrêmement actifEt 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!le 11/02/2023 à 10:37