[scoutt]

> Rust looks like C

I program in C for a living, and no, Rust doesn't look like C. In fact, one of the things that keeps me away from learning Rust is that it is so complicated in terms of syntax.

Today I was reading this HN entry (https://news.ycombinator.com/item?id=24404628) and there is a little Rust code snippet towards the end, and I was thinking "this is so fck'd up, I'll never grasp Rust".

> Languages have to basically look like C

I wish they do.

[vvillena]

Rust has more syntax than other languages, but it's a cleverly designed language: every bit of syntax has one unique, clear meaning. Every bit of Rust syntax is intentional, and the official Rust documentation helps explain the reason behind it, with the reason usually being "the programmer is forced to make a choice that is usually implicit in other languages, and we want the code to explicitly show the choice the programmer made".

[scoutt]

I love the intention and the motivation behind the reasons they choose to define new syntax, but in what syntax regards, I tend to prefer less, not more. To me, things aren't clearer by adding more text or context.

"...perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away..." - Antoine de Saint Exupéry

[pornel]

You're overthinking it. Rust's syntax is not that complicated, even if it looks a bit scary before you read the book. For C programmers the real hard part is in semantics of references, which C programmers mistake for general-purpose pointers, and gloss over ownership.

Rust has an intentional well thought-out approach to what it makes explicit[1], which is useful in a language that is focused on control, correctness, and performance. It's not trying to make source code beautiful, it's trying to balance usability of the language with avoidance of surprises caused by implicit compiler magic.

[1]: https://boats.gitlab.io/blog/post/2017-12-27-things-explicit...

[acqq]

> Rust is ... so complicated in terms of syntax.

> there is a little Rust code snippet towards the end, and I was thinking "this is so fck'd up, I'll never grasp Rust"

After you mentioned it, I had to try to read it, and not programming in Rust, I'm surprised that there was a need to "clone" the "references" to the single value which would be accessed by each spawned thread using the "Arc" "reference counter."

A question for those who really know Rust:

As it is a single value, in C or C++ I could do the atomic access without any "cloning" and doing "reference counting" with something like "Arc" and it would still be safe. What am I missing? Was it necessary in Rust or was it an example of a demonstration that did more than actually needed?

For me, it's always more than just syntax that is to understand.

[steveklabnik]

In C++ terms, Arc is a shared_ptr. clone bumps the reference count up. You only need to do that if you want another owner. If you don't, you can take a regular old reference to the contents of the arc.

The core issue here is that it's not clear (from the snippet, but also to the compiler due to the type signatures) when the threads join. If they're joined in the same scope, they could use "scoped threads" instead, which would remove the need for the arc alltogether.

[acqq]

> it's not clear (from the snippet, but also to the compiler due to the type signatures) when the threads join.

Thanks. Assuming the join indeed immediately follows the snippet, what were the needed changes in the type signatures in this case? I’d like to know the “good” and “idiomatic” example (which avoids doing more than needed) for that example.

[steveklabnik]

    use scoped_threadpool::Pool;
    use std::sync::Mutex;
    
    const N: u32 = 3;
    
    fn main() {
        let mut pool = Pool::new(N);
    
        let data_mutex = Mutex::new(vec![0, 1, 2, 3, 4]);
        let res_mutex = Mutex::new(0);
    
        pool.scoped(|scoped| {
            for _ in 0..N {
                scoped.execute(|| {
                    let mut data = data_mutex.lock().unwrap();
                    
                    let result = data.iter().fold(0, |acc, x| acc + x * 2);
                    
                    data.push(result);
                    
                    *res_mutex.lock().unwrap() += result;
                });
            }
        });
        
        println!("{:?}", res_mutex);
    }

I kept the variable names similar to hopefully make it easy to see the transformation. Here, instead of using thread::spawn, we use a scoped threadpool. Effectively, rather than saying "take this closure and run it on a thread" like thread::spawn does, this uses "scoped.execute", which is like spawn, but ties the lifetime to the variable "scoped". This lets the compiler understand that all of these threads will be joined inside the given scope, and so it's able to grok the lifetimes. That variable is zero-sized and so will compile away to nothing.

(You still need the mutexes because multiple threads are writing to the same variables at the same time; imagine if we didn't push the result onto the vector; we could drop the mutex around it entirely, which would simplify things even further. See the example here, where because we are accessing disjoint parts of the vector, we can use no mutexes at all: https://crates.io/crates/scoped_threadpool

[acqq]

Thanks!

> You still need the mutexes because multiple threads are writing to the same variables at the same time

I understand that for the "data" for which the push exists. Do we however need it for res_mutex when the value that we want to update is a single (I guess integer) variable for which atomic add could be performed? Is there something like atomic add?

[steveklabnik]

Oh, duh, yes. one line added, two lines changed, I've left them at their indent levels and left the variable name the same:

    use std::sync::atomic::{AtomicU32, Ordering};
    
        let res_mutex = AtomicU32::new(0);

                    res_mutex.fetch_add(result, Ordering::SeqCst);

[scoutt]

I think the snippet is part of the example code for Mutex. Here: https://doc.rust-lang.org/std/sync/struct.Mutex.html

After "It is sometimes necessary to manually drop the mutex..."

[steveklabnik]

Ah ha! I should have recognized it, given that I'm pretty sure I wrote that, haha.

Incidentally, this is one reason why I've been advocating for a return of scoped threads to libstd; I can't change this example to be the "good" one, because we don't refer to external packages and we don't have scoped threads built-in.