# Newcomer to Rust: my experience **URL:** \ **Category:** documentation\ **Created:** [April 6, 2015, 1:54pm UTC](https://internals.rust-lang.org/t/newcomer-to-rust-my-experience/1816 "2015-04-06T13:54:30Z")\ **Posts on this page:** 1\ **Showing post:** 52
**Author:** ![qwertie](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/qwertie/32/152_2.png) [@qwertie](https://internals.rust-lang.org/u/qwertie)\ **Post date:** [April 10, 2015, 9:26pm UTC](https://internals.rust-lang.org/t/newcomer-to-rust-my-experience/1816/52 "2015-04-10T21:26:30Z")
@nrc I don’t think Rust is a great first programming language, but I think it’s better than C++, which my university has been teaching as a first programming language for the last 15 years or so. @steveklabnik here are the notes I’ve been taking while reading through the Intermediate sections. Looks like a big reorganization is in progress, so I better post this while it still has some relevance. ### Pointers - This section explains why we should use `&T` in preference to `Box`, _before_ introducing `Box`. - It doesn’t say _why_ you can’t lend an mutable reference and another reference to the same value at the same time. (I remember hearing a rationale for this, involving enums, that seems irrelevant to why one can’t double-borrow simpler types like i32, but regardless of what the rationale is, it should be provided.) ### More strings - We are told “References to Strings will automatically coerce into &strs”, but it doesn’t say why or how. It also doesn’t explain very clearly what the difference between `str` and `String` is. It says when to use which type, but since this is a systems language I’d like to hear an explanation in terms of memory layout. - It doesn’t say why there is a `true` in `for l in s.graphemes(true)`. ### Method Syntax: - it says one can “return self” to accomplish method chaining like `foo.bar().baz()`. This is true, but it refers to this as the “original example”, which is incorrect. The original example was `x.foo().bar().baz()` and it was given as an alternate syntax for `baz(bar(foo(x)))` in which no one would assume that each function returns `self` (`x`). ### Associated types - What does the first line mean? ### Closures - “Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment.” Although I know what a closure is, the phrase “close over an environment” isn’t meaningful to me. Must be a math thing. - I think rationales should be stated more explicitly. Instead of saying we don’t need to write the types of closure arguments because “they don’t cause the kinds of error-at-a-distance that inferring named function types can,” restate the fact that “Rust supports type inference, but doesn’t allow it on top-level functions because [blah blah blah]. For closures, however, these reasons don’t apply / these problems are not so severe / the benefits were felt to outweigh the drawbacks.” Although the “Basics - functions” section talked about this issue a little, it doesn’t hurt to repeat yourself, once, 15 sections later, especially since experienced developers may have skipped the Basics entirely. - The subsection on “move closures” is confusing because the previous example showed that variables are already moved into the closure _without_ the `move` keyword, whereas the book says that the initial example with `move` gets a _copy_ of `num`. The second example with `move` is also confusing, because the closure appears to get a _copy_ of `num`, so I’m puzzled how the word `move` is relevant at all. Indeed, I am wondering if using `move` implies that all arguments must be copyable. - the closure traits are presented as if they were normal traits, but there are two strange things about them that are not explained: 1. The syntax `Fn(A, B) -> C` is different than for all other traits. 2. Moreover it seems impossible to express closures with the normal `Trait` syntax, because `type Output` is an associated type, not a type parameter, i.e. we can write `Fn<(A, B)>`, but there’s nowhere to put the return type `C`. - C++ programmers will recognize `extern "rust-call"` as a calling convention. But isn’t this redundant? Wouldn’t all trait functions be `rust-call` by default? I think if the book includes `extern "rust-call"` it needs to explain what it’s doing there. ### Iterators: - Saying that `for i in 0..nums.len()` is “strictly worse than using an actual iterator” seems an exaggeration. Because if you use an index variable your loop will know which index of the vector it is looking at, while `for num in &nums` won’t. It’s a tradeoff. - The statement _"Why does `&nums` give us references? Firstly, because we explicitly asked it to with `&`"_ is strange. There is no obvious connection between `&nums` and "`&(nums[i])` for each possible `i`". - It is unclear why `for num in &nums` was later changed to `for num in nums.iter()`. - Why doesn’t `for i in (1..100).filter(|&x| x % 2 == 0)` say `*x % 2`? ### Generics: - A missed opportunity to give a rationale. The section ends by discussing _"error: binary operation `==` cannot be applied to type `T`"_. C++ programmers will note that C++ does _not_ give an error like that unless the template is instantiated with a T that actually has no `==` operator. The opportunity here is to explain that if a generic function compiles at all, then it will work correctly for all Ts that meet the constraints in the function signature. Hmm… this does mean that you’d have to have to introduce a constraint that includes `==` before the traits section. But that’s okay, there’s no need to know what a trait is before revealing `T: Float`. ### Traits - `PartialEq` is a strange name. How is it “partial”? ### Static & dynamic dispatch: - The VTable “example” is very confusing, firstly because it appears to be Rust code but on closer inspection seems to be a kind of pseudocode, secondly because it uses notations that were never introduced before, like `x as *const u8`, thirdly because `call_method_on_u8` calls `byte.method()` somehow, even though `call_method_on_u8` does not mention `Foo` nor `FooVtable`, and fourthly because there’s no apparent reason why the parameter `x` points to `()` instead of the type to which `x` is immediately cast. Finally, it seems to me that next to the pseudo-Rust we should be shown some normal Rust that the pseudo-Rust is supposed to represent. Since Rust is a systems language, isn’t it possible to write some code that is actually compiles & runs and is equivalent to what the normal Rust code does? ### Macros: - I’m confused about this “vec” macro. It was shown with the syntax `vec![1,2,3]` but the square brackets are nowhere to be seen in the `macro_rules`. - I suggest changing the `o_O` macro to use the syntax `10 + [1, 2, 3]` instead of `10; [1, 2, 3]` so it’s more obvious what the macro is supposed to do. ### Concurrency: - The problem with `Mutex` is fixed by introducing `Arc`, but you didn’t explain the fact that `let data = data.lock().unwrap();` was orginally outside the closure and then was moved inside. I think the first version was inherently wrong, `Arc` or no `Arc`. - You mention that `data.lock()` may fail to acquire the mutex, but why would it fail? Doesn’t `lock()` wait for the shared resource to become available? - At the same location you do something that will baffle many programmers, `let mut data = data.lock().unwrap();`, in which the left and right hand side of `=` both refer to `data`. This trick wasn’t mentioned before, at least not in the Intermediate part of the book. - You seem to be suggesting that channels are somehow an alternative to using a timer to wait 50ms for threads to complete (even though you already introduced `thread::scoped`). I think it would be more appropriate to introduce `join()` at this point. ### Error handling: - "try! makes use of `FromError`" links to a page that does not mention `FromError`. Thanks for listening! --- _[View the full topic](https://internals.rust-lang.org/t/newcomer-to-rust-my-experience/1816)._