> When handing out references of something bound with let mut, why do i need to do &mut instead of just & ?<p>Sometimes, you still want to immutably borrow a mutable variable. Otherwise, you wouldn't be able to have multiple references to a variable declared with `mut`, which would be an unnecessary limitation.<p>EDIT: Here's an example of something that wouldn't otherwise work if borrows of mutable variables were implicitly mutable:<p><pre><code> struct Point {
x: i32,
y: i32,
}
fn add(p1: &Point, p2: &Point) -> Point {
let x = p1.x + p2.x;
let y = p1.y + p2.y;
Point { x: x, y: y }
}
fn main() {
let mut some_point = Point { x: 1, y: 1 };
some_point.x = 2;
// `some_point` is borrowed twice here, which wouldn't be possible if the borrows were mutable.
let other_point = add(&some_point, &some_point);
println!("({}, {})", other_point.x, other_point.y);
}</code></pre>
> As with Swift, I haven’t been able to find conclusive evidence nor credit given to suggest that there was any influence from Scala on Rust …<p>Scala was a significant influence on Rust. Niko did his dissertation in Scala, and several other team members were fans. Let it be known!
<p><pre><code> match some_int {
// Why not Some(& s) => ... ???
Some(ref s) => println!("{}",s),
None => unreachable!()
}
</code></pre>
To me his proposed syntax looks like the exact contrary use case: pattern-match on something that's a reference.<p>EDIT: And that's actually the case.<p><a href="https://play.rust-lang.org/?gist=017740fbff2c5923dec3cc514bdba2f7&version=stable&backtrace=0" rel="nofollow">https://play.rust-lang.org/?gist=017740fbff2c5923dec3cc514bd...</a><p>In that case it works because `w` is copy. For non-copy types, it prevents moving out of the borrow (as expected).<p><a href="https://play.rust-lang.org/?gist=241728575a382c54c324b0201c5f7ea5&version=stable&backtrace=0" rel="nofollow">https://play.rust-lang.org/?gist=241728575a382c54c324b0201c5...</a>
Having done scala for a few years and only dabbled in rust, I also get the impression that the rust community is trying to have good default answers to questions like how to do json, or which web framework to use. As opposed to scala-land where if you ask three scala devs those questions you'll get five answers.
Concerning cross compiling, one useful tool the author may of missed is [xargo](<a href="https://github.com/japaric/xargo" rel="nofollow">https://github.com/japaric/xargo</a>).
> If you lean more towards the functional programming paradigm side of Scala then you’ll probably love the following about Rust’s type system<p>Some of the more popular functional languages have advanced type systems, but not all functional languages are statically typed. Lisp, the granddaddy of all FP languages, is dynamically typed. So is Elixir.<p>Can we stop conflating FP with static typing?
thanks for doing this<p>two questions: from the perspective of a Scala dev, does Rust have a solid collections library (including persistent structures such as Scala's Vector type) with mutable counterparts (eg, ListBuffer)?<p>second, from a quick glance it seems Rust's top-level concurrency model (locks, thread ownership) is the polar opposite of Scala's (Actor-based)--is this correct? Scala's concurrency model (based on Erlang), along with trait-based multiple inheritance, were Scala's initial selling points for me
<p><pre><code> TL;DR:
</code></pre>
He is happy.<p>Better toolchain (environment manager, package manager, etc)<p>Macros are easier to do with Rust (than in Scala).<p>IDE: happy with MS Visual Studio Code<p>Syntax is not too different.<p>Type system: He likes it.<p>Calls C code with a similar syntax than doing it with Scala<p>Rust allows you more control on how to use your memory allocation. (Or forces you to take control).<p>-------<p>My own take on Rust (haven't used the language yet, only looked at specs) is that it appears to be a more "sane", state-of-the-art version of C++, streamlined, without all the cruft and all the legacy. And with a much better object oriented system based on Traits.