Learning Rust and Lemmy

393 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

Rust for Lemmings Reading Club (portal)
Rust beginners challenges (portal)
Heroically Helpful Comments

Policies and Purposes

This is a place to learn and work together.
Questions and curiosity is welcome and encouraged.
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.
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.

Rules

Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
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.
Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
See the Lemmy Code of Conduct
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 1 year ago

MODERATORS

[email protected]

Rust Beginners Challenge - Check in - Write a file diff program [PROJECT] (lemmy.ml)

submitted 1 year ago by [email protected] to c/[email protected]

14 comments fedilink hide all child comments

Intro

Not long ago I posed a challenge for those of us learning rust: https://lemmy.ml/post/12478167.

Basically write an equivalent of git diff --no-index A B ... a file differ.

While it's never too late to attempt it, I figured it'd be a good time to check in to see what anyone thought of it, in part because some people may have forgotten about it and would still like to have a shot, and also because I had a shot and am happy with what I wrote.

Check In

I'll post where I got up to below (probably as a comment), but before that, does anyone have anything to share on where they got up to ... any general thoughts on the challenge and the general idea of these?

My experience

My personal experience was that I'd not kept up with my rust "studies" for a bit and used this as a good "warm up" or "restart" exercise and it worked really well. Obviously learning through doing is a good idea, and the Rust Book is a bit too light, IMO, on good exercises or similar activities. But I found this challenge just difficult enough to make me feel more comfortable with the language.

Future Challenges

Any ideas for future challenges??

My quick thoughts

A simple web app like a todo app using axtix_web and diesel and some templating crate.
Extend my diffing program to output JSON/HTML and then to diff by characters in a string
A markdown parser??

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 1 year ago (1 children)

I also found using an enum for the state variable along with associating data with each state a useful, flexible and elegant way to go. The program basically becomes just a single enum and the looping pattern above, along with a few data structures and some methods. Is this normal/idiomatic for rust??

In my experience, this is the sweet spot for Rust programming. If you can formulate your approach as a state machine like this, then you almost always should - especially when writing in Rust.

The only times I'd pass on the pattern is if stuffing all of the ambiant state of a problem into different states of a state machine just to make the giant loop work correctly introduces too much cognitive complexity (aka makes the code too hard to read / follow).

[–] [email protected] 1 points 1 year ago (1 children)

Thanks for the feedback! What you say tracks exactly with my feelings after writing this.

I personally did encounter enough issues with the borrow checker while writing this, largely because I'm not on top of ownership and language enough, that I'm still somewhat wary of moving off of clean data flow patterns like this state machine one.

Maybe I should try re-writing it using "dumb" globals and a procedural/imperative style and see how I go?

What would you be reaching for, in terms of patterns/approaches, when you know your data flow is too messy for a state machine?

[–] [email protected] 2 points 1 year ago (1 children)

What would you be reaching for, in terms of patterns/approaches, when you know your data flow is too messy for a state machine?

Bare if and loop expressions. Basically what you described as "dumb globals and a procedural/impérative style". Of course, defining some custom types is almost always useful if not needed for "properly" handling ownership.

[–] [email protected] 1 points 1 year ago

Cheers!