Rust 1.12 Programming Language Released

[Jabberwocky]

Ezio21 people still start projects using PHP? I don't know anyone that does.
Node.js & Go seem to be popular now, and C# might also get popular with .NET Core.
Java is also being used in some new projects, it seems. But PHP? really?

Ezio21 smells like a troll.

Regardless, I have moved on from PHP years ago and I'm happy, but that does not mean that I expect every PHP dev to do the same. Is it really so difficult to believe that people are still writing good software in PHP? It used to be very popular and you know legacy systems will be around for years and years... Some large companies that still run major projects in Cobol. Yes, in 2016 people are still studying Cobol... I'm not going to say that the people studying and developing it are untalented programmers albeit quite masochistic.

[mmstick]

popular programming language

Is this a joke? I never ever heard about rust being used in some good applications, web or desktop. Everyone now uses C# or C++14 which is dying slowly too. For web everyone uses PHP, some maniacs still use python or ruby. What's rust?

This isn't a good application? This is also not a good application? This also isn't a good application?

[nslay]

I'm the author of the Parallel implementation in Rust. The borrowing system was designed exclusively for safe parallel programming practices, and it just happened to also be useful everywhere else in single-threaded applications. The book has great examples of what not to do and how to do it properly. There are also many crates available to provide higher level features and convenience, such as rayon, which provides parallel work-stealing iterators that will only execute in parallel when it improves performance, which you are looking for.

The Safe Shared Mutable State example is perfect as it is. A vector in any language, like an array, does not point to data, but pointers to memory addresses. With a mutable vector, if you were to grow the size of the vector, the vector would be allocated into a new region of memory. If you did not lock a vector within a Mutex, the other threads would continue attempting to access invalid memory addresses, not knowing that the addresses have changed. You are asking for Rust to enable support for incredibly unsafe parallel programming practices.

Thank you for your response. I disagree with your assessment of unsafe parallel programming practices and I think it's extremely foolish to force developers to lock the entire array when your parallel routine on said array may not have any dependencies on other array elements. Why can't Rust do dependency analysis or array element borrowing? There's nothing unreasonable or unsafe about accessing and assigning disjoint sets of array elements.

[nslay]

I would like to also add that when you're number crunching in parallel in C++ and eager to learn Rust to help prevent time consuming bugs that you often encounter in C++ and you reach that section on Concurrency in The Rust Book that shows an example of threads processing 3 vec elements ... it's extremely demotivational when your final solution locks the entire array. It doesn't help when the example doesn't do anything meaningful with the array either (assigning the first element). In fact, I stopped reading The Rust Book the moment I saw the final solution. I just couldn't believe it. And it was not helpful to see a stackexchange question of a person asking how to do something basic with Rust threads that is clearly known to be safe. I really love your language, but I can't use it for any of my projects until parallelism is straightforward to use. Having to use external crates and read documentation to do something so obviously safe as accessing and assigning disjoint sets of elements is just not acceptable to me.

Please update the example to do something more destructive like push back elements in the vec! at least. It will only drive more people like me away from Rust. Or add an example that does true parallel computing with an array. The example currently in The Rust Book is really bad in my opinion.

[oneofone]

popular programming language

Is this a joke? I never ever heard about rust being used in some good applications, web or desktop. Everyone now uses C# or C++14 which is dying slowly too. For web everyone uses PHP, some maniacs still use python or ruby. What's rust?

Trolling troll is trolling

[ssokolow]

Thank you for your response. I disagree with your assessment of unsafe parallel programming practices and I think it's extremely foolish to force developers to lock the entire array when your parallel routine on said array may not have any dependencies on other array elements. Why can't Rust do dependency analysis or array element borrowing? There's nothing unreasonable or unsafe about accessing and assigning disjoint sets of array elements.

Yes, but the compiler can't verify that at compile time. That's why you use things like std::cell::Arc and std::cell::RefCell, which are implemented as safe wrappers around unsafe blocks. (They use manually audited unsafe code to replace compile time checks with runtime checks, dying with a panic! if the way you're using them isn't actually a case of "safe but the compiler can't confirm it")

