Need help progressing beyond the basics of Rust

[bruh]

Hello fellow rust enthusiasts,

I started writing code in Rust almost a year ago, just as a hobby. Since I did not had the time and application to start more ambitious projects I stayed on a very basic level of understanding of the language and its nature. Last year I paricipated in a programming competition in Germany for pupils and apprentice, using Rust. That worked out quite well (although I don not know wether the code was really "good", it worked here is the code just in case you are interested). It really was fun and I felt how I got more comfortable thinking in Rust. But the individual tasks were rather small, so that I never had to think about strukture, threading and basically everythink you would consider in larger projects. Since then I have not wrote any code in Rust.

Fast forward to this year. In school we have to write an simulation programm and I decided that I want to do that in Rust, figuring this is a great oportunity the learn to better learn the language and stick to the project, since there is a deadline and a not unsigificant mark. To the simulation: Being an enthusiastic DiscGolf player I decided that I will build a discgolf tournament simulation. A bunch of players will be grouped together, throwing their discs and based their skill level, weather conditions and disk stats their attempts will be more or less successful. A couple months ago I discovered tui-rs, this will be my "UI". So much for planning.

Now that it is time for coding I realized that I absolutely do not know where to start. I am feeling like in art class sitting in front of a blank sheet of paper, to hesitating to make my first strokes fearing that I will make critical mistaked haunting me in the end. For example:

• How do I structure my project? I need a binary, but is it useful to use a lib inside too?
• All those Rust things like lifetimes and borring...I understand them, but not to that point that I could use them correctly in my own code.

I am feeling like the list can go on for much longer. I have to admit that this sounds like I did not understand Rust then, or programming at all and indeed, I started programming three years ago and I am "just" an apprentice. But worked through all the basic guides and made the beginnings of a breakout clone with the amethyst game engine.

So after that introduction my call for help. Do you have any advice going forward. What things I do not have to care about at the start? Are these people having some time to "coach" me? Or are there articles or such I did not discover yet.

Thank you for your time reading my complaints. I do really enjoy writing Rust and exited to tackle more advanced topics in this evironment.

Hope you all stay safe.

[2e71828]

Program structure, for me, is mostly an exercise in data modelling: What are the key concepts of my problem, and how do they relate to each other? To get past the blank page problem, I usually start projects in the Rust playground. Try to get a few datatypes set up that represent a small part of your problem space, and work outwards from there. Write liberal #[test] functions to make sure they behave the way you want them to. Once you have your data model worked out, the overall program structure is usually a natural extension of that.

There’s lots of pitfalls and wrong turns to make in this process; avoiding them comes from experience. You need to be willing to revisit your earlier decisions, but also to move forward with a solution that’s only “good enough;” it’s a hard needle to thread.

[Michael-F-Bryan]

As you've identified, there's often a big difference between being able to write code (programming) and being able to design a project which fulfills a purpose (software engineering).

One way to help you get going is to come up with an example or test which uses the code that you generate. Sure, you'll eventually have a UI, but beneath the UI is some code which represents a game and does stuff. For now it doesn't matter that none of the "code" you are calling doesn't exist, we just want to get an idea of the overall workflow.

Once you have a couple code snippets you can start stubbing them out with empty struct definitions and methods who's entire body consists of a todo!() call. Then one by one you try to remove the todo!()s until the code actually runs. Along the way you'll realise your original workflow wasn't quite correct and be forced to refactor it to something better... Multiply by a couple evenings and your game simulator should start to take shape.

TL;DR: Just fake it 'til you make it. Then ask someone for a code review and they can help you figure out where your design could be improved.

[bruh]

@Michael-F-Bryan
Thank you, that was really helpful and enlightened. Never thought about that, despite knowing the todo!() feature. Just to make sure I understood what your were trying to tell me. I will start tinkering with the UI and evetually call have to call some methods for getting the actual data from the simulation. Whenever I realize I need a method I fill them with a todo!() until I my programm starts to take shape. And so on...

[Phlopsi]

• Postpone multi-threading until the project is done — it's a non-trivial optimization and you have a deadline
• Use a version control system like Git, Mercurial, SVN, etc. — easily revertible experiments will save you time
• Don't waste your time fighting the borrow checker, if the outcome is uncertain; clone away your problems and use interior mutability (Cell, RefCell) and reference counting (Rc) where it helps — revisit your code when the project is done
• Use generics when you need them, not just 'cause — unnecessary complexity won't do you any good
• Got a compile error you don't understand, yet? Don't hesitate to ask — and use the search, first!

[Michael-F-Bryan]

Yeah, pretty much.

An alternative is to take the bottom-up approach, where you may know how you want to implement a smaller component, the you incrementally build bigger and bigger things on top of it until you have a complete app.

Often it'll be a combination of the bottom-up and top-down approaches.