One way of looking at Rust is that it is kinda at the intersection of three different language families: {Ruby,Python,JavaScript} x {C,C++} x {OCaml, Haskell, Scala}

“Needs” is a bit strong but “may find some things familiar and therefore easier” is a common refrain.

That makes more sense. I'd probably phrase it as: "if you are familiar with a lower-level language and a functional language, you'll likely have an easier time learning Rust".

Yup, I’d agree with that.

Not the OP, but I agree. Also, coming to Rust from a higher level language is very hard. Beginners who do so cannot understand why something like this:

    fn foo() -> &str {
        &String::from("foo")
    }

Does not work. Whereas coming from C or C++, you will appreciate the safety guarantees the borrow checker is giving you.

Learning Rust coming from an OO background is also hard, as you have to adapt to the more functional approach of the Rust type system.

There's definitely content to be learnt. But I'm not sure I'd say it's very hard. I came from JavaScript, and I found that the Rust Book was very good at explaining these kind of issues, so even though they were new to me they didn't cause too many problems.

That makes more sense - it's definitely true that knowing a lower-level language and a functional language gives you a leg up when learning Rust.

As for your example, even C and C++ devs would squint a bit at why that code doesn't compile: you're allocating a string on the heap, so why can't you return a pointer to it? Also, I think str vs. String is usually confusing at first, regardless of your background.

I think analogous C++ code is a bug, the text might be a heap allocation (SSO may stash it inside the object) but surely the string object is local and lives on the stack. When the function returns that local object no longer exists and the reference to it is now dangling ?

I would say that the relationship between str and String was what most surprised me. I at first assumed the underlying primitive would be String since str is what you get when you borrow from a String, but it isn't. str is a built-in, whereas String is just a type defined in the (optional, this is a systems language) standard library.

If your environment can't afford memory allocation, you can't have Strings but you can use str just fine, that's a built-in. Since you lack allocators obviously you won't be going around minting new strings but str is perfectly fine for stuff like substring operations or comparisons.

> Also, I think str vs. String is usually confusing at first, regardless of your background.

Yes, of course. Rust has some new concepts that will be confusing at first, regardless of your background. You still have to understand Rust's destructors to understand that example. I didn't mean to say that it is impossible for Rubyists to learn Rust, or that C++ devs would understand Rust immediately.

Perhaps a better example:

    fn foo() -> &usize {
        let x = 50;
        &x
    }

From my experience I found the ideas of move semantics from modern C++ directly relatable to ownership and move vs borrow. I also found the FP ideas from Scala, pattern matching, combinators, result and option monads directly useful in rust.

I would have said it was mor like ocaml.