Re: Rust et SIMD

Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread.

De quelles garanties tu parles ?

Le modèle de programmation parallèle de Go est intéressant mais il ne propose pas les mêmes garanties que le typage de Rust. Par exemple, ce programme compile et le résultat dépend d'une race condition : il peut afficher ["foo" "qux" "baz"] ou ["foo" "bar" "baz"].

package main
import "fmt"
func main() {
 c := make(chan []string)
 go func() {
 a := []string{"foo", "bar", "baz"}
 c <- a
 a[1] = "qux"
 }()
 b := <-c
 fmt.Printf("%q\n", b)
}

En rust, ce n'est pas possible de compiler un programme avec ce comportement. Il faudrait dire si le tableau sous-jacent au slice a est modifiable (mutable) et, si c'est le cas, les autres contextes d'exécution ne peuvent pas du tout y accéder. Ou alors, il n'est pas modifiable et peut-être partagé entre plusieurs contextes d'exécution. Si on veut pouvoir modifier le tableau dans un contexte et y accéder depuis un autre contexte, il faut en faire une copie, ce qui résout le problème de la race condition.

En pratique, c'est un problème que je rencontre de temps en temps sur cozy-stack (la partie de Cozy Cloud écrite en Go) et je considère que c'est une faiblesse de Go. Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace. À l'inverse, le modèle de Rust est plus sûr mais il est plus contraignant (on perd pas mal de temps à se battre avec les types, surtout quand on est un débutant comme moi en Rust).

Pour ce qui est de la question thread / goroutine / futures, ce n'est pas dans le langage (Rust), mais ça s'implémente bien en dehors. Par exemple, actix propose un modèle à base d'acteurs et futures.rs propose des futures.