In the last exercise (05), I ran quickly tried to extend it into creating “unfloored halves” (you’ll know what I mean if you look at the exercise) … and ran into the process of initialising empty arrays.

What I hit upon is:

let mut floating_data: [f32; 5] = [0.0; 5];

Where the 0.0 in [0.0; 5] is necessary it seems?? And you can’t simply have let floating_data = [f32; 5]; … ?

From what I gathered, the general syntax is [EXPR; SIZE], where EXPR is actually evaluated, presumably to define the required memory/type, even though the type of the array (in the code above, f32) also constrains the type of elements of the array.

In the code above, as the default float type is f64, the typing of the array as [f32; 5] actually constrained or affected the way that the expression of 0.0 in the array literal was used to build the array.

So why do I need to provide both so that they interact in this weird and implicit way?? Unless I’m missing something, surely something like let floating_data = [f32; 5]; would be better? Putting that 0.0 because it just needs to be there is tolerable but a bit off IMO.

Ok, so the first exercise here 1-basic-syntax/01.rs throws me a little bit. With the compiler error it’s easy enough to fix, but conceptually I didn’t actually have this down.

fn multiply(a: i32, b: i32) {
    a * b
}

This function is invalid. The crucial error from the compiler is:

error[E0308]: mismatched types
 --> src/bin/01.rs:6:5
  |
5 | fn multiply(a: i32, b: i32) {
  |                            - help: try adding a return type: `-> i32`
6 |     a * b
  |     ^^^^^ expected `()`, found `i32`

So the quick fix it needs is a return type. That’s fine.

The bits that throw me are:

• The default return type is an empty tuple? (whatever is meant by ()).
• There is no type inference on the return type? For let v = a * b; rust is happy to infer that v: i32, why not a function’s return? I’d guess some policy of ensuring function declarations are clean with respect to types and reaping the compiling and safety features that follow that.

So getting setup to actually attempt these exercises yourself before seeing the answers in the video takes a little bit of work.

Having just got set up, I’ll share the process here. What’s nice about it is that it seems to be kinda TDD exercises … ie you run cargo run, which runs some tests, which fail, and you have to fix things until tests pass or compilation can happen. Not a bad way to write exercises IMO.

But it does require a few steps to set up the repo, which also seems to be somewhat over engineered for an introductory course (just some friendly feedback there Andy if you’re reading this).

You can see their “official” docs on this here: https://101-rs.tweede.golf/0-install/mod.html

• Have cargo installed (basically use rustup, see “The Book” or the docs linked above)
• Clone repo at: https://github.com/tweedegolf/101-rs
• Build the materials (this is basically compiling a rust program to then put the materials together from the raw content in the repo):
  • Create a directory for where you want to dump the built materials. I created intro_track/ alongside the repo’s directory
  • From inside the repo (named 101-rs, navigate to ./modmod/
  • run cargo run -- -o target/course -c ../content/rust-intro.track.toml where target/course is the directory you created above for containing these materials.
• Navigate to course (where materials were dumped). There’ll you find ./exercises/2-foundations-of-rust/1-foundations-of-rust/. In this directory will be numbered subdirectories including 1-basic-syntax and 2-move-semantics etc. Each one is a rust/cargo project and represents a module or something of the course.
• The idea being, I think, that completing the exercise will be when cargo run works without errors.