Getting Your Hands Dirty

That’s all fine, but it might become boring pretty fast to learn from such synthetical examples. So, I decided to go wild and use Rust for some real projects.

Generally, it’s a brilliant idea for any Hacktoberfest participant to find issues to work on before the event.

In our location, that was a major problem, as lots of people came with no ideas on what to do, so they spent a lot of time crawling over GitHub looking for any viable issues. It’s much easier to spend an hour or two a couple of days before.

I didn’t have any ideas for open-source and neither do we use Rust for main projects in my job (at least, for now). So, what can a programmer do, when they want to write some code but they’re not sure which code?

Browse open source, of course. A couple of days before the event, I opened my browser to find some issues to work with. There are a whole lot of projects written in Rust on GitHub.

Quite a large part of them are popular and have some active issues. I used the Advanced search to find Rust repositories with more than 500 stars.

For myself, I found two projects to contribute to:

Hyperfine (A console benchmarking tool that I am using day-to-day.)

Monolith (A tool to download webpages and bundle them into a single .html file.)

And that is another good point here. Try to find a project you already use. For some main-stream languages (such as JavaScript or Python), it’s easier as they have much more tooling written with them, but it’s also possible for ones like Rust or Go.

After a quick review of the repositories, I found one issue for each of them to work on. Both well-defined, which is extremely useful for a new language and project.

Issues are self-contained, so I didn’t have to dig through the whole codebase of the project to get those tasks done. A good idea was to contact the repository’s maintainers.

It allows you to:

Ask if the issue is still relevant (as one of them was quite old). Claim that you’ll work on it, so we don’t end up in a weird situation where two or more people are doing the same job.

Authors of both projects responded fast, so I finished my preparations and was waiting for the event. I was not completely sure if I would be able to finish them in time, so I booked the next day to be able to finish contribution on time.

I will not go into details of the implementation as that’s quite project-specific. Here are just a few things I would like to mention about this experience, both regarding the Rust language and my approach in general:

Ownership

It blew my mind the first time I read about it. Then, I spent some time trying to understand it. Gave up. Tried again. Gave up. Decided to do something useful and eventually got the idea. After that — enjoy it.

Timing is important

It is important for every activity, but the format I participated in was an offline event. So it was twice as crucial as with the online-first approach.

So, plan, maybe even create some reading lists for top five problems you believe you might encounter.

Networking makes a difference

Working on issues was not that hard, so I had plenty of time to spend on networking.

And, even though there weren’t all that many participants, it was a great opportunity to borrow some experience from different ecosystems with which I rarely interact.

Outcome and Thoughts

I didn’t learn Rust in eight hours. However, it was an amazing start after which I:

Started to contribute to open-source software.

Found tons of interesting projects with Rust.

Began diving into the long-forgotten (for me) domain of the low to mid-level programming languages.

Gathered with cool people.

Such activities might not be necessary for your development as an engineer, but, I believe it will help with that.

So, I strongly encourage you to check the Events page of Hacktoberfest and if there’s an event coming near you — visit it to have an amazing time.