🔎

    Organizational lesson

    2025-10-02 (last edit: 2025-10-02)

    Rust course

    We will be using Github Classroom for task submission and Discord for discussions.

    Our learning/teaching materials are going to be:

    • the content of this site - it contains explanations and questions tailored towards MIMUW students,
    • well-known Rust teaching materials ("The Book", "Rust by Example") that complement this site,
    • explanations/deeper insight during class and many examples of Rust code.

    Final grade

    • 1/2 of the grade is based on small tasks.
      • There will be 8 or 9 tasks.
      • Each task will be graded on a scale of 0 to 3.
      • You can get up to 21 points from the small tasks. It means that it is enough to do 7 tasks with a score of 3 points.
      • You can solve the task between the end of the lesson and strictly before the start of the next lesson. The deadline is different for different lab groups.
      • Note: we will have 14 classes in total, so you can expect a task every week or two.
    • 1/2 of the grade is based on a big project. You can choose a topic yourself, but it must be accepted by us. The project has to be split into two parts. It can be done in groups of two (or bigger, if ambitious enough). The grading is as follows:
      1. Usability - 4 points.
      2. Usage of Rust functionalities - 6 points.
      3. Programming challenges - 5 points.
      4. Size of project - 4 points.
      5. Quality of code - 2 points.

    In specific, individual cases, it is possible to raise the grade by doing additional work, but it has to be agreed by us beforehand and it should be not easier than going through the standard path. The additional work might be:

    • Making a presentation about some advanced topic (const generics, futures, macros, etc.) or about architecture of a selected Rust open-source library.
    • Contributing to a selected Rust open-source library.
    • Contributing to this course's materials.

    Big project deadlines

    The deadlines for the big project (not to be confused with separate deadlines for the small projects) are set to the start of your class. If you have a class on Wednesday at 12:15 and the project deadline is 2025-11-05 - 2025-11-06, then your deadline is 2025-11-05, 12:15.

    1. 2025-11-05 - 2025-11-06: Project ideas should be presented to us for further refining. If you wish to pair up with someone, tell us before the deadline.
    2. 2025-11-12 - 2025-11-13: Final project ideas should be accepted by now.
    3. 2025-12-10 - 2025-12-11: Deadline for submitting the first part of the project.
    4. 2026-01-07 - 2026-01-08: Deadline for submitting the second and final part of the project.

    Small tasks grading

    • By default, as long as the solution makes sense and passes all the tests, you get the maximum number of points, which then gets reduced based on the number of review comments we gave. There is no fixed convention, but usually tiny review comments give just a tiny penalty (multiples of 0.1 point).
    • The solutions shouldn't have any unnecessary files or code. As long as they satisfy the task requirements, they are fine.
    • As memory management is a big part of the Rust language, to learn how to do it optimally, the solutions should minimize the used memory (while still doing it safely). When possible, prefer to avoid allocations.
    • Algorithmic complexity and the constant behind the solutions matters too. For example, prefer using single operations on HashMap instead of multiple operations, and prefer to use data structures that minimize lookup time.
    • As the functional programming approach is also a big part of the Rust language, prefer to use it over imperative programming. Especially whenever you do operations on containers. Finding the cleanest (and usually safest) approach is left to you.
    • Error handling should be done consistently, as per lessons' guidelines. Be sure that you understand when to use unwrap, expect, ?, Result. Design the code to minimize the number of assumptions and unwraps.
    • During lessons we do not dive into the documentation to learn all available functions from the standard library. It is your job to explore the documentation and find functions that solve whatever specific issue you have. We might give review comments whenever there's some cleaner approach using the standard library.
    • We can also give review comments related to general code quality, not strictly related to the Rust language. In particular, please avoid copy-pasting, writing non-meaningful comments, overcomplicating the approach, using unoptimal data types. The approach and readability of the code also matters.
    • Lastly, of course the solutions should adhere to guidelines that are in the lessons (both in the provided text and spoken during classes).