What's everyone working on this week (39/2026)?

New week, new Rust! What are you folks up to?

Just planning and experimentation for typed-ident this week, I'm heading towards adding better integration and support with proc-macro2.

Still working on uutils awk, the plan is to triage remaining failing GNU tests, clean-up & implement some missing functionality, and then cut an alpha release.

I wouldn't say it's ready for daily use, but we're inching closer. We could use some new contributors! If you're interested, DM me or drop by our discord! :slight_smile:

Been building BorrowFix this week, a small tool that lets you pick from curated Rust compiler errors (borrow checker, lifetimes, moves) or paste your own broken code, and explains what went wrong in plain English. Would love feedback from folks here
: https://borrowfix-smoky.vercel.app

proc-macro2 integration sounds like a solid direction, curious what kind of ergonomics you're aiming for with typed-ident, is the goal mostly compile-time safety for identifiers, or also better error messages when something doesn't match the expected type?

Thanks for the question!

To not derail this thread, I've added a response to my announcement post for this crate.

Feel free to take a look and respond there if you have further questions there. :slightly_smiling_face:

Trying to teach some logic inference to rustc; sadly, it (or LLVM) can't follow and optimize extra statements out.

The original code used this:

unsafe trait TrustedEq: Eq {
    /// Reflexivity, a logic requirement of [`std::cmp::Eq`],
    /// is a safety requirement for [`TrustedEq`].
    final fn trusted_refl(v: &Self) {
        // The block to be proven safe for arbitrary `v`.
        unsafe {
            std::hint::assert_unchecked(PartialEq::eq(v, v));
        }
    }
}

A bit late but I worked on and released a new sampling memory profiler for Rust, that you can use in production even, and makes memory profiling very easy:

I announced it at RustConf. I'm not sure what the decorum or community standards here but just want to share this with folks, I'm not sure if making a new thread is appropriate, but would love to get some feedback.

I recently rebuilt muhasib-e-hledger, my frontend for the hledger PTA tool, using axum & htmx instead of Leptos (i.e. WebAssembly). I’m currently working on performance. The hard work is done by hledger, not my code, so this mostly means wiring up input and output streams to let hledger invocations run in parallel instead of serializing them… which turns out to be a bit complicated in and of itself.

New release of epdsi

v0.6.0

Added

Added 4-level grayscale (Gray4) support for GDEQ0426T82 (Ssd1677Controller): GDEQ0426T82::GRAY4, Ssd1677Controller::with_gray4/reload_gray4_lut, Ssd1677RefreshMode::Gray4Preclear/Gray4, Gray4Polarity::ADAFRUIT_SSD1677, and render_paged_gray4_preclear. Ported from Adafruit_EPD's ThinkInk_426_Grayscale4_GDEQ, not Seeed or Good Display references.

Adafruit_SSD1677::update()'s grayscale branch runs in two passes: a baseline mono refresh, an LUT and voltage-register reload, then the final refresh. Because the crate's existing render_paged_gray4 helper assumes a single-pass update like the SSD1680 (GDEY0266T90), this controller requires its own refresh-mode pair and a dedicated render_paged_gray4_preclear helper.

Confirmed on physical hardware across all four target boards: RP2350 (blocking and async), ESP32-C3, and RP2040. Each renders four distinct gray levels correctly.

Building a small ui framework using native graphic api