[steveklabnik]

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles.

That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. How do I get the compiler to shut up and do X?" and the reply would be something like "what if there was another thread? that's what Rust is saving you from" or "Rust's pointer rules are different than the language you're used to."

Whereas folks from scripty backgrounds don't have preconceived notions of "I should be able to do this in this way," and so tend to trust the compiler more. Heck, that's why a lot of them are learning Rust instead of C; they know the compiler can help them out, and C's compilers cannot to the same degree.

Now, that doesn't mean that scripty people don't struggle, or that C and C++ developers don't have their own advantages in learning. Just that I don't think it's straightforward to say who has the overall easier time. It's more of a "having learned something like C or C++ does not universally advantage you."

[shrimp_emoji]

Ha. Given that the C and C++ compilers optimize your code by inferring undefined behavior and other crazy stuff like that, it's funny to imagine you're not just playing with just another code generator. :p

(In fact, if you decide to be responsible about what you're telling your poor compiler to do and use a `size_t i` instead of an `int i` in your for loop, since iteration can never go negative and, if overflow happens, overflow on a signed type is worse since that's UB, I think you just made your for loop slower since all the optimizations the compiler was going to generate from inferring that iteration won't be infinite because that would overflow the `int i` and that would be UB so it can just ignore the possibility that the iteration would be infite went out the window and...man I really need to switch to Rust.)

((I've pretty painlessly learned and love Rust, btw. I'm still using C at home lately though cuz... masochism.))

[steveklabnik]

I agree with you, but many trot out the "portable assembly" line.

[dureuill]

Thanks for the elaboration. Now I'm wondering if this hasn't something to do with bottom-up people vs top-down people and their natural affinity towards lower level or higher level languages.

I'm very top-down, always starting by sketching the API I'd like to see for the feature, and then filling in the implementation. A lot of people I know from C++ are bottom-up, they toy with the implementation and then go up to the API. I found that what they like in systems programming is being close to the machine, while my interest lies in the OS boundaries and interfaces, not really the hardware.

I'm thinking maybe those different ways of approaching programming make it easier or harder to learn rust.

[steveklabnik]

I think that's possibly insightful, yeah. A similar effect: a lot of people say "Rust is bad for exploratory programming because the compiler gets in your way." For me, it's fantastic for exploratory programming specifically because when I change something, it gives me a list of the other things I need to change! That's huge! But for others, it seems to harsh their buzz. I don't know how to reconcile these opinions other than "they're opinions and different people are different."