Nyårs bug-hunt meetup

[eirikblekesaune]

Forslag om å holde en litt mer intro-aktig workshop for å sparke i gang nyåret. Som @cbrevik nevnte så er det sikkert flere som brenner inne med nyttårsforsetter om å lære seg nye ting.

Her tar vi for oss de de mer "særegne" aspektene ved Rust. Vi lager en samling Rust programmer med klassiske Rust-kompilasjonsfeil, som vi løser i felleskap.

Noen forslag til tematitler😎 (m. fare for ordspill og rim av generelt 'varierende' kvalitet...):

• Kamper med borrow checkeren
  • "Eierskap og ansvar er gull": Moving values, drop
  • "Lånekvota er full, så ikke prøv deg på no tull": Mutable borrows
  • "Bare se men ikke røre": Immutable borrows
• "Livet with lifetimes"
  • String slice iterator?
• "Alt med egen trait oppfører seg greit"
• "Mitt skip er lastet med": Fn closures
• "Hatten går": FnMut closures
• "Iterere, Modifisere, Kaptivere"
  • iter vs. iter_mut vs. iter_into
• "Til og fra er like langt": Type konvertering med From og Into traits

[eirikblekesaune]

Forslag til dato for workshop: 15. Februar Tror dere det kan funke @cbrevik og @AndersNS ?

[cbrevik]

Haha, denne er fantastisk! Jeg skal sjekke kalenderen, men ser ut som Varianthuset er ledig 15. februar ja. Kommer tilbake sporenstreks på den.

[cbrevik]

Ser ut som det er opptatt til kl 17 den 15. februar. Så evt. kan vi pushe det til kl 17, eller ta det en annen dag hvis vi ønsker tidligere klokkeslett.

Ville du ta denne selv @eirikblekesaune eller interessert i å dele den opp så blir det ikke mye å bite over? Er du interessert i å være med @AndersNS? Tenkte så vi kan bytte på å presentere/fasilitere?

[eirikblekesaune]

For meg funker det jo fint å ta det fra 17:00 egentlig. Hva med dere?

Vi kunne jo feks laget et par-tre slike ødelagte programmer hver? De titlene ovenfor var bare forslag altså, så jeg har ikke noen klar tanke med det hele egentlig.

[eirikblekesaune]

Lagde et repo hvor vi kan legge inn ødelagte programmer, så ser vi bare hvor vi ender opp. https://github.com/rust-trondheim/programmer-med-feil

Hva tenker dere om strukturen i repoet?

En mulig løsning er å legge inn programmene i separate mapper, også lage et workspace av hovedmappa. Så kan for eksempel hver mappe ha en README.md, hvor man kan gjemme løsningsforlag med details/summary https://gist.github.com/scmx/eca72d44afee0113ceb0349dd54a84a2

Dette er feil:

let x = "fd;

:see_no_evil: Slik fikser du det:

let x = "fd";

Btw, jeg fikk ikke syntax coloring til å funke med <pre>-tags, men de nødvendige inne i <details>(?) Vet dere om et triks?

[cbrevik]

For meg funker det jo fint å ta det fra 17:00 egentlig. Hva med dere?

For min del er det vanligvis greit at det er tidlig på grunn av legging av unger, men jeg kan evt. runde av litt tidligere selv! Fikk melding nå om at det er kanskje tilgjengelig før kl 17 også den dagen så kan være det ordner seg læll.

Liker tanken på at vi kan gjemme løsningsforslag som du sier. En annen måte hadde vært å ha en git branch for oppgave og en for løsning. Men fort mareritt å holde de oppdatert med hverandre ved endringer/tillegg 🙈

Klarte heller ikke å få til syntax highlighting inni details, alternativt så kunne vi lenke til en markdown-fil med løsning ved siden av README.md som vi lenker til? Ikke like smud kanskje. Men tenker kanskje med mindre løsningene er veldig omfattende så er det ikke krise om det ikke er highlighting?

Støtter separate mapper i hvert fall :+1: - åpner for å kunne lage noen kule problemstillinger fremfor at hele greia må "henge sammen".

Jeg jobber ikke med Rust daglig, så tar gjerne noen av de "enklere" problemstillingene 😂

[eirikblekesaune]