[plonoma]

I would like to also add that when you're number crunching in parallel in C++ and eager to learn Rust to help prevent time consuming bugs that you often encounter in C++ and you reach that section on Concurrency in The Rust Book that shows an example of threads processing 3 vec elements ... it's extremely demotivational when your final solution locks the entire array. It doesn't help when the example doesn't do anything meaningful with the array either (assigning the first element). In fact, I stopped reading The Rust Book the moment I saw the final solution. I just couldn't believe it. And it was not helpful to see a stackexchange question of a person asking how to do something basic with Rust threads that is clearly known to be safe. I really love your language, but I can't use it for any of my projects until parallelism is straightforward to use. Having to use external crates and read documentation to do something so obviously safe as accessing and assigning disjoint sets of elements is just not acceptable to me.

Please update the example to do something more destructive like push back elements in the vec! at least. It will only drive more people like me away from Rust. Or add an example that does true parallel computing with an array. The example currently in The Rust Book is really bad in my opinion.

Rust is a language still in development. Heavy development.

I would also like to have more fine grained locks for vectors.
Why not separate the vector lock into ref and value locks/mutexes?
Having a separate ref lock from value change lock for arrays/vectors would allow the compiler to analyse if an operation is doing stuff that impacts the reference/ptr of an array/vector while still allowing value changing operations.
Allowing working with elements in the array concurrently with the compiler able to do checks since value updating operations and reference changing operations are clearly distinguishable through separate types of locks.

[Khrundel]

I would like to also add that when you're number crunching in parallel in C++ and eager to learn Rust to help prevent time consuming bugs that you often encounter in C++ and you reach that section on Concurrency in The Rust Book that shows an example of threads processing 3 vec elements ... it's extremely demotivational when your final solution locks the entire array. It doesn't help when the example doesn't do anything meaningful with the array either (assigning the first element). In fact, I stopped reading The Rust Book the moment I saw the final solution. I just couldn't believe it. And it was not helpful to see a stackexchange question of a person asking how to do something basic with Rust threads that is clearly known to be safe. I really love your language, but I can't use it for any of my projects until parallelism is straightforward to use. Having to use external crates and read documentation to do something so obviously safe as accessing and assigning disjoint sets of elements is just not acceptable to me.

AFAIK, Rust encourages people to use as less shared data as possible, so, that example shows how to syncrhronize access if it is unavoidable.
Still you can crunch numbers in parallel without messing with unsafe, you should only to "split" vector between threads. You can take a mutable slice from the Vec, than split it to as many parts as you require using split_at_mut, and voila, you will have many mutable slices to process in parallel. And you need scoped threads to make sure all slices will be freed at predictable point.

[gamma_ray]

I'm really really wanting to move over to Rust. But the borrowing system makes parallel computation extremely tedious (at least for what I do).

...

Processing/accessing/assigning disjoint sets of elements of arrays with threads is a pretty common task in numerical algorithms. Rust's borrowing system makes this very difficult to do efficiently presently. It's so bad that people had to craft special libraries that chop an array up so that the borrow system will let threads own each chunk for processing to achieve true parallelism. But this is not sufficiently flexible. You may need dynamic chunks since not all elements are processed in the same amount of time.

...

If they can make the borrowing system aware of safe parallel programming paradigms, I'm definitely going to start using Rust for my projects.

It is possible in Rust, just use "chunks_mut" method on arrays as you mentioned: No need to have locks or muetexes! And if they need different amount of time you can use a thread pool that takes care of that. It's very efficient. For example the Rayon crate uses s.th. similar to Cilk (used by Intel) for data parallelism.

There is a nice mandelbrot example that shows how you can do parallel array processing with various libraries (crates).

And of course if you have any question just post them on the Rust user forum, the community is very friendly and helpfull.

[gamma_ray]

I'm curious now - if I have 2 datasets (like 2 vectors) - can I process them in a true parallel way in Rust like for example pthreads do? (I haven't learned Rust yet)

Yes you can!
There are data parallel libraries (crates) that make these kind of things really easy, for example Rayon.