Skip to content
tezvyn:

All bites

The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.

4247 bites

Page 133

Go & Rust2 min read

Rust Unit Tests: Co-locating Tests with Code

In Rust, unit tests live inside a special tests module within the same file as the code they're testing. This lets you test a module in isolation, including its private functions.

Go & Rust2 min read

Rust Doctests

Rust doctests are code examples written inside documentation comments that the compiler extracts, compiles and runs as real tests, so your documentation's example code is guaranteed to keep working instead of silently rotting out of date.

Go & Rust2 min read

Go Test Coverage: Rewriting Source to See What's Untested

Go's coverage tool rewrites your source code, adding counters to see what's executed during tests. It's a powerful way to find untested code, but remember: high coverage doesn't guarantee your tests are actually checking for correctness.

Go & Rust2 min read

Mocking in Go: Swap Real Code for Test Doubles

Mocking in Go uses interfaces to swap slow dependencies like time.Sleep with fast fakes in tests, keeping your test suite quick. Use it for network calls or database access. The footgun is testing implementation details instead of observable behavior.

Go & Rust2 min read

Go's pprof: Finding Your Code's Hotspots

pprof is a heat map for your code, revealing which functions consume the most CPU. It samples your program's call stacks to find performance hotspots. Use it to diagnose slow API endpoints or high-CPU background jobs. The footgun: profiling under no load.

Go & Rust2 min read

Go Memory Profiling with pprof

pprof takes a snapshot of your Go app's memory usage, showing which functions allocate the most. Use it to diagnose high memory consumption or find leaks. A common footgun is profiling total allocations (allocs) instead of current memory use (heap).

Go & Rust2 min read

Criterion: Statistical Benchmarking for Rust

Criterion isn't just a stopwatch; it's a statistical lab for your code. It provides stable performance metrics by running functions many times, letting you detect regressions and prove optimizations. The footgun is ignoring its statistical reports.

Go & Rust2 min read

Rust Mocking: Using Traits as Test Seams

Mocking in Rust uses traits as test doubles. You program a mock's behavior—what calls to expect and what to return—to isolate the code under test. The mockall crate's #[automock] macro generates mocks from traits. The footgun is over-specifying behavior.

Go & Rust2 min read

Go Fuzz Testing: Automated Bug Discovery

Go's fuzz testing automatically generates strange inputs to crash your code, finding bugs you'd never think to test. It's ideal for stress-testing parsers or security-sensitive functions.

Go & Rust2 min read

Fuzz Testing in Rust with cargo-fuzz

Fuzz testing automatically finds bugs by feeding your code pseudo-random inputs. Use cargo-fuzz to stress-test parsers and APIs that handle untrusted data. The main footgun is assuming random bytes are enough; effective fuzzing needs structure-aware inputs.

Go & Rust2 min read

Go Execution Tracer: Pinpointing Concurrency Bottlenecks

Go's Execution Tracer creates a visual timeline of your program, capturing goroutine state changes, syscalls, and GC events. It's essential for diagnosing subtle concurrency issues like lock contention. The main footgun is misusing annotations for work.

Go & Rust2 min read

Rust `cfg`: Compile Code for Specific Targets

Rust's cfg attribute acts like a compile-time switch, including or excluding code based on the target platform or features. It's used for cross-platform support (e.g., Windows vs. Unix) or enabling optional dependencies.

Go & Rust2 min read

Go Linker Flags: Injecting Data at Build Time

Go's -ldflags lets you inject data into your program at build time. This is perfect for embedding version numbers or git commit hashes into variables without hardcoding them. The main footgun is that the target variable must be a top-level string.

Go & Rust2 min read

Go Reflection: Inspecting Types at Runtime

Go's reflect package lets your program inspect and manipulate variables of unknown types at runtime. This is the engine behind JSON marshaling and generic frameworks. Misuse leads to slow code and runtime panics; always prefer interfaces when possible.

Go & Rust2 min read

Rust Declarative Macros (`macro_rules!`)

Think of macro_rules! as 'find and replace' for your code's structure. It matches patterns at compile time and expands them into boilerplate you don't want to write. It's used for helpers like vec![].

Go & Rust2 min read

Rust's `unsafe` Keyword: Five Superpowers, Zero Guarantees

Rust's unsafe keyword lets you bypass certain compile-time memory safety guarantees for low-level tasks like OS interaction or FFI. The footgun is thinking it disables all safety; it only enables five specific 'superpowers,' making you responsible for…

Go & Rust2 min read

Rust Raw Pointers: When References Aren't Enough

Raw pointers (*const T, *mut T) are Rust's C-style pointers, bypassing the borrow checker. They're used for FFI or building low-level abstractions. The footgun is assuming they're safe; they can be null or dangling, requiring unsafe to dereference.

Go & Rust2 min read

Go's `unsafe` Package: Breaking the Rules for Performance

Go's unsafe package lets you bypass type safety, treating memory like C with raw pointers for performance gains. It's used for low-level optimizations and C interoperability. The footgun: its behavior isn't guaranteed across Go versions, making code fragile.

Go & Rust2 min read

Cgo: The Bridge Between Go and C Code

Cgo is Go's bridge to the C world, letting you call C functions and use C types from your Go code. It's for leveraging existing C libraries or low-level OS APIs. The footgun: cgo calls have high overhead and break Go's simple cross-compilation.

Go & Rust2 min read

Rust Procedural Macros: Code That Writes Code

Procedural macros are compile-time functions that write Rust code for you. They power common patterns like Serde's #[derive(Serialize)]. The main footgun is hygiene: generated code can clash with local variables, so authors must use absolute paths to be…