Ah, jeg ser at man faktisk kan bruke trippel backticks. Sist jeg prøvde det funka det ikke, men grunnen til det var at jeg hadde ikke tom linje over og under selve trippel-backticks delen. Hvis du sammenligner under:

Oppgave: Lag et program i Rust som skriver "Hello, World!" til terminalen.
<details><summary>🙈 Løsningsforslag</summary>
```rust
fn main() {
  println!("Hello, World!");
}

blir til:

Oppgave: Lag et program i Rust som skriver "Hello, World!" til terminalen.
<details><summary>🙈 Løsningsforslag</summary>
```rust
fn main() {
  println!("Hello, World!");
}

mens dette:

Oppgave: Lag et program i Rust som skriver "Hello, World!" til terminalen.
<details><summary>🙈 Løsningsforslag</summary>

```rust
fn main() {
  println!("Hello, World!");
}

Blir til dette:

Oppgave: Lag et program i Rust som skriver "Hello, World!" til terminalen.
<details><summary>🙈 Løsningsforslag</summary>

```rust
fn main() {
  println!("Hello, World!");
}

[eirikblekesaune]

Jeg jobber ikke med Rust daglig, så tar gjerne noen av de "enklere" problemstillingene :joy:

Ja, det samme gjelder meg også. Men jeg tenker at den beste måten å lære seg noe er å prøve å lære det bort, eller hvertfall sette i gang en kollektiv læringsprosess.

[eirikblekesaune]

For min del er det vanligvis greit at det er tidlig på grunn av legging av unger, men jeg kan evt. runde av litt tidligere selv! Fikk melding nå om at det er kanskje tilgjengelig før kl 17 også den dagen så kan være det ordner seg læll.

Supert at du lagde event på Meetup.com. Teksten ser helt super ut. Når vi får avklart endelig starttidspunkt så kan vi jo bare publisere det eller?

Jeg tenkte på varigheten på 2 timer. Er det evt. mulig å holde på litt lengre hvis det skulle være flere som fikk fot? Om vi hadde f.eks. satt det til 3 timer, så kan vi jo runde av når det passer?

[cbrevik]

Men jeg tenker at den beste måten å lære seg noe er å prøve å lære det bort

Helt enig!

Når vi får avklart endelig starttidspunkt så kan vi jo bare publisere det eller?

Jeg lagde en draft så dere kan gi tilbakemelding, tror 16:30 kan være greit. Noen andre bruker rommet til kl 16, så da får vi tid til å sette opp bord osv, ordne med mat. Tenker jeg publiserer under lunsjen nå.

Om vi hadde f.eks. satt det til 3 timer, så kan vi jo runde av når det passer?

Ja kan godt utvide. 🎯 Var litt tilfeldig at jeg satte to timer egentlig.

[eirikblekesaune]

Sjekket ChatGPT om hvilke temaer som oftest er utfordrende for for nye Rust programmerere. Her er svaret:

---

There are several common programming errors that Rust programmers may encounter, some of them are:

• Borrowing and Ownership: Rust's ownership and borrowing model can be difficult to understand and reason about, especially for those new to the language. Common errors include forgetting to release a borrowed reference, using a variable after it has been moved, or trying to use a borrowed reference after it has been dropped.
• Lifetime Errors: Rust's lifetime system can be tricky to work with, and it's easy to make mistakes that result in lifetime errors. For example, returning a reference to a local variable or passing a reference with an incorrect lifetime to a function.
• Concurrency and Parallelism: Rust has powerful features for concurrent and parallel programming, but it also requires careful consideration of shared state and synchronization. Common errors include data races, deadlocks, and use of unsafe features such as raw pointers.
• Unsafe Rust: While Rust is designed to be a safe programming language, it does allow for some unsafe code when necessary. Common errors in unsafe code include use-after-free, data races, and buffer overflows.
• Matching and Pattern: Rust's match and pattern matching mechanism is powerful but it can also be tricky to use. Common mistakes include forgetting to handle all possible cases, using the wrong pattern, or using patterns that don't match the type of the value.
• Trait and Type-related errors: Rust is an expressive language with a lot of types and traits. Common mistakes include implementing the wrong traits, using the wrong types, or not implementing required traits.
• Lifetime and Bounds: When working with generics, it can be tricky to understand and specify the correct lifetime and bounds for the type parameters. Common errors include using the wrong lifetime for a reference, not specifying bounds for a generic type, or specifying bounds that are too restrictive.
• String handling: Rust has several types of strings like String, &str and String literals, and it's important to choose the right one for the task at hand. Common errors include trying to pass a string slice to a function that expects a owned String, or trying to use a String where an &str is needed.
  • Iterator and Iterable: Rust's Iterator and Iterable traits are powerful, but it's easy to make mistakes when working with them. Common errors include using the wrong type of iterator, not consuming the iterator completely, or not handling the case when the iterator is empty.
