this post was submitted on 27 Feb 2024
17 points (94.7% liked)

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


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 1 year ago
MODERATORS
 

Intro

So ... as we learn rust, exercises and puzzles are obviously valuable (at least in the early stages).

But IMO, jumping into just trying to write actually functional and useful programs can be very valuable.

I've been away for a bit and was wondering what I should do to start up rust learning again and figured that trying to power through some simple but not trivial program would be great. Then I figured people learning rust here might find the process worthwhile too.

The Idea of the Challenge

  • Pose a challenge in a post, outlining roughly what sort of program should be written, and at roughly what level it's pitched.
  • Propose a time period during which people can try to write the program, while having as much of a discussion as they like about it of course
  • When the time period is up, make another post inviting everyone to post where they got up to, posting code so we can discuss and provide feedback.

Any thoughts on this?

If you've got ideas for other challenges, feel free to post them. If there are a number of ideas it might be best to catalogue them and run them every week or month so as not to clog things.

The Challenge

A file diff program. Basically something like git diff or diff/colordiff.

git diff --no-index A B
  • Takes two files/paths as inputs, "A" and "B".
  • Determines the differences between them, or rather, what changes have been made to "B" relative to "A".
  • Changes are measured on a line by line bases (generally like git).
  • Provides some sort of output showing these changes.

Discussion

As I see it (not being an expert in this sort of program), there are three kinds of changes:

  • Addition
  • Deletion
  • Alteration

The difference between them depends, as far as I can understand right now, on whether lines surrounding the changed lines are duplicated in the reference file (file "A" lets say) and where they occur in the reference file relative to the changes.

I've got rough ideas about how this could work (which may be very wrong!) but I suspect working out the logic (if you haven't done it before) is a good part of the challenge as you then have to map that to rust.

We can talk about the logic in the comments here though, of course.

Also, an alteration here is really a deletion + addition, so not necessary, but it makes sense to me so I might try to implement it.

Otherwise, the output is open ended I'd say ... whatever makes sense to you. My first thought is JSON (which presents a chance to maybe try serde?). Something like:

[
  {
    "start_line_no": 0,
    "end_line_no": 1,
    "lines": ["this is a line of text", "and another"],
    "type": "unchanged"
  },

  {
    "start_line_no": 2,
    "end_line_no": 3,
    "lines": ["an added line",],
    "type": "addition"
  },

  ...
]

Probably a few complications there I haven't thought about, but you get the idea. You could even go further and supplement the program with a renderer that takes this JSON and produces HTML or something else.

Time

I'd say we can have a decent shot at this in a week. So how about I post again in a week asking how we all did.

top 2 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 1 year ago (1 children)

Some thoughts:

  • file diff-ing can be a great project, but it can also be a never-ending recursive nest of special cases and problems - especially if you want structured output beyond a list of byte offsets. It's important to not start out thinking "I can design a program that will always find all of the differences between 2 arbitrary files". A good list of assumptions to start with could include "files are always UTF-8 encoded", "files are never empty", "lines are always separated by \n" (or \n\r if you're on Windows?), "files are never larger than 250Mib [arbitrarily chosen small enough to fit in RAM on any modern-ish personal computing device]".

  • the timed constraint for the challenges might not be the best approach, long-term. Granted, given how young this community is right now, it could be better to "keep us focused on the same thing" for now. Story time: when I was in engineering school, the computer club operated a CTF leaderboard. The challenges were all designed to introduce you to different aspects of cybersecurity, and they all remained permanently available (akin to Codingame, LeetCode, and similar websites). Coming back to Rust for Lemmings, we could at least maintain a list of past challenges (as its own meta-post, for ex, to be easily linked in the sidebar). That way, at some point, anyone not feeling up to the "current" challenge can attempt a previous challenge instead, and know that sharing their results will still be explicitly welcomed.

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

All great points!

And yea, on the points about presumptions … yes! I wouldn’t focus on the diffing side of stuff at all, make whatever simplifying presumptions you need to and get writing would be my approach.

Moreover, “failure”, or not making a program that works is definitely an option! If you’re stuck somewhere, the idea at least, is that that’s helpful and informative, and if you want you can let us know where you got stuck and see if we can work it out.