You Can Do More with Less

I am an ardent supporter of test-driven development. Having previously worked with languages like Java and JavaScript, I initially approached testing in Rust similarly. However, I quickly found myself crafting tests that were almost guaranteed to succeed. Once your Rust code compiles, the language's error handling means many common test scenarios become unnecessary. By steering clear of unsafe {} blocks and panic-inducing methods like .unwrap(), you build a strong foundation that naturally avoids many pitfalls.

Rust's stringent borrow checker, sophisticated type system, and functional programming features allow for easier maintenance with reduced testing requirements. For instance, I've managed over 70,000 lines of code in the Wick project with far fewer tests than I'd typically need in other programming languages.

When writing tests becomes necessary, Rust's testing framework allows you to add them seamlessly alongside your code, making the process almost effortless.

I Write Better Code in Other Languages Now

Programming in Rust can feel akin to being in a tumultuous relationship. The compiler often admonishes you for errors that might go unnoticed in other languages. Over time, you adapt, learning to navigate the tightrope to avoid inciting the compiler’s wrath. Much like in real life, these behavioral changes linger long after the experience.

While this kind of pressure isn't a conventional means of fostering growth, it undeniably catalyzes change.

Now, I find myself uneasy writing code in other languages when things are out of order or when I neglect to check return values. I also experience undue frustration when faced with runtime errors.

Clippy Is an Excellent Tool!

Clippy, Rust's linter, deserves more than just the title of a linter. In a language where the compiler can be quite unforgiving, Clippy acts as a supportive companion rather than a mere tool.

The Rust standard library is vast and can make it challenging to locate specific functions among the multitude of granular types, traits, macros, and functions available. Many of Clippy's rules aim to identify common patterns that could be improved using standard library methods or types.

Clippy encompasses hundreds of rules that address performance, readability, and unnecessary complexity, often providing suggested code replacements. Additionally, it seems that soon you will be able to globally configure lints for your projects, a long-awaited feature that the Rust community has worked hard to implement.

Gaps You Must Accept

I often questioned my sanity regarding Clippy’s limitations. Surely, there must be a way to configure lints globally. Despite extensive checks, I found no solution, and this issue lingered unresolved for years.

While Clippy is impressive, this situation exemplifies a broader issue within the Rust ecosystem. I frequently encounter libraries or tools that don’t cater to my specific needs. This isn’t unusual in emerging languages, but Rust has been around long enough that it feels unusual.

In open source, early adopters typically address edge cases, refining projects for future users. Rust has consistently been ranked as the "most loved language," attracting new users. However, this influx hasn't necessarily led to significant improvements in libraries or tools; instead, it has resulted in isolated forks for specific use cases.

I can't pinpoint the cause of this stagnation. Perhaps the pressure to maintain stable APIs combined with Rust's granular type system inhibits library owners from making changes. Alternatively, writing versatile Rust code that serves a broad audience can be daunting, discouraging developers from attempting it.

Cargo, crates.io, and Project Structuring

I structured the Wick repository based on popular projects I admired. It worked well until it didn't.

While you can easily build, test, and use module-sized crates with Cargo, publishing them to crates.io introduces challenges. You cannot publish a crate unless every referenced crate is also published individually, which seems reasonable but poses a challenge for developers who naturally break large projects into smaller modules.

This limitation feels arbitrary. You can design projects in this manner, but publishing them becomes a hurdle.

Edit: Ed Page reached out to clarify that you can publish with local dev dependencies, provided that you do not specify a version in Cargo.toml.

Cargo does provide excellent workspace support, offering a better experience for managing large projects than many languages. However, it doesn't alleviate the deployment issue. Setting up workspaces can be done in various ways, but none simplify the deployment process.

The frustrations manifest in the abundance of utility crates created to facilitate workspace publishing, each compatible with a limited set of configurations. The elusive "one true way" to set up workspaces continues to elude me, leading to hours of repetitive manual tasks when publishing Wick.

Async Programming

Rust introduced asynchronous programming after its initial release, and it often feels like an afterthought. This addition can create confusion and complicate matters with difficult-to-understand error messages. When searching for solutions, you must navigate the different runtimes and their async implementations. If you wish to use an async library, you might find it incompatible with your chosen async runtime.

With two decades of JavaScript experience and a solid background in Go, async programming remains my most significant source of frustration in Rust. It’s a manageable challenge, but you must always be prepared to confront async issues head-on.

Refactoring Can Be Tedious

Rust's complex type system can be both a blessing and a curse. While thinking in Rust types can be enjoyable, managing them can be a nightmare. Your data structures and function signatures may involve generics, lifetimes, and trait constraints, often resulting in more type constraints than actual code.

You must define all generics for every implementation, which can be tedious when initially coding. However, during refactoring, a minor change can lead to a cascade of complications.

Making swift progress is challenging when you need to update numerous definitions before moving forward.

Edit to clarify: The issue isn't with expressibility; rather, there's no solution in the language or tooling to minimize duplication. While there are often reasons to have identical constraints or refer to the same generics, there’s no way to create an alias or central reference. The absence of a solution doesn’t lessen the burden of duplication.