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

94PARTAGES

16  0 
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 ?

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]
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:rometheusAndGrafana => "[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:rometheusAndGrafana => {
@@ -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:rometheusAndGrafana),
"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:rometheusAndGrafana => "ENABLE_PROMETHEUS_GRAFANA",
Self::Etcd => "ENABLE_ETCD",
Self::Kafka => "ENABLE_KAFKA",
Self:ubsub => "ENABLE_PUBSUB",
Self::Redis => "ENABLE_REDIS",
Self::RustComponents => "ENABLE_BUILD_RUST",
Self:ashboard => "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:efault) => {
println!("Using default config");
Components::default_enabled().to_vec()
}
Some(Commands::Enable { component }) => {
let mut chosen = chosen;
chosen.push(*component);
chosen
}
Some(Commands:isable { 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!("===[/]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

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