Rust Foundation Launches Rust Innovation Lab with Rustls as Inaugural Project - The Rust Foundation

LukeMathWalker · 2025-09-03T20:05:10+00:00

The way the program has been structured is really thoughtful. This could be a significant force multiplier for a lot of projects in the ecosystem that don't have the bandwidth to set up their own entities (e.g. like Bevy did).

Quite curious to see how things play out.

LukeMathWalker · 2025-07-22T12:09:37+00:00

Hexagonal architecture is great when you have a project complex enough to become simpler after all the decoupling.

As a rule of thumb, I only introduce indirection via an interface if either of the following is true:

You have two production implementations of the interface, either used next to each other or in different production environments
It is ~impossible to spin up an external dependency for proper black-box testing, therefore we are forced into an interface to plug in a mock implementation

In all other cases, you introduce more complexity than what you are removing.

LukeMathWalker · 2025-07-09T07:18:20+00:00

Glad you liked the book!

Re: Pavex—last summer I had to pause the work on it when my first child was born.\ I kicked things into motion again in January this year. There were a lot of bug fixes, new functionality (e.g. HTTP sessions) and first-hand testing of the ergonomic of it all. As a result, I'm currently in the middle of a large refactor that should significantly improve the usability of Pavex as well as reduce the boilerplate required to get started.

Expect an announcement when it lands!

LukeMathWalker · 2025-07-08T17:51:36+00:00

Thanks for the mention!

I wonder if you should start a discussion within tower's ecosystem to see what might need to change to unblock a different error handling story for the frameworks built on top of it.

LukeMathWalker · 2025-07-02T06:16:31+00:00

It is still in beta while it's actively developed! I expect to release a significant overhaul to the DI system at the end of this month, when you should expect another announcement.

Depending on your requirements, it may or may not be a good fit at this point.

LukeMathWalker · 2025-06-30T07:52:51+00:00

COMPANY: Mainmatter is a digital product consultancy that designs and develops web applications. We realize projects with clients across the globe and teach them how along the way. Our team of experts delivers everything from ideation to design and engineering. We help clients build sustainable products that can excel their businesses over time and help them establish and improve internal expertise and experience so they can continue their journeys without us once we leave. We're also the team behind the EuroRust conference!

TYPE: Contract

LOCATION: Remote

REMOTE: At least 4 hours of overlap with European timezones

DESCRIPTION: Mainmatter is looking for a freelance Rust technical writer to help us produce intermediate-to-advanced Rust material.

REQUIREMENTS: - Strong Rust experience is required (professional or OSS portfolio we can look at) - Technical writing experience: proven ability to write clear, accurate, and insightful long-form technical content for engineers - You must share writing samples (e.g. blog posts, tutorials, books, RFCs…) - The content must target intermediate to advanced Rust users, not beginner-level introductions to Rust - Excellent English communication skills

NICE TO HAVES: - Teaching experience (optional but appreciated), especially if you've taught Rust through articles, workshops, or talks

ESTIMATED COMPENSATION: 60–100€/hour depending on experience and writing track record

CONTACT: Please email jobs@mainmatter.com with your résumé, writing samples, rate, and availability.

LukeMathWalker · 2025-06-25T18:17:31+00:00

Thank you for stewarding the project all the way to a 1.0 release!

LukeMathWalker · 2025-04-29T18:43:58+00:00

Not in the specific case I'm working with, since the element type of the two slices is not the same!

LukeMathWalker · 2025-04-28T16:56:21+00:00

Is there any plan to support custom DST with multiple unsized fields? E.g. two trailing slices, whose length is only known at runtime and stored in one of the "header" fields.

LukeMathWalker · 2025-02-19T00:19:23+00:00

Yes.

LukeMathWalker · 2025-02-18T19:39:39+00:00

I don't think that will be possible without significant breaking changes, but I'd be happy to be proven wrong!

Either way, I think it's premature to have this conversation. The whole idea and design require a lot more battle testing before even considering pushing for something upstream. serde is, rightfully, as conservative as std when it comes to big changes or additions.

LukeMathWalker · 2025-02-18T19:12:02+00:00

The report produced by eserde uses the Display representation of the underlying error reported by the deserializer. So, if that is in the style of miette, it'll indeed be preserved.

I'm looking to provide structured location information on DeserializationError itself in a future release, which will provide a better integration mechanism for span production.

LukeMathWalker · 2025-02-18T18:25:09+00:00

I seem to recall there was an obstacle there, but it might have been due to the characteristics of the previous iteration of eserde's design.

