How do I know that I know enough?

This might sound like a dumb question but what is a good benchmark to know that I "know" Rust? So far I have read the Rust Book, done some mini projects, tried to use the provided tools such as cargo fmt and clippy to improve my code and generally attempted to make it more idiomatic. But I still don't feel confident that I know much especially without googling around to find the answer. What is a good benchmark to know that I am at least an intermediate level Rust developer?

1 Like

I would worry less about knowing everything upfront before starting a project, and just dive in. When you get stuck (which you will), use your ability to Google to find the knowledge you need to continue.

Programming is a craft - books will only teach you the basics and it's experience that hones your knowledge into mastery (and confidence).

I'm still learning new patterns or libraries, even after programming for over a decade and writing Rust for 7+ years. You can never "know enough" in tech because it's constantly evolving and reinventing itself.


Thanks for the reply. Just a nitpick. I don't wait to know everything up-front, I am okay with diving in without knowing all the details and learn as I go. But in general I want to have a benchmark or end-goal to set for myself. This could be anything that proves that I have a given level of competency.

For me, this generally takes the form of a working project that's useful in its own right (vs. just as an exercise). Picking such a project to embark on is, of course, an exercise for the reader.


Benchmarking anyone's abilities in something as complex as tech is just so faulty. What does "intermediate" even mean? It is a subjective measurement. I assume you ask this question partly because you are planning to apply to a job that has "intermediate" Rust knowledge in the description? In which case it obviously makes sense to present the recruiter with something tangible. Unfortunately I have no idea how best to approach this. I'm not a recruiter. Having some open source repos with stuff written in Rust is a good place to start I guess. Something that is authentically yours and solves a real problem is preferable I assume, but maybe well written implementations of something like AoC could be good enough to demonstrate "intermediate" Rust knowledge.


How about... read all the questions that come here everyday. When you can answer 80 or 90 percent, or whatever your criteria, you are done.

Of course you will not be done, quite, there will be some research required for that last 10 or 20%

Heck I rarely understand the questions let alone the discussions that follow. All that functional speak and type theory speak is a whole new language to me, before we even get to the actual Rust language.


Thanks! I will check out AoC. I have some public repos but I have no idea how they rank in terms of usefullness or quality of code. The question is not about getting a job but rather having something measurable to aim for.

1 Like

I would use this benchmark for knowing enough: are you able to do the thing you want to do?


If that means: "A program that can do X", e.g. a Ray-tracer. Then there are 2 issues.

  1. The bottleneck for doing anything interesting is first understanding the subject (not so much the coding itself)
  2. I could get a away with doing it in a slow, non-idiomatic way, thus why I need some benchmark to strive for

Hmm... I'm not sure about that.

Consider programming in C. One could learn enough C to use íf and gotoand then be able to get the thing one wants done. But surely we would expect that while, and for should be used? Or perhaps our C programmer never bothered to learn about switch and used clunky ìf`changes everywhere, surely we would not like to see that?

Consider the programmer I have been advising this last week about their C++ program that uses the Qt GUI tool kit. He is a C programmer that is actively hostile to C++ and tries to minimise its use as much as possible. Describing C++ as "over complex mumbo jumbo". That. makes offering any advice on how to get things done in a simple neat way using C++/Qt libs very frustrating. The result is a horrible mess of C code complete with buffer overruns and the usual flaws.

After two years of using Rust I still feel like that C programmer. Most of my Rust code looks like C (or perhaps JS sometimes). It works well but I'm sure if I studied Rust more I would arrive at better looking and likely more performant solutions. Sadly time is always against me.

1 Like

It depends on the exact choice of X, but to me neither has been true:

  1. The sheer amount of coding problems on this forum and rest of the internet makes it clear that there are plenty of subjects where coding is the bottleneck.
    If there is something you want to do, you're going to need the domain knowledge either way. If you're exercising to learn programming in general, puzzles are fine. But if you're exercising to learn Rust in particular, don't go for the puzzles. Try to write as little algorithmic code as possible.
    Instead, leave these parts to external crates, and write the glue code. That way, the workload is more realistic, and you're more likely to learn the Rust-specific knowledge.
  2. If your program runs too slow, obviously that doesn't count as successfully having written a program. You'll have to optimize it until it runs at a reasonable speed.
    If you're doing something in a non-idiomatic way, you will know it mostly because the compiler or clippy will tell you, and also because you'll be working against the toolchain and libraries, which is a lot of pain. So no, you could not get away with doing something in a slow, non-idiomatic way.

It is normal for experienced developers to constantly look up things. With a complex language like Rust, no one is expected to understand the entirety of the language. Pages like Learn Rust or can make it really quick to find comprehensive resources you need. The more you can quickly find, the less you need to know. Really, if you're not sure whether you know enough, you know enough. There aren't that many things that must be memorized.


I would define it more like "A program that can do X efficiently, passes clippy and is easy to read and maintain". But that really depends on what your goals are. Or those of one who pays you. Or the people you work with.

I see that "thing you want to do" is unhelpfully vague.

To me, "horrible mess with buffer overruns" is not something I would want to do. But evidently, some people are fine with it!

If you had more time, how would you study?

Right, I feel like being able to accomplish some goal is "the benchmark" by which one can test their knowledge. But learning is a very fluid and fractal-like exercise. The more you understand about any subject, the more you will realize there are other, deeper things to learn about it.

Building a ray tracer is something that can be done in a week or so (YMMV) following sources like the Ray Tracing in One Weekend Series or Home · ssloy/tinyraytracer Wiki ( That doesn't mean your solution will be optimal, but writing a working ray tracer is in fact an accomplishment of the stated goal, despite all else. If you then want to improve upon it or better familiarize yourself with the topic of ray tracing in general, I say that's just another (different) goal to strive for.

In other words, goals beget goals. Or as I've heard sports aficionados say, "move the goal posts". There's a good reason that roadmaps are delineated in milestones! We're talking about a journey, not a destination.

The anecdote about the hardcore C programmer that avoids C++ with hostility is quite different. It sounds more like that person's goal was "learn C" and that's where they stopped. Being receptive to change is part of the learning process. Perhaps it is the acceptance of this fact when you know that you know enough?

I'm +30yrs a software developer and +5yrs programming Rust professionally, and I'm this forum asking dumb basic questions all the time. (Thanks for the help, everyone!)

There's no finish line. Being a developer, like being an engineer, artist, musician, etc, is a continuous learning process. Just when you think you've "got it" someone will show you something new and surprising.

With Rust, I often go back and review the basics, particularly the things that were new and surprising when I first came to Rust: the borrow checker, lifetimes, macros, async/await, etc. Each time through I feel like I pick up something new.

Just keep learning. Never stop that.

1 Like

This fells like a philosophical question. There are things that you know, things that you know of but don't know the answer to, and then there are the things you don't even know that you don't know of, and there is no way (really) to know how many of them there are.

So my tip would be to go around looking for "advanced Rust tips" articles or videos. If you go in knowing most of the topics before hand, that can be a good indicator that you know a good portion of the things that there are to know. Or that you need to look better.

I personally recommend the "Crust of Rust" videos on Jon Gjengset's Youtube channel, they go into enought depth to be interesting without being needlessly too technical.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.