C'est un système de lock pour les problèmes d'accès concurrents ? [...]
Non pas du tout. Alors n'étant (encore :) ) pas un spécialiste du langage, mon explication va être un peu légère. En gros tout est fait à la compilation (un lock serait fait au runtime), où le compilateur, via son borrow checker, vérifie plusieurs choses comme:
- les temps de vie des objets. Par exemple si on retourne une référence sur un attribut d'un objet, alors le temps de vie de cette référence ne peut excéder celui de l'objet lui-même. Le borrow checker peut donc détecter des cas où on essaye de stocker cette référence en dehors du scope de vie de l'objet lui-même (un cas de dangling pointer comme on peut en trouver en C/C++).
- lorsqu'on passe une référence mutable à une fonction, on lui délègue la responsabilité de cette référence, et on ne peut plus utiliser cette référence dans la suite du code.
En pratique cela oblige à écrire le code de manière à satisfaire le borrow checker (sachant qu'il est régulièrement amélioré pour être moins stupide—il y a des fois où il est évident pour l'humain qu'il n'y a pas de problème, mais ça ne l'est pas pour le borrow checker). L'écriture des structure de données classiques est donc tout un art (heureusement le boulot est déjà fait !).
Au final c'est un peu comme quand les langages fonctionnels, qui en promouvant l'immuabilité et l'abandon des variables globales par exemple (ce que Rust fait aussi), obligent à penser son code d'une manière naturellement plus robuste.
J'espère avoir été clair.
Et on peut aussi manipuler des références (mais là c'est sans garde-fou) et faire de la programmation système en OCaml (la seule limite actuelle, c'est le GC qui ne gère pas les accès concurrents sur la major heap ce qui pose problème pour le parallélisme, cf multicore OCaml).
Ocaml permet de faire de la programmation système (ce qui ne veut pas dire grand chose, mais disons qu'un langage compilé nativement, avec de bonnes performances, qui permet de manipuler threads/sockets..., rentre dans cette appellation), mais à l'instar de Go par exemple, il ne peut pas être qualifié de langage système à cause de la présence obligatoire du GC (attention je n'ai jamais dit que tu avais affirmé que c'était un langage système—mais la précision me tient à cœur), tandis que Rust peut se passer complètement de runtime. Ça n'en fait pas un meilleur langage, c'est juste qu'ils ont des desseins différents.
[^] # Re: On s'en bat le steak
Posté par GuieA_7 (site web personnel) . En réponse au journal Typage statique pour Python. Évalué à 2.
Non pas du tout. Alors n'étant (encore :) ) pas un spécialiste du langage, mon explication va être un peu légère. En gros tout est fait à la compilation (un lock serait fait au runtime), où le compilateur, via son borrow checker, vérifie plusieurs choses comme:
- les temps de vie des objets. Par exemple si on retourne une référence sur un attribut d'un objet, alors le temps de vie de cette référence ne peut excéder celui de l'objet lui-même. Le borrow checker peut donc détecter des cas où on essaye de stocker cette référence en dehors du scope de vie de l'objet lui-même (un cas de dangling pointer comme on peut en trouver en C/C++).
- lorsqu'on passe une référence mutable à une fonction, on lui délègue la responsabilité de cette référence, et on ne peut plus utiliser cette référence dans la suite du code.
En pratique cela oblige à écrire le code de manière à satisfaire le borrow checker (sachant qu'il est régulièrement amélioré pour être moins stupide—il y a des fois où il est évident pour l'humain qu'il n'y a pas de problème, mais ça ne l'est pas pour le borrow checker). L'écriture des structure de données classiques est donc tout un art (heureusement le boulot est déjà fait !).
Au final c'est un peu comme quand les langages fonctionnels, qui en promouvant l'immuabilité et l'abandon des variables globales par exemple (ce que Rust fait aussi), obligent à penser son code d'une manière naturellement plus robuste.
J'espère avoir été clair.
Ocaml permet de faire de la programmation système (ce qui ne veut pas dire grand chose, mais disons qu'un langage compilé nativement, avec de bonnes performances, qui permet de manipuler threads/sockets..., rentre dans cette appellation), mais à l'instar de Go par exemple, il ne peut pas être qualifié de langage système à cause de la présence obligatoire du GC (attention je n'ai jamais dit que tu avais affirmé que c'était un langage système—mais la précision me tient à cœur), tandis que Rust peut se passer complètement de runtime. Ça n'en fait pas un meilleur langage, c'est juste qu'ils ont des desseins différents.
Au passage, un petit article, que j'ai lu récemment, sur les problèmes qu'un GC peut poser (ici en Haskell): https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/