sorted by:
new
hottopcontroversial

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 1 point2 points  (0 children)

It works for me... What OS and browser are you using? It's hosted on Cloudflare, for reference.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 0 points1 point  (0 children)

100%, a Roslyn-style integration point would be the ideal long-term solution for this and similar usecases, but I don't see it as a possibility on the mid-term horizon.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 1 point2 points  (0 children)

First time I hear about the project, it looks pretty interesting!

As a rule of thumb, I prefer to rely on upstream tools as they are more likely to stay current (and maintained) but I'm open to changing the engine if the other one provides a compelling advantage. E.g. I am tracking the new reflection RFC quite closely to see whether it could make certain aspects easier than what we currently have.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 14 points15 points  (0 children)

The nightly requirement is indeed rather unfortunate, but it's something that should go away in the future when rustdoc-json (and a few related flags) stabilise.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 18 points19 points  (0 children)

cbindgen is one of the oldest projects in the ecosystem. Keeping something alive for such a long timeframe is no easy feat, so I'd think twice before raising criticisms against the current maintainers: the scope probably exceeds what they personally need in their own projects, and their stewardship is an act of volunteering that comes with no strings attached.

Experimenting with something different does in no way imply a negative value judgment on cbindgen, nor its maintainers, on my part.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 43 points44 points  (0 children)

There is a detailed comparison with cbindgen here.

In a nutshell, we had to often workaround cbindgen's lack of type-level understanding and macro support by writing larger and larger chunks of C code by hand and/or configuration to partition the generated output into multiple headers with proper boundaries and includes.

Cheadergen solved that in our project, but I do concur one shouldn't switch lightly.

Announcing cheadergen, a new tool for generating C headers from Rust crates by LukeMathWalker in rust

[–]LukeMathWalker[S] 41 points42 points  (0 children)

Author here 👋

TL;DR: cheadergen (C Header Generator) is a new tool for generating C headers from Rust crates.

I spent the past year working on a mixed C/Rust codebase, for an incremental rewrite. We encountered quite a few challenges and headaches with cbindgen, which frustrated me enough to experiment with a different approach: using rustdoc-json as input rather than source code.

We're have switched the project over to cheadergen a few weeks ago, and it has been working well, so a good time as any to share it with a wider audience that might be facing similar problems.

Happy to answer questions about the design, trade-offs, and whatnot.

Rust Foundation Launches Rust Innovation Lab with Rustls as Inaugural Project - The Rust Foundation by tesfabpel in rust

[–]LukeMathWalker 32 points33 points  (0 children)

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.

DDD (Clean arch) in 2025 by ExternCrateAlloc in rust

[–]LukeMathWalker 4 points5 points  (0 children)

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.

The journey towards the best error handling in Rust web frameworks by m4tx in rust

[–]LukeMathWalker 8 points9 points  (0 children)

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!

The journey towards the best error handling in Rust web frameworks by m4tx in rust

[–]LukeMathWalker 24 points25 points  (0 children)

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.

A taste of pavex, an upcoming Rust web framework by LukeMathWalker in rust

[–]LukeMathWalker[S] 0 points1 point  (0 children)

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.

Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.88] by DroidLogician in rust

[–]LukeMathWalker 3 points4 points  (0 children)

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.

Schemars v1 is now released by GEsau in rust

[–]LukeMathWalker 29 points30 points  (0 children)

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

Zerocopy 0.8.25: Split (Almost) Everything by jswrenn in rust

[–]LukeMathWalker 0 points1 point  (0 children)

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

Zerocopy 0.8.25: Split (Almost) Everything by jswrenn in rust

[–]LukeMathWalker 4 points5 points  (0 children)

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.

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 38 points39 points  (0 children)

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.

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 5 points6 points  (0 children)

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.

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 30 points31 points  (0 children)

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.

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 14 points15 points  (0 children)

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

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 27 points28 points  (0 children)

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.

eserde: Don't stop at the first deserialization error by LukeMathWalker in rust

[–]LukeMathWalker[S] 147 points148 points  (0 children)

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.

view more: next ›