Then again, often
#pragma omp for
#pragma omp for
OpenMP does nothing to prevent data races, and anything beyond simple for loops quickly becomes difficult to reason about.
It is easy to divide loop body into computation and share info update, the latter can be done under #pragma omp critical (label).
The we have the anecdotal "They failed firefox layout in C++ twice then did it in Rust" < to this I sigh in chrome.
It's also true that for both, it's not always as easy as "just make the for loop parallel." Stylo is significantly more complex than that.
> to this I sigh in chrome.
I'm actually a Chrome user. Does Chrome do what Stylo does? I didn't think it did, but I also haven't really paid attention to the internals of any browsers in the last few years.
The hard part isn't splitting loop iterations between threads, but doing so _safely_.
Proving an arbitrary loop's iterations are split in a memory safe way is an NP hard problem in C and C++, but the default behavior in Rust.
Naturally nothing on C++ prevents someone to do that, which is why PVS, Sonar and co exist.
Just like some things aren't prevented by Rust rather clippy.
You write concurrent code in Rust pretty much in the same way as you would write it in OpenMP, but with some extra syntax. Rust catches some mistakes automatically, but it also forces you to do some extra work. For example, you often have to wrap shared data in Arc when you convert single-threaded code to use multiple threads. And some common patterns are not easily available due to the limited ownership model. For example, you can't get mutable references to items in a shared container by thread id or loop iteration.
This would be a good candidate for a specialised container that internally used unsafe. Well, thread id at least; since the user of an API doesn't provide it, you could mark the API safe, since you wouldn't have to worry about incorrect inputs.
Loop iteration would be an input to the API, so you'd mark the API unsafe.