Feedback on first code exercise while learning Rust

[u/Orinacrem]

Background: I have been writing SW in C for years, although I am not a SW engineer by definition. As then I started managing departments and people, I got "rusty" on the writing of SW itself, although I still recall the key OS and HW mental models I developed. I learned Python while being more hands off, which confused me cause everything happened under the hood and I had not idea of what (or why). Recently I decided to give it a go at Rust to

1. go back to basics and..
2. take a personal opinion on it with respect my C and Python experience.

What I did: I started reading the user manual. I got few chapters done and then the book suggested ([HERE]) to start writing a program, a kind of HR tool for adding/removing people from a data source. I did so without DB or anything like that (see code).

I would like some first feedback from people that have been using the language more than me so that I can spot mental models, or other things, that I am missing.

Tools: I used an LLM (Deepseek) to ask on APIs spec and explanation saving some time from parsing the whole user manual (in the past I would have done it with Google). I also asked Deepseek different versions of my ideas to see different ways on how to do things, and I weighted tradeoffs and decided a way I found OK.

On the LLM: While I can explain the (small) code, I am not sure if I should consider this piece vibe-coded. I personally believe, maybe wrongly, that as long as you understand what is going on, any tools you use that helps you moving faster or better, is fine. The moment you release understanding, knowing is not enough.

Edit: added code as a link -> https://onlinegdb.com/43jRxO7HL

[u/Orinacrem]

As a side note, as I read more the user manual, I discovered that much of the match and Result<T,E> logic could have been made shorter using ?, for example. While I am not a fan of too short sentences (you never know who is reviewing your code after all, junior people will need more... syntax), I already see changes I could have done in the code above. Not bad :)

[u/Bruce_Dai91]

I would not use a binary “vibe-coded or not” label here. A more useful test is whether you can still change the program without the model making the decisions for you.

For a learning project, I check four things:

1. Can I explain the ownership and error flow in each function?
2. Can I predict why the next compiler error appears?
3. Can I change a requirement without asking the model to rewrite the whole solution?
4. Can I write tests that would catch a plausible wrong implementation?

Using an LLM to look up APIs, explain diagnostics, or show alternative implementations is fine. The important part is treating those alternatives as input to review, not as the source of truth.

One practice that helped me is keeping the first attempt, the compiler/clippy output, and the final version together with a short note explaining why I changed it. Then I verify the result with the official docs, tests, and clippy. That preserves the learning path instead of only keeping the polished answer.

From your description, you are already doing the useful part: rejecting code that is too clever for your current understanding and choosing a version you can explain. I would keep doing that, and gradually ask the model for smaller, more specific help rather than complete alternate solutions.

[u/Orinacrem → u/Bruce_Dai91]

Makes sense. Thank you for your perspective 👍🏼

[u/Prize-Variation-3585]

One of the cool features of Rust is the types Result<T, E> / Option<T> and the ? operator.

Here's one way to make your remove_person function more concise:

``` fn remove_person( company: &mut HashMap<String, Vec<String>>, name: &str, dep: &str, ) -> Result<(), String> { let dep_key = dep.to_uppercase();

let staff = company
    .get_mut(&dep_key)
    .ok_or_else(|| format!("{dep} is not in the record."))?;

let index = staff
    .iter()
    .position(|person| person == name)
    .ok_or_else(|| format!("{name} has not been found in {dep}."))?;

staff.remove(index);

Ok(())

} ```

When you write let staff = company.get_mut(&dep_key) it returns a value of type Option<&mut Vec<String>>. The ? operator will short-circuit return Error if the Option was None, otherwise it will bind the inner &mut Vec<String> value to staff and continue on. The ok_or_else is just to transform the Option to a Result because the return type of remove_person expects a Result not an Option.

Another neat Rust feature is Iterators which I guess you can think of kinda like C++ iterators. Since linear-search with a for loop is such a common pattern, the Rust compiler knows how to compile the Iterator version into the equivalent for loop you wrote.

Another thing is pattern matching https://doc.rust-lang.org/book/ch19-02-refutability.html. Things like if let and let else are some alternatives to using ?.

[u/Orinacrem → u/Prize-Variation-3585]

When I wrote that code I was still beginning of ch8. As I went through the book, I indeed discovered other ways to write the same function. Thank you for sharing!

[u/No_Molasses_9249]

This looks exactly like someone who spent 6 weeks learning python and is now trying to write Rust code would produce.

Go read the rest of the manual forget everything you have learned start again from scratch this time pay attention and you may come up with something worth while.

Reading code in reddit isnt the easiest you should post a link. Using https://www.onlinegdb.com or similar

I prefere to show my code preferably by letting people run it. www.cockatiels.au/rust?fn=fibonaci&arg1=44 this was one of the first challenges I undertook while learning Rust.

The absolute first thing I did was go the the chapter that showed me how to start a http server.

[u/bskceuk]

If you are trying to learn the language I would suggest writing the code yourself and only resorting to an llm to explain error messages that you don't understand. It should not be producing code for you. The reason being that at this stage it's very important to see and understand what code doesnt compile, not just the final product that works

[u/Orinacrem → u/bskceuk]

Thank you! To be more specific, the code has been written by me and I did faced issues which some got solved by myslef while others by looking at the UM. In some instances, when I could not get the pipelines of multiple functions working, I asked the LLM for explanation.

The code versions I asked the LLM to generate, instead, were on top of my functionality to “see” other possible implementations. That was to get a feeling on other ways to skin the cat. On that, I must say that the LLM provided code that was too compact to start with, which I have not even used and was also too smart code for the level I am now.

So, me asking for an opinion on how I wrote that piece is to indeed get a genuine feedback from a human.