• FFI (Foreign Function Interface): Rust's FFI system allows calling C or other languages functions, but it can be tricky to use. Common errors include passing arguments with the wrong type or size, or not properly handling the return value of a foreign function.
• Testing and Debugging: Rust has powerful testing and debugging tools, but they can be tricky to use. Common errors include not properly testing all possible code paths, or not properly handling edge cases in tests.

It's important to note that Rust is a new programming language and it has a steep learning curve. These common errors are not unique to Rust, but rather a reflection of the complexity of programming in general. With experience, and a good understanding of the language's features and best practices, many of these errors can be avoided.

---

Så har vi jo et utgangspunkt for å sette temaer. ;-)

[eirikblekesaune]

Fordeling av temaer

1 - Anders

Ownership Borrowing Lifetimes, bruke Drop trait til å vise lifetime, forskjell mellom GC språk og Rust

2 - Eirik

Iteratorer Closures Pattern/String matching

3 - Christian

C# bakgrunn, mapping av Exceptions Result, Error, håndtering Trait objects

[eirikblekesaune]

Her er noen forslag til organisering av cargo oppsett. Hvis vi samler de individuelle programmene våre i egne cargo packages, dvs. lage egne mapper som har egne Cargo.toml, og bruker rotmappa til å liste opp disse pakkene som members under en [workspace] header, får vi et virtuelt workspace. Dette kan gjøre at de indivuelle pakkene ikke er avhengige av hverandre i så stor grad.

Slik @cbrevik har lagt det opp er fint tror jeg. Det eneste som er nyttig å legge til er å definere binaries i underpakkenes Cargo.toml filer. F.eks. for pakken som ligger i mappen bug_07_result, så kan man legge inn to binaries slik:

[[bin]]
name = "divider"
path = "src/divider.rs"
[[bin]]
name = "file_reader"
path = "src/file_reader.rs"

Man kan da kjøre testene slik: cargo test -- bin divider Navnet på binaries er jo valgfritt. Kanskje det er lurt å prepende bug_07 slik at det blir bug_07_divider.

Hvis programmet har en main funksjon så kan man kjøre binary med: cargo run --bin divider

En annen fordel med dette er jo at vi kan ha så mange binaries i hver underpakke som vi trenger.

[cbrevik]

Satt og tenkte litt på dette nå, en mulighet kan være å navngi testene på en sånn måte at en kan kjøre de som en enkelt test suite.

F. eks. hvis jeg navngir de for divide-funksjonen som divider_valid_args_should_return_ok_result og divider_divide_by_zero_should_return_err (mao starter test-navnet med divider), så vil cargo test divider kun kjøre de testene som har divider i navnet.

Vil det løse problemet? Merker også at den vil ikke kjøre testene som ikke kompilerer, så vurderer egentlig bare kommentere ut tester som ikke bygger.

[eirikblekesaune]

Du kan kansksje legge til en #[ignore] over de som ikke skal kompileres, så fjerner du #[ignore] for hver test du aktiverer?

vis du trenger å kjøre kun én av testene så tror jeg syntaksen er cargo test --bin divider::valid_args_should_return_ok_result

[eirikblekesaune]

Det lukter vel litt av at vi skal få til en cargo relatert meetup etterhver..? Er mye å lære der som jeg absolutt ikke har oversikt over.

[cbrevik]

Så absolutt hadde vært verdifullt det ja

[cbrevik]

Prøvde ignore nå, men ser ut som de fortsatt blir forsøkt bygd, virker til at ignore bare påvirker om den kjøres eller ikke etter at den har blitt bygd

[eirikblekesaune]

Ah, du skal bruke en #[cfg(test)] sak før testene dine. Da kompileres ikke testene med resten av koden.