this post was submitted on 14 Feb 2024
15 points (100.0% liked)

Learning Rust and Lemmy

391 readers
1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.


Running Projects


Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities


Thumbnail and banner generated by ChatGPT.

founded 2 years ago
MODERATORS
 

cross-posted from: https://diode.zone/videos/watch/9766d1f1-6018-48ec-ad67-e971758f8a3a

Going through some exercises on basic Rust syntax and ownership.

Links:

Rust 101 is a series of videos explaining how to write programs in Rust. The course materials for this series are developed by tweede golf. You can find more information at https://github.com/tweedegolf/101-rs and you can sponsor the work at https://github.com/sponsors/tweedegolf . They are released under the Creative Commons Attribution Share Alike 4.0 International license.

This series of videos is copyright 2023 Andy Balaam and the tweede golf contributors and is released under the Creative Commons Attribution Share Alike 4.0 International license.


These videos are roughly on track with the Reading Club apparently, so this video belongs here this week, I think.

top 9 comments
sorted by: hot top controversial new old
[–] maegul@lemmy.ml 2 points 1 year ago

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.

[–] maegul@lemmy.ml 1 points 1 year ago (2 children)

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.
[–] maegul@lemmy.ml 1 points 1 year ago

Another interesting to note here is there's a basic introduction to writing and running tests in rust!

As you'll see in the video, Andy himself seems to be a TDD guy and starts writing a test before just completing the exercise.

[–] maegul@lemmy.ml 1 points 1 year ago

I missed the last step really.

So you need to navigate into one of these subdirectories like .../1-basic-syntax/. Which, as I said above, is a rust/cargo project.

From there, you run cargo run to see if it compiles (it likely won't until you fix the code, which is the exercise).

OR, you run cargo test to run the tests (which, again, will likely not pass).

If the project has mulitple files, each being their own exercise, then you have to use --bin to specify which file/bin you want to run. EG: cargo run --bin 01 for a file named 01.rs. Or, cargo test --bin 01 for the tests in a file named 01.rs.

[–] maegul@lemmy.ml 1 points 1 year ago (1 children)

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.
[–] Jayjader@jlai.lu 2 points 1 year ago (1 children)

I think I have some answers for you if you haven't resolved them yet:

  • the default return type is not an empty tuple, but the unit type which basically represents a unit of computation being performed, without any data as output (i.e. purely side-effects are allowed). It is kinda the equivalent of void from java- and c-style languages. Here is a decent explanation on StackOverflow if you prefer that sort of thing.
  • there absolutely is inference on the return type (I've used it in other rust projects before), but I can't remember if it only, or also takes into account how the function is externally called. In any case, this function's sole use is on the line
    println!("{}", multiply(10, 20));

And "sadly" (for us here), this doesn't explicitly say "I am expecting an int/i32 as output of multiply", it only says "I am expecting something that implements the Display trait". I think that in such cases it defaults to assuming the unit type () because it is the "simplest"/"most conservative" guess the compiler can make in such cases.

[–] maegul@lemmy.ml 2 points 1 year ago (1 children)
[–] Jayjader@jlai.lu 2 points 1 year ago (1 children)

I found a more precise answer re: type inference: https://stackoverflow.com/questions/24977365/differences-in-type-inference-for-closures-and-functions-in-rust

As I understand it, if a function is public you will need to explicit the return type. If it's private/local/not visible from outside the module wherein it is defined, then inference can kick in.

But generally, you'll want to specify the return type to make the compiler that much more aware of your intent.

[–] maegul@lemmy.ml 1 points 1 year ago

That makes a lot of sense. Intuitively I figured it would be something like that.

Still, as a compilation error, it’s confusing to see an error on the unit type being inconsistent when the issue is really an untyped return. Though now I know what the unit type is it’s a bit clearer what such a compiler error is about.