Rust Programming Expertise

Key Principles

• Prefer owned types at API boundaries and borrows within function bodies to keep lifetimes simple
• Use the type system to make invalid states unrepresentable; enums over boolean flags, newtypes over raw primitives
• Handle errors explicitly with Result; use

  thiserror

  for library errors and

  anyhow

  for application-level error propagation
• Write unsafe code only when the safe abstraction cannot express the operation, and document every safety invariant
• Design traits with minimal required methods and provide default implementations where possible

Techniques

• Apply lifetime elision rules: single input reference, the output borrows from it;

  &self

  methods, the output borrows from self
• Use

  tokio::spawn

  for concurrent tasks,

  tokio::select!

  for racing futures, and

  tokio::sync::mpsc

  for message passing between tasks
• Prefer

  impl Trait

  in argument position for static dispatch and

  dyn Trait

  in return position only when dynamic dispatch is required
• Structure error types with

  #[derive(thiserror::Error)]

  and

  #[error("...")]

  for automatic Display implementation
• Apply

  Pin<Box<dyn Future>>

  when storing futures in structs; understand that

  Pin

  guarantees the future will not be moved after polling begins
• Use

  macro_rules!

  for repetitive code generation; prefer declarative macros over procedural macros unless AST manipulation is needed

Common Patterns

• Builder Pattern: Create a

  FooBuilder

  with

  fn field(mut self, val: T) -> Self

  chainable setters and a

  fn build(self) -> Result<Foo>

  finalizer that validates invariants
• Newtype Wrapper: Wrap

  String

  as

  struct UserId(String)

  to prevent accidental mixing of semantically different string types at the type level
• RAII Guard: Implement

  Drop

  on a guard struct to ensure cleanup (lock release, file close, span exit) happens even on early return or panic
• Typestate Pattern: Encode state machine transitions in the type system so that calling methods in the wrong order is a compile-time error

Pitfalls to Avoid

• Do not clone to satisfy the borrow checker without first considering whether a reference or lifetime annotation would work; cloning hides the real ownership issue
• Do not use

  unwrap()

  in library code; propagate errors with

  ?

  and let the caller decide how to handle failure
• Do not hold a

  MutexGuard

  across an

  .await

  point; this can cause deadlocks since the guard is not

  Send

  across task suspension
• Do not add

  unsafe

  blocks without a

  // SAFETY:

  comment explaining why the invariants are upheld; undocumented unsafe is a maintenance hazard