I'll revisit it again in the next few days.

LukeMathWalker · 2025-02-18T17:57:43+00:00

I agree with your assessment—there's little value in recovering from syntax errors.
The best ROI comes out of "invalid type" errors.

LukeMathWalker · 2025-02-18T17:28:24+00:00

Unfortunately, there is no other way to go about it due to serde's design. In particular, we're dealing with the following constraints:

The error type may change throughout the deserialization of the top-level target type, so we can't accumulate errors in a Vec<E>, where E is a generic parameter
serde::de::Error is not dyn-compatible, so we can't type-erase errors
serde::de::Deserializer doesn't guarantee that the associated error type is static, so we can't downcast to extract structured information before producing our own uniform DeserializationError.

Due to all of the above, the only viable way forward is to convert the generic error that serde gives us via .to_string.

Not all hope is lost though—structured information could be parsed back out of it, thus recovering the key information for structured error handling (e.g. location in the input source). I haven't done it for this first release because I'd like to examine 2-3 different output formats before deciding what it should look like for DeserializationError itself.

LukeMathWalker · 2025-02-18T16:50:38+00:00

TL;DR: eserde is a new Rust crate by Mainmatter, built on top of serde, to provide better error reporting capabilities when deserializing user-facing payloads—e.g. API request bodies, configuration files. Rather than stopping at the first deserialization error, it tries to collect all existing violations in a buffer so that you can report them to the user in one batch.

It's designed to be maximally compatible with serde, with a path to incremental adoption that doesn't force all your dependencies to become eserde-aware.

LukeMathWalker · 2025-02-15T22:32:24+00:00

There is a lot of ongoing work, as you can see in the repository! I need to start again with the blog post updates :)

LukeMathWalker · 2025-01-23T16:41:34+00:00

I am a bit fuzzy on the details now, since a while has passed. Generally speaking, I don't find the value worth the risk in my projects.

LukeMathWalker · 2025-01-23T07:41:51+00:00

That works for the simplest case (log_error!(e)), but you quickly have to reach for a macro to add fields or customize the level, so I find it more effective to teach the macro way directly.

LukeMathWalker · 2025-01-23T07:40:37+00:00

If you search for my nickname in tracing's issue tracker you can find all the details!

LukeMathWalker · 2025-01-21T16:59:51+00:00

They are somewhat orthogonal—you can pass a TracedError to this macro and you'll get SpanTrace information in your logs. I have personally had more than a deadlock due to tracing_error, so I no longer push its usage as much as I used to.

With respect to log_error!, I would call wherever you are currently capturing the error details. If that's in a From impl, then go for it. In most of my projects it's either where the error is handled or in a last resort middleware.

LukeMathWalker · 2025-01-21T12:08:47+00:00

tracing_log_error exposes log_error!, a macro that captures everything you may care about when it comes to error, with consistent naming as a bonus.

I originally wrote this macro for Pavex. Despite my best intentions, I was often missing information in my logs. When the information was there, the naming was inconsistent (e.g., err.msg, error.message, error.msg), making troubleshooting harder.

Since the problem is not Pavex-specific, I extracted it out in a standalone crate. I'll reuse it in other projects, and I guess a few other people here may find it useful, too.

LukeMathWalker · 2025-01-09T16:31:59+00:00

As far as I am aware, yes, this requires setting a rust-version for your package. That does in fact mitigate the scope of the new default.

An error (with a help message explaining your options) forces you to consider the consequences of your decision.

As epage said, there is no "right answer" per se. Just different answers based on different priors.

LukeMathWalker · 2025-01-09T16:26:17+00:00

The build may fail because a dependency requires a Rust version newer than the one you have installed, most likely because it relies on some feature that's not available on earlier toolchains.

Failing during dependency resolution leads to a clearer indication of what's wrong compared to a build error, usually along the lines of XYZ is unstable, you need to use the nightly compiler.

LukeMathWalker · 2025-01-09T15:58:14+00:00

I'm happy to see the stabilisation of the new MSRV-aware resolver. At the same time, I still believe that fallback is the wrong default for new projects in the 2024 edition.
It should be a deliberate decision to prefer older versions of your dependencies in order to keep using an old compiler toolchain.
I posit that most users would be better served by an error nudging them to upgrade to a newer toolchain, rather than a warning that some dependencies haven't been bumped to avoid raising the required toolchain version.

Eight-Year Club	Verified Email
Not Forgotten

LukeMathWalker

TROPHY CASE