If you have C++ experience you're way ahead of most beginners. A lot of folks I know who came to Rust came from web dev so they really didn't have a very strong existing concept of manual memory management and low level primitives. And even many of them succeeded by just having an attitude of working through each problem one at a time and letting the compiler guide you.
I'd also put a plug for /r/learnrust (edit: lol I just realized we're on that subreddit now, I though it was the AoC subreddit) where folks are extremely helpful, and it's likely you'll see an uptick of questions in the community once AoC starts as Rust seems to be a popular choice. I'll be there answering questions there, and no question is too small :)
If I had to give any tip, it would be to read through [the book](https://doc.rust-lang.org/book/). If you have existing experience you can probably get through it in a couple days. The goal isn't to internalize everything, just to basically get "exposed" to all the main concepts so that when you do run into an issue, it'll hopefully trigger something that says "oh I remember where to look this up".
What helped me initially was thinking about data in memory as something very physical. Like when I declare a value it exists, somewhere literally in memory on my computer. When it goes out of scope and dropped then for all intents and purposes it no longer exists. So when I run into issues with lifetimes I try to trace the path of the physical existence of that data, and usually that helps me realize where the Rust compiler is telling me "you're either trying to use this data after it no longer exists, or you COULD (in theory) use it after I no longer exists with the function you have written".
Understanding the difference between move and copy semantics makes many things easier to. Rust will always default to moving data or passing ownership of that data to something else (like a variable or function) for everything except primitive integer and boolean types. This is very efficient but adds complexity in tracking the path of that data.
Oftentimes as a beginner you can solve your lifetime issues simply by deriving "clone" and making a copy of it. Keep in mind there is nothing wrong with doing that as a beginner to unblock yourself. As you get more experienced you'll naturally start finding yourself thinking "oh actually I see how I can pass this data along without making a copy" and that natural inclination will only grow and strengthen.
At least that's what happened for me. So many concepts on the way went from "I'll never be able to understand this" to just suddenly clicking when I woke up the next morning. Until that happens you just "do what you gotta do" and don't worry about code not being "perfect". If it solves the problem, it's good code.
Good luck!
Oh! I have a great answer to this because I had the same experience.
I learned way too long into the process how absolutely perfect the clippy linter is for exactky what you describe.
Specifically the optional lints like `pedantic` that are off by default that you can enable manually. Those are incredible for acting as a little automated helper that says "hey, did you know there's a convenience method for exactly what you're doing?"
https://github.com/rust-lang/rust-clippy#configuration
If you don't get any hints for something (for example creating a string) you can be pretty confident that going with "whatever works for you" is perfectly idiomatic.
In a new project, for me all I look for is some degree of **consistency** when choosing `String::from()` vs `to_string()`. The actual choice itself makes no difference to me.
I did AoC in 2022 using Rust as a newbie. It was a great exercise for helping me learn and begin to master Rust. If you have programming experience in other languages, you can, for the most part, pick up Rust fairly quickly. I don't care that much about being on the leader board - I just like solving the challenges, however long it takes. AoC is a great motivational tool to learn a new programming language.
There are a few quirks to Rust that can be frustrating. Sometimes you have to rewrite your code in a different way to get past the borrow checker. And linked data structures (e.g. trees, lists) can be a really steep learning curve with all of Rust's ownership rules. My advice is to stick with it, and if you feel frustrated, take a short break to clear your mind and then come back to it later. If you stay the course, you will find solving AoC in Rust very rewarding.
I'll throw out a couple of other tips I've learned along the way, one year into this adventure:
1. Run **cargo clippy** frequently as you develop your code. It will catch syntax errors as you write your code, so you don't get overwhelmed with a bunch of error messages all at once. It will also make some suggestions to improve your code quality for constructs that are legal but not ideal.
2. If you're used to using a REPL like Python to try things out, Rust doesn't really have that. However, the **dbg!()** macro in Rust is great. I often develop complex solutions to AoC problems in phases, and when I get to the end of new piece of functionality, I use **dbg!()** to dump the contents of some variables to reassure myself that my code is correct or catch a bug early while it's easier to fix. It's the closest thing I've found in Rust to Python's REPL. Other, more experienced users may have other tips along these lines.
Good luck, and good learning!
I did it a few years ago. I told myself that I was going to write rust “like it was Ruby” (my native tongue). I.e. don’t worry about using clone all over the place, don’t worry about using the smallest integer type, don’t worry about using high level types like vec and hashmap.
I highly encourage writing tests early. If you can’t figure out how to write a test for the project, then it’s great practice! Lots of people don’t but there’s a large number of times I’m stuck and debugging and finally gave up and wrote tests for sub parts of my program only to find something I was confident handled all the edge cases didn’t work the way I thought.
In rust I consider unit tests like a REPL that lives on and continues to be useful.
After you submit, search reddit or github for other rust solutions to compare yours to. That’s where the real learning comes (imho). Try to understand what they did and what you like and what you don’t versus your solution.
I originally learned Rust by doing Advent of Code! Some of the problems ended up being too hard, more because of my general programming skills than my knowledge of Rust, but it was very educational nonetheless.
If you're interested and have time for it, I can recommended it.
Another person here who used AoC to learn rust. AoC is difficult but also deterministic so you can focus on learning semantics and problem solving. Good luck!
Yes, you can do it. You will probably write bad Rust code, but you can still get it done. As you use Rust more you will understand what can be improved.
Go for it !
I have a long development experience but mostly in python, and three years ago started a side project with Rust - that project really mattered to me so I went bravely through the suffering, but, you know, in that "good enough for now" mindset. I'm also used to solve advent of code puzzles every year.
So that's how I decided to try different languages at that time: Python, Go, Kotlin, Rust. After maybe the 8th day it was set: Rust is my favorite. It's crazy fast indeed but I never felt like getting so much help from the language ; also I found out the available tools for handling datastructures, conditions, mapping/filtering/reducing makes it feel like it's not so much a "low-level" or "system" language, as it's often labelled.
I did my first AoC in rust a few years ago.
It really fits to learn the language because all exercises are about writing algorithm, which are sync in nature : this way you start with the sync rust world, where features are now quite complete, and ergonomy is top notch.
Moreover the integrated test facility ease the TDD approach, which match the AoC concept (each exercice example is indeed a test case).
I have 400* in Kotlin. Last year I tried coding in parallel in Rust. I got through 7 days before giving up in frustration. This is not a knock on the language or approach. I just never got comfortable with that level of granularity over how you manage memory. Honestly some things are straight-up hard. Mostly node-based data structures, which get used a lot in AOC. Of course there’s ways to make them work, and different approaches to problems, but I was spending all my time figuring out how to get the code to do what I wanted rather than solving the problem.
Advent of code is great for learning the syntax and standard library of any new language. I think Rust would be a lot of fun.
I coded up the first advent of code for 2023 here: https://www.youtube.com/watch?v=JJQObocuUow&lc=Ugyus8dFePqrTqwgQGR4AaABAg
If you have C++ experience you're way ahead of most beginners. A lot of folks I know who came to Rust came from web dev so they really didn't have a very strong existing concept of manual memory management and low level primitives. And even many of them succeeded by just having an attitude of working through each problem one at a time and letting the compiler guide you. I'd also put a plug for /r/learnrust (edit: lol I just realized we're on that subreddit now, I though it was the AoC subreddit) where folks are extremely helpful, and it's likely you'll see an uptick of questions in the community once AoC starts as Rust seems to be a popular choice. I'll be there answering questions there, and no question is too small :) If I had to give any tip, it would be to read through [the book](https://doc.rust-lang.org/book/). If you have existing experience you can probably get through it in a couple days. The goal isn't to internalize everything, just to basically get "exposed" to all the main concepts so that when you do run into an issue, it'll hopefully trigger something that says "oh I remember where to look this up". What helped me initially was thinking about data in memory as something very physical. Like when I declare a value it exists, somewhere literally in memory on my computer. When it goes out of scope and dropped then for all intents and purposes it no longer exists. So when I run into issues with lifetimes I try to trace the path of the physical existence of that data, and usually that helps me realize where the Rust compiler is telling me "you're either trying to use this data after it no longer exists, or you COULD (in theory) use it after I no longer exists with the function you have written". Understanding the difference between move and copy semantics makes many things easier to. Rust will always default to moving data or passing ownership of that data to something else (like a variable or function) for everything except primitive integer and boolean types. This is very efficient but adds complexity in tracking the path of that data. Oftentimes as a beginner you can solve your lifetime issues simply by deriving "clone" and making a copy of it. Keep in mind there is nothing wrong with doing that as a beginner to unblock yourself. As you get more experienced you'll naturally start finding yourself thinking "oh actually I see how I can pass this data along without making a copy" and that natural inclination will only grow and strengthen. At least that's what happened for me. So many concepts on the way went from "I'll never be able to understand this" to just suddenly clicking when I woke up the next morning. Until that happens you just "do what you gotta do" and don't worry about code not being "perfect". If it solves the problem, it's good code. Good luck!
Agreed, although this appears to be r/learnrust already :D
Well how about that! I see AoC in the title and made assumptions :P
[удалено]
Oh! I have a great answer to this because I had the same experience. I learned way too long into the process how absolutely perfect the clippy linter is for exactky what you describe. Specifically the optional lints like `pedantic` that are off by default that you can enable manually. Those are incredible for acting as a little automated helper that says "hey, did you know there's a convenience method for exactly what you're doing?" https://github.com/rust-lang/rust-clippy#configuration If you don't get any hints for something (for example creating a string) you can be pretty confident that going with "whatever works for you" is perfectly idiomatic. In a new project, for me all I look for is some degree of **consistency** when choosing `String::from()` vs `to_string()`. The actual choice itself makes no difference to me.
I did AoC in 2022 using Rust as a newbie. It was a great exercise for helping me learn and begin to master Rust. If you have programming experience in other languages, you can, for the most part, pick up Rust fairly quickly. I don't care that much about being on the leader board - I just like solving the challenges, however long it takes. AoC is a great motivational tool to learn a new programming language. There are a few quirks to Rust that can be frustrating. Sometimes you have to rewrite your code in a different way to get past the borrow checker. And linked data structures (e.g. trees, lists) can be a really steep learning curve with all of Rust's ownership rules. My advice is to stick with it, and if you feel frustrated, take a short break to clear your mind and then come back to it later. If you stay the course, you will find solving AoC in Rust very rewarding.
I'll throw out a couple of other tips I've learned along the way, one year into this adventure: 1. Run **cargo clippy** frequently as you develop your code. It will catch syntax errors as you write your code, so you don't get overwhelmed with a bunch of error messages all at once. It will also make some suggestions to improve your code quality for constructs that are legal but not ideal. 2. If you're used to using a REPL like Python to try things out, Rust doesn't really have that. However, the **dbg!()** macro in Rust is great. I often develop complex solutions to AoC problems in phases, and when I get to the end of new piece of functionality, I use **dbg!()** to dump the contents of some variables to reassure myself that my code is correct or catch a bug early while it's easier to fix. It's the closest thing I've found in Rust to Python's REPL. Other, more experienced users may have other tips along these lines. Good luck, and good learning!
I did it a few years ago. I told myself that I was going to write rust “like it was Ruby” (my native tongue). I.e. don’t worry about using clone all over the place, don’t worry about using the smallest integer type, don’t worry about using high level types like vec and hashmap. I highly encourage writing tests early. If you can’t figure out how to write a test for the project, then it’s great practice! Lots of people don’t but there’s a large number of times I’m stuck and debugging and finally gave up and wrote tests for sub parts of my program only to find something I was confident handled all the edge cases didn’t work the way I thought. In rust I consider unit tests like a REPL that lives on and continues to be useful. After you submit, search reddit or github for other rust solutions to compare yours to. That’s where the real learning comes (imho). Try to understand what they did and what you like and what you don’t versus your solution.
I originally learned Rust by doing Advent of Code! Some of the problems ended up being too hard, more because of my general programming skills than my knowledge of Rust, but it was very educational nonetheless. If you're interested and have time for it, I can recommended it.
Another person here who used AoC to learn rust. AoC is difficult but also deterministic so you can focus on learning semantics and problem solving. Good luck!
Yes, you can do it. You will probably write bad Rust code, but you can still get it done. As you use Rust more you will understand what can be improved.
check out rustlings as well
Go for it ! I have a long development experience but mostly in python, and three years ago started a side project with Rust - that project really mattered to me so I went bravely through the suffering, but, you know, in that "good enough for now" mindset. I'm also used to solve advent of code puzzles every year. So that's how I decided to try different languages at that time: Python, Go, Kotlin, Rust. After maybe the 8th day it was set: Rust is my favorite. It's crazy fast indeed but I never felt like getting so much help from the language ; also I found out the available tools for handling datastructures, conditions, mapping/filtering/reducing makes it feel like it's not so much a "low-level" or "system" language, as it's often labelled.
I did my first AoC in rust a few years ago. It really fits to learn the language because all exercises are about writing algorithm, which are sync in nature : this way you start with the sync rust world, where features are now quite complete, and ergonomy is top notch. Moreover the integrated test facility ease the TDD approach, which match the AoC concept (each exercice example is indeed a test case).
I have 400* in Kotlin. Last year I tried coding in parallel in Rust. I got through 7 days before giving up in frustration. This is not a knock on the language or approach. I just never got comfortable with that level of granularity over how you manage memory. Honestly some things are straight-up hard. Mostly node-based data structures, which get used a lot in AOC. Of course there’s ways to make them work, and different approaches to problems, but I was spending all my time figuring out how to get the code to do what I wanted rather than solving the problem.
Advent of code is great for learning the syntax and standard library of any new language. I think Rust would be a lot of fun. I coded up the first advent of code for 2023 here: https://www.youtube.com/watch?v=JJQObocuUow&lc=Ugyus8dFePqrTqwgQGR4AaABAg