DEV Community: Mykhailo

The 22 Rust errors every beginner hits, in the order they hit them

Mykhailo — Sun, 16 Aug 2026 20:50:35 +0000

Rust's compiler is the best teacher in the language and almost nobody reads it properly. Below are the 22 errors you will actually hit, roughly in the order you'll hit them, with what each one is really telling you.

Every diagnostic here is real. It was captured from a real rustc 1.96.0 (ac68faa20 2026-05-25) compiling a real broken program. The explanations were drafted with an LLM and edited by me.

Two things to know before the list.

Most Rust errors underline two places. One is where the rule was broken. The other is where the decision that broke it was made. The error is reported at the first; the fix is almost always at the second.

The help: block is often a literal diff. When you see +++ under a span, rustc isn't describing the fix. It's writing it.

1. E0061: The function takes two arguments and you passed one.

error[E0061]: this function takes 2 arguments but 1 argument was supplied
 --> src/main.rs:6:20
  |
6 |     println!("{}", add(1));
  |                    ^^^--- argument #2 of type `i32` is missing
  |
note: function defined here
 --> src/main.rs:1:4
  |
1 | fn add(a: i32, b: i32) -> i32 {
  |    ^^^         ------
help: provide the argument
  |
6 |     println!("{}", add(1, /* i32 */));
  |                         +++++++++++

The fix. Pass both: add(1, 2).

Rust has no default parameters and no overloading, so arity is exact. That sounds restrictive until you notice it means a function signature is a complete description of how to call it. There is never a hidden second way.

2. E0277: `Vec` has no single obvious way to print itself, so `{}` will not take it.

error[E0277]: `Vec<{integer}>` doesn't implement `std::fmt::Display`
 --> src/main.rs:3:20
  |
3 |     println!("{}", numbers);
  |               --   ^^^^^^^ `Vec<{integer}>` cannot be formatted with the default formatter
  |               |
  |               required by this formatting parameter
  |
  = help: the trait `std::fmt::Display` is not implemented for `Vec<{integer}>`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead

The fix. Use the debug formatter: println!("{:?}", numbers);

This is the first trait error most people meet, and the message names the exact missing capability: Vec<i32> doesn't implement std::fmt::Display. Read trait errors as a sentence (this type cannot do that thing) rather than as a wall.

3. E0282: Rust cannot work out what type this collection holds, because nothing was ever put in it.

error[E0282]: type annotations needed for `Vec<_>`
 --> src/main.rs:2:9
  |
2 |     let items = Vec::new();
  |         ^^^^^   ---------- type must be known at this point
  |
help: consider giving `items` an explicit type, where the type for type parameter `T` is specified
  |
2 |     let items: Vec<T> = Vec::new();
  |              ++++++++

The fix. Say it: let items: Vec<i32> = Vec::new();

Rust infers types from use, not from declaration. Push one integer and the annotation becomes unnecessary, because the inference works forward from evidence, and here you gave it none.

4. E0308: You promised an `i32` and returned nothing.

error[E0308]: mismatched types
 --> src/main.rs:1:14
  |
1 | fn five() -> i32 {
  |    ----      ^^^ expected `i32`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
2 |     5;
  |      - help: remove this semicolon to return this value

The fix. Delete the semicolon after 5.

() is Rust's word for "nothing". Whenever you see found (), look for a stray semicolon before you look at anything else. In Rust an expression without a semicolon is the value, and with one it becomes a statement that evaluates to nothing.

5. E0381: The variable was declared but never given a value, and you read it.

error[E0381]: used binding `count` isn't initialized
 --> src/main.rs:3:16
  |
2 |     let count: i32;
  |         ----- binding declared here but left uninitialized
3 |     println!("{count}");
  |                ^^^^^ `count` used here but it isn't initialized
  |
help: consider assigning a value
  |
2 |     let count: i32 = 42;
  |                    ++++

The fix. Give it a value: let count: i32 = 0;

Other languages hand you a zero or a null here. Rust refuses to guess, and that refusal is the point: there is no such thing as an uninitialised read in safe Rust, so a whole category of bug cannot reach runtime.

6. E0384: `let` bindings do not change unless you say `mut`.

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

The fix. Write let mut x = 5;

Two spans, not one: the ^^^^^ is where the rule broke, the - marks where the decision was made. The error is reported at the assignment, the thing you change is the declaration. That pattern holds across most Rust errors, and once you see it you cannot unsee it.

7. E0425: You used a name that was never declared in this scope.

error[E0425]: cannot find value `count` in this scope
 --> src/main.rs:2:20
  |
2 |     println!("{}", count);
  |                    ^^^^^ not found in this scope

The fix. Declare it first: let count = 0;

Ninety percent of the time this is a typo, and rustc will often guess the name you meant in a help: line. Read that before you go looking for a real bug, because the compiler has already done the search.

8. E0596: You called a method that needs to modify the value, on a binding that cannot be modified.

error[E0596]: cannot borrow `numbers` as mutable, as it is not declared as mutable
 --> src/main.rs:3:5
  |
3 |     numbers.push(4);
  |     ^^^^^^^ cannot borrow as mutable
  |
help: consider changing this to be mutable
  |
2 |     let mut numbers = vec![1, 2, 3];
  |         +++

The fix. let mut numbers = vec![1, 2, 3];

The interesting part is that push never says "mutable" in your code; you have to know its signature takes &mut self. The compiler is telling you a fact about a function you did not write, which is why the fix is on a different line from the error.

9. E0599: That type has no such method.

error[E0599]: no method named `push` found for type `{integer}` in the current scope
 --> src/main.rs:3:11
  |
3 |     count.push(1);
  |           ^^^^ method not found in `{integer}`

The fix. Use a type that has it, or the right method for this one.

When the type is right but the method is missing, rustc often lists candidates with similar names, and sometimes tells you a trait exists but is not in scope, which is a use statement away, not a redesign.

10. E0601: Every Rust program starts at a function called `main`, and there isn't one.

error[E0601]: `main` function not found in crate `snippet`
 --> src/main.rs:3:2
  |
3 | }
  |  ^ consider adding a `main` function to src/main.rs`

The fix. Rename the function to main.

The compiler is not looking for your code, it is looking for one specific name. Rust has no "top level" that runs. The entry point is a convention with no flexibility, and this is usually the first time a beginner learns the program has a designated front door.

11. E0618: You put call parentheses after something that is not a function.

error[E0618]: expected function, found `{integer}`
 --> src/main.rs:3:18
  |
2 |     let total = 5;
  |         ----- `total` has type `{integer}`
3 |     let result = total();
  |                  ^^^^^--
  |                  |
  |                  call expression requires function

The fix. Drop the parentheses, or call the function you meant.

Usually a shadowed name: a variable and a function with the same identifier, and the variable won. The help: line will tell you what the thing actually is, which is faster than re-reading your own code.

12. E0765: A string was opened with a quote and never closed.

error[E0765]: unterminated double quote string
 --> src/main.rs:3:25
  |
3 |       println!("{greeting}");
  |  _________________________^
4 | | }
  | |_^

The fix. Close the quote: let greeting = "hello";

Notice the error points at where the string started, not where the compiler gave up. That is the general pattern for unclosed things: the reported line is the opening, because the compiler cannot know which of the following lines you meant to close it on.

13. E0004: A `match` has to cover every possible case and yours misses one.

error[E0004]: non-exhaustive patterns: `Direction::South` not covered
  --> src/main.rs:8:11
   |
 8 |     match d {
   |           ^ pattern `Direction::South` not covered
   |
note: `Direction` defined here
  --> src/main.rs:1:6
   |
 1 | enum Direction {
   |      ^^^^^^^^^
 2 |     North,
 3 |     South,
   |     ----- not covered
   = note: the matched value is of type `Direction`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
   |
 9 ~         Direction::North => println!("up"),
10 ~         Direction::South => todo!(),
   |

The fix. Add the missing arm, or a _ => {} catch-all.

This is the feature you will miss most in other languages. Add a variant to the enum a year later and every match that forgot to handle it fails to compile. The compiler maintains your switch statements for you.

14. E0005: That pattern can fail, and `let` has nowhere to go when it does.

error[E0005]: refutable pattern in local binding
 --> src/main.rs:3:9
  |
3 |     let Some(value) = maybe;
  |         ^^^^^^^^^^^ pattern `None` not covered
  |
  = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
  = note: for more information, visit https://doc.rust-lang.org/book/ch19-02-refutability.html
  = note: the matched value is of type `Option<i32>`
help: you might want to use `let...else` to handle the variant that isn't matched
  |
3 |     let Some(value) = maybe else { todo!() };
  |                             ++++++++++++++++

The fix. Use if let Some(value) = maybe { … } or let Some(value) = maybe else { … };

let must always succeed, so it only accepts patterns that cannot fail. This is where if let and let … else come from: they are the versions with somewhere to put the failure.

15. E0063: You built a struct without all of its fields.

error[E0063]: missing field `y` in initializer of `Point`
 --> src/main.rs:7:13
  |
7 |     let p = Point { x: 1 };
  |             ^^^^^ missing `y`

The fix. Supply y too.

There is no partially-built struct in Rust. Every field is set at construction or the value does not exist, which is why you never have to check whether a field was initialised.

16. E0070: The left side of `=` has to be something that can be assigned to.

error[E0070]: invalid left-hand side of assignment
 --> src/main.rs:2:7
  |
2 |     5 = 6;
  |     - ^
  |     |
  |     cannot assign to this expression

The fix. Assign to a variable, or use == if you meant to compare.

Almost always a == typed as =. In C this class of typo silently compiles inside an if; Rust rejects it because a condition must be a bool and an assignment is not one.

17. E0382: The value moved to a new owner, and you used the old name afterwards.

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:16
  |
2 |     let name = String::from("crab");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{name}");
  |                ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

The fix. Clone it, or borrow with &name, or use other.

Read the note: rather than the error: move occurs because String does not implement the Copy trait. That single line is the whole ownership model. An i32 in the same code would have been fine, because copying eight bytes is free and copying a heap allocation is not.

18. E0423: You used a struct's name where a value was expected.

error[E0423]: expected value, found struct `Config`
 --> src/main.rs:6:13
  |
1 | / struct Config {
2 | |     debug: bool,
3 | | }
  | |_- `Config` defined here
...
6 |       let c = Config;
  |               ^^^^^^ help: use struct literal syntax instead: `Config { debug: val }`

The fix. Construct it: Config { debug: true }.

A struct name is a type, not a value, unless it is a unit struct, in which case the name is the value. That inconsistency is real and worth knowing, and the error message tells you which case you are in.

19. E0428: Two things with the same name in the same scope.

error[E0428]: the name `total` is defined multiple times
 --> src/main.rs:5:1
  |
1 | fn total() -> i32 {
  | ----------------- previous definition of the value `total` here
...
5 | fn total() -> i32 {
  | ^^^^^^^^^^^^^^^^^ `total` redefined here
  |
  = note: `total` must be defined only once in the value namespace of this module

The fix. Rename one of them.

No overloading in Rust: one name, one item, per scope. This is the language deciding that "which one did I call?" should never be a question you have to answer.

20. E0432: The path in your `use` statement does not exist.

error[E0432]: unresolved import `std::collections::HashMapp`
 --> src/main.rs:1:5
  |
1 | use std::collections::HashMapp;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `HashMapp` in `collections`
  |
help: a similar name exists in the module
  |
1 - use std::collections::HashMapp;
1 + use std::collections::HashMap;
  |

The fix. Fix the spelling: HashMap.

Import errors surface before type errors, so a single typo in a use line can produce a cascade of unrelated-looking failures below it. Always fix the topmost error first and recompile. Most of the rest often vanish.

21. E0433: The type exists in the standard library but has not been brought into scope.

error[E0433]: cannot find type `HashMap` in this scope
 --> src/main.rs:2:18
  |
2 |     let scores = HashMap::new();
  |                  ^^^^^^^ use of undeclared type `HashMap`
  |
help: consider importing this struct
  |
1 + use std::collections::HashMap;
  |

The fix. use std::collections::HashMap;

Rust's prelude is deliberately tiny: only the handful of items nearly every program needs. Everything else you import by hand, and rustc will usually print the exact use line, which you can paste.

22. E0609: That struct has no field by that name.

error[E0609]: no field `z` on type `Point`
 --> src/main.rs:8:22
  |
8 |     println!("{}", p.z);
  |                      ^ unknown field
  |
help: a field with a similar name exists
  |
8 -     println!("{}", p.z);
8 +     println!("{}", p.x);
  |

The fix. Use a field that exists, or add it to the struct.

rustc lists the fields that do exist, which makes this one of the errors you can fix without leaving the terminal. Worth noticing: the available-fields list is the compiler volunteering information you did not ask for.

The pattern behind all of them

Once you've read a few hundred of these, they stop being 22 separate errors and become four questions:

Who owns this value, and did I give it away? Ownership errors.
How long does this reference need to live? Lifetime errors.
Does this type do the thing I'm asking of it? Trait errors.
Did I say what I meant? Type, scope and mutability errors.

That's the language's whole difficulty curve, and the compiler tells you which of the four you're in every single time.

If you want to practise these against a real compiler without installing anything, that's what I built codecrab for: actual rustc output, the failing span underlined in your own source, one hint at a time. 94 exercises. Exercises derive from rustlings (MIT).

There'll be a paid tier later, chapters 6 and up, because compiling costs real money and I'd like this to still exist in 2028. Anyone with an account before that ships keeps the whole course.

https://codecrab.app/

Forward Deployed Engineer is outsourcing with a better logo

Mykhailo — Fri, 14 Aug 2026 00:26:41 +0000

I spent more than five years in outsourcing companies. That is where I started my career.

The job looked like this: get assigned to a client, learn their infrastructure, fight their legacy systems, sit in calls with people who could not describe what they wanted, ship something that worked, move to the next client. Sometimes I was on their VPN more than my own employer's. Sometimes I knew their systems better than their own staff did.

Now the same job has a new name and a salary that can be twice as high. It is called Forward Deployed Engineer.

Where the name came from

The term belongs to Palantir. The earliest published use I could find is a TechCrunch piece from June 2010 about a funding round, which identifies one of their employees by the title forward deployed engineer.

The name is borrowed from the military, where a forward deployed unit sits in the field instead of at home base. That is the whole idea. Palantir was selling data integration software to intelligence and defense customers who could not describe what they needed, partly because the requirements were classified and partly because nobody had written them down. Shipping the software did not work. So they shipped engineers, cleared and embedded on site, writing production code inside the customer's environment for months at a time.

Internally Palantir called them Deltas, a name they explain in their own post on Dev versus Delta. According to The Pragmatic Engineer, the company had more FDEs than regular software engineers until roughly 2016. That is a striking ratio for a company that sells a product. There is also a day in the life of an FDE from 2022 if you want their version of the job.

So the name is about fifteen years old, and the current wave of AI companies hiring FDEs did not invent anything. They picked up a label that already had a decade of history and a good story attached to it.

The job description is identical

Read what an FDE is supposed to do. Integrate a vendor's product with the client's messy data. Build custom pipelines and workflows on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. Feed real-world edge cases back to the product team.

Now read what I did in outsourcing. Integrate whatever the client bought with whatever the client already had. Build custom pipelines on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. File bugs and feature requests upstream when the vendor's product could not do the thing the client paid for.

I cannot find the daily difference. Same messy enterprise APIs. Same undocumented internal system that one person understands and that person is on vacation. Same client stakeholder who changes the requirement after the sprint started. Same travel, same context switching, same burnout curve.

What actually differs

Two business models, one job description.

An outsourcing agency sells hours. The unit of revenue is a person occupying a seat for a month. If a client cuts ten engineers, the agency loses ten engineers of revenue. Every engineer is a line item, and line items get negotiated down. That is why the rate is what it is, and it is why the agency's incentive is to keep bodies billable rather than to make any single engineer irreplaceable.

A product vendor sells licenses. The unit of revenue is an annual contract with a margin an agency will never see. The engineer they send into the client is not the product. The engineer is what makes the contract renew. One person who unblocks a stuck rollout can be the reason a seven-figure renewal happens instead of a churn. That is a very different number to justify a salary against.

If you want the numbers, levels.fyi has them. Palantir's forward deployed software engineer sits around $211K median. An EPAM engineer in the US is $165K. Accenture is closer to $109K. The frontier labs pay far more than any of them, but they pay everyone far more, so that gap is the company and not the title.

The lock-in argument does not hold up

The usual defense is that outsourcing and FDE work create different kinds of dependency. Outsourcing locks the client into people who understand the custom code. FDE work locks the client into the vendor's platform.

Both are lock-in. I have watched both happen. I have written the pipeline that nobody else could maintain, and I have also been the one who inherited someone else's version of it three years later and needed two weeks just to draw the diagram.

The distinction people draw is real but small. It describes who captures the value, not what the engineer does with their day. An engineer wiring a client's legacy database into a vendor's domain model is doing the same work whether the invoice says time and materials or annual license.

What I would actually tell someone trying to make the jump

If you are in outsourcing and you want the FDE title and the FDE compensation, the honest advice is to stop optimizing your engineering and start optimizing three other things.

Learn one product deeply instead of ten stacks shallowly. Outsourcing rewards breadth. You get thrown at whatever the next contract needs, and after five years you have touched a dozen stacks and mastered none of them. Product companies hire for the opposite. They want someone who knows their platform's data model well enough to argue with the core team about it. Pick a platform, go deep, get certified if the vendor offers it, build something real on it in public.

Get comfortable being wrong in front of executives. In outsourcing my escalation path was almost always internal. There was an account manager and a delivery lead between me and anyone who owned a budget. FDE work removes those layers. You are in the room where the customer decides whether to keep paying, and you have to say "that integration will take three weeks and here is why" to someone who wanted to hear one week.

Go find out what they are actually hiring for. Change your LinkedIn title to Forward Deployed Engineer and start reading the job posts. Scrape them if you want, there is nothing hidden here. A few dozen descriptions will tell you what the requirements really are, and once you line them up against your own CV the gaps are obvious. Then build a plan to close them.

What you will notice is that almost every one of these roles is at a product company. So you need a product mindset. Not just "solve the client's problem", but understand why the company put you at this particular client, what that account means to them, and what happens if it goes badly.

None of this is about writing better code. If you are already the person the client asks for by name, you have the engineering part.

The part I am not sure about

I do not know how durable the FDE label is. Roles that exist to make a specific product land tend to get squeezed when the product gets easier to deploy, or when the vendor decides the work belongs to a partner network. That is more or less what happened to a lot of specialist consulting niches over the last decade.

I also do not know whether the pay gap survives the title becoming common. Right now it is scarce enough that the compensation reflects the revenue it protects. In five years there may be a lot of people with FDE on their profile, and the salary may look a lot more like a senior engineer's, and the same people who chased the title will be looking for the next one.

I did this job for five years before it had the good name. Nobody called it strategic then, and I still cannot tell whether they were wrong about the work or just early on the pricing.

Originally published on yetmike.com.

Podman Lost to Docker. I Stopped Fighting It.

Mykhailo — Mon, 27 Apr 2026 20:18:32 +0000

Most "Podman vs Docker" articles treat it as a technical comparison. It isn't. It's a migration cost problem.

The technical case for Podman is real: rootless by default (not opt-in like Docker's 20.10 mode), no dockerd running as root, no $9–15/user/month for Docker Desktop, and Quadlet (5.0, 2025) for native systemd integration. These are genuine architectural wins.

But Stack Overflow's 2025 survey shows Docker at 71.1% adoption — the largest single-year jump of any technology. Podman at 11.1%. Docker Hub: 318 billion pulls. Podman Desktop: 3 million total downloads since launch.

That's not a competitor. That's a niche.

The question that actually matters

Not "which is better?" but "what context are you in?"

Starting fresh — use Podman if it fits. On RHEL, it's the obvious choice: Red Hat ships it by default, Quadlet integrates directly with systemd, rootless-by-default matters when someone audits your runtime. The CNCF accepted it into sandbox in January 2025. Greenfield project, no legacy tooling — go for it.

Migrating an existing Docker setup — think twice. This is where the calculation breaks down. The spreadsheet shows Docker Desktop at $9–15/user/month. It doesn't show:

Migration day
Debugging socket path differences (Podman uses a different socket location than Docker)
Updating CI pipelines built around Docker socket compatibility
Fixing Dev Containers when VS Code stops finding the right runtime
The 30-minute Podman explanation for every new hire who's never heard of it

These are real hours from real people. None of them ship anything a user will ever see.

Why Docker won anyway

Not on merit. On surface area.

GitHub Actions assumes Docker. Rancher Desktop defaults to Docker. MCP server configs reference Docker. Every Stack Overflow answer assumes Docker. Every internal platform template your company has written assumes Docker.

When you switch, you're not just swapping a binary. You're swimming against the accumulated inertia of every tool your team uses daily. Podman's remaining real advantages — daemonless architecture, rootless-by-default, Quadlet — are genuinely better. They're also genuinely invisible to 90% of the people making the decision.

I wrote about the full trade-off breakdown, including where each argument actually landed and what Docker did and didn't fix, in the original post on yetmike.com.

The short version: run the numbers with migration costs included. Then decide.

Originally published on yetmike.com