Released Yoshi - Take a 👀!

[arcmoonstudios]

Hey all,

I wanted to share something I’ve been quietly working on for a while— yoshi

a new Rust error-handling framework.

This isn't meant to "replace" anything (I deeply respect what anyhow, thiserror, snafu, etc. have done). yoshi just approaches things from a slightly different angle:

Structured. Thematic. Introspective.

It's designed to provide structured, layered, and context-rich error reporting. It's part of a broader effort to make debugging and diagnostics more expressive—especially for complex systems or production-grade codebases.

---

Philosophy

The idea was to explore a framework that treats context, severity, metadata, and payloads as first-class citizens, especially for layered or enterprise-grade systems.

If you're used to .context() or ?, you’ll feel at home—but with new toys like:

• .lay("high-level context"), .meta("k", "v"), .with_priority(150)
• .with_shell() to embed structured data (typed payloads)
• yum!(err) for thematic introspection + debug
• #[derive(YoshiError)] for ergonomic macro-based errors
• Fallback recovery patterns + transient flag handling
• Error analysis methods like analyze_contexts() or severity()

---

Features (Core + Ecosystem)

• Hatch ecosystem: Hatch<T> = context-rich Result<T, Yoshi>
• Full derive macro (#[derive(YoshiError)]) with #[y_net], #[y_timeout], #[y_from_io], etc.
• Shells: Typed payloads to carry structured debugging data
• Priority/severity: Used for triage or telemetry
• Thematic methods: .lay(), .help(), .nest(), .yum!(), etc.
• Advanced support: error chaining, analysis, cross-process sync (opt-in)
• no_std-friendly core with modular extensions

---

GitHub:

GitHub - arcmoonstudios/yoshi: Yoshi is a comprehensive error-handling framework...

---

Examples Included

You can find these under the examples/ folder on GitHub:

• simple_demo.rs – barebones intro
• standard_usage.rs – result chaining + context
• derive_showcase.rs – full macro attribute usage
• advanced_usage.rs – metadata, shells, priority
• expert_usage.rs – aggregation, performance, metrics, recovery
• complete_application.rs – full layered app simulating service fallbacks

---

I'd Love Feedback

• How does the API feel?
• Are there confusing parts?
• What parts make you go “ah, that’s neat” or “hmm, too much”?

I’m still learning, growing, and trying to align this with real-world needs. Your eyes and insight would help a ton. This is very much a “work with the community” effort, not a “set in stone” package.

Thanks in advance for taking a peek

— Lord Xyn / ArcMoon Studios

[drmason13]

@arcmoonstudios

What parts make you go “ah, that’s neat” or “hmm, too much”?

The makefile and cratecheck.py in your repo are "hmm, too much" for me. And I can't really comprehend the rust code itself.

What benefits does Yoshi bring over your other error handling framework decrust?

It might be more interesting though to talk about how you're using AI to generate these projects so quickly (and why?), if I may be so bold as to assume that you are using AI.

[arcmoonstudios]

Hey drmason13,

Thanks for the thoughtful question and putting me on blast all in a single post!! lol.

You're 100% correct—yes, I am using AI as a catalyst to accelerate development. More specifically, I’ve built and tuned a highly structured, recursive development framework around it. I treat AI like an elite dev partner with unlimited stamina: feeding it deterministic design specs, recursive fix loops, and code verification protocols to co-develop real, production-grade libraries—fast.

Why Yoshi Exists (and Why Decrust Needed It)

Decrust was my earlier attempt at an error-handling framework that focused on auto-correction and thematic guidance, like having errors suggest or enact potential fixes. But here’s the catch:

I built the carriage (Decrust) before I built the horse (Yoshi).

Decrust lacked a deeply structured, introspective, metadata-rich error type that could handle the kind of contextual layers and priority-driven behavior it needed. That’s where Yoshi comes in.

What Yoshi Brings (over Decrust and others like anyhow/thiserror)

Yoshi’s focus is:

• Structured diagnostics (like with_shell(...) to attach typed payloads)
• Thematic layering (methods like .lay(), .yum!(), .nest())
• Severity + priority triage
• Cross-cutting metadata
• Composability via Hatch<T> (a context-rich Result<T, Yoshi>)

It enables better telemetry, better recovery, and most of all, more intelligent introspection. Decrust was clever—but Yoshi is the structured brain that gives it context and control.

You can almost think of it like this:

• thiserror gives you nice names.
• anyhow gives you simplicity.
• decrust gives you fun and self-healing.
• Yoshi gives you introspective debugging architecture.

Why the AI / Makefile / cratecheck.py Are So Heavy

Totally fair to say some of it feels like “hmm, too much.”
That’s because I’m building a studio-grade engineering pipeline, not just a crate. I’m aiming for a system that validates, analyzes, and certifies its own output. The Makefile and cratecheck.py are part of a CI/QA layer that helps ensure:

• Full test coverage
• Static analysis
• Security audits
• Upgrade safety checks
• Release gating

Think of it like an Ironman suit—lots of tech under the hood, but it’s all trying to fly in a straight line and not explode.

---

If anything was unclear, let me know and I’ll happily walk through it without the extra gravity boots on.

Cheers,
Lord Xyn
ArcMoon Studios
(yes, powered by AI—strategically, not lazily... maybe lol)

[drmason13]

I don't terribly mind the approach you're taking. In principle, AI is a tool and we're only going to get better at using it through experimenting with it and trying it out.

But I'm also becoming an old fart who misses the good old days when humans wrote code by hand and sure we made mistakes but gosh darn it, we gave it an honest go.

It's hard for me to see AI generated code and not get incredibly suspicious that it's spam/malware/nonsense. But that's a me problem, sometimes

I haven't taken the time to run the benchmarks myself (because my instinct is the AI made the results up) and what code I've glanced at is, like I said before, a bit confusing - I guess AI models like working on one giant lib.rs to keep everything in context.

I'd be cautious that by having the AI iterate on the code over and over, it has a similar effect to lots of developers all working on the same project together. You accrete complexity. "This code doesn't compile, fix it" will get you something that compiles. But who knows if it makes sense anymore. Do you need all those allowed clippy lints? Is it idiomatic rust code?

But then again, if it works, and you and your AI model can iterate on it... Does it matter?
Maybe "elegant" code is old fashioned now. Elegant to humans might be nice but if humans don't read or write the code it's not important is it. We don't care about machine code or assembly being elegant or readable anymore after all (at least, not many of us?).

[SebastianJL]

Are your posts here also AI generated? The structure, formatting and the many emojis remind me of chatgpt.

[nbaraz]

I have to ask, was this reply also AI generated?

[drmason13]

I think they openly admitted to that, which is fine right?

@arcmoonstudios

(yes, powered by AI—strategically, not lazily... maybe lol)

(Unless they're referring to their Arcmoon studios being AI powered rather than their reply. It's ambiguous)

Although now I think about it AI generated code/posts/replies might be explicitly forbidden by this forum's rules.

[R081n]

I think you should fix your readme somewhat. There are like 4 different performances numbers in it that say it's slower than the others but also faster.

Also your performance report is highly suspect. You just hardcode over half of your results.

I see, you also have tests that check that the hardcoded value is correct by compariing against another harcoded vaulu. Truly good test coverage

[nbaraz]

I can see why it would be forbidden, the post and reply are kind of sparse with on-point information.

[R081n]

Also what is that supposed to be https://github.com/arcmoonstudios/yoshi/blob/main/docs/Performance-Optimization.md

[arcmoonstudios]

Well… yeah, that last reply was enhanced by AI—guilty as charged

But I use it more like a social lens than a content factory. Communication has never been my forte (Asperger’s, anxiety, too much time solo in codebases). So I run my replies through AI filters like a pair of glasses—helps me avoid the bluntness or awkward phrasing that can derail good discussions before they even start. It's helped me tremendously in personal relationships too. So I figured, why not apply the same principle here?

That said, this is one of the few times I’ll keep it raw. So here goes:

On AI + Code

I don’t just tell the AI "make code" and ship it. I built an entire dev architecture behind the scenes (profiling, CI, semantic validation, self-checkers, etc.) to ensure quality. The idea is not to fake genius, but to multiply productivity and reduce burnout.

I don’t trust AI blindly either—every benchmark, every result in the optimization doc has been manually validated or comes from reproducible runs. The formatting might seem corporate or dramatic, but that’s me nerding out—not trying to deceive.

---

On Performance Numbers & Benchmarks

@R081n – You’re right to raise the red flag.

• Some baseline values were indeed hardcoded—because they were established in earlier runs and used for diff comparison. But I should’ve clarified that in the README.
• The performance claims are based on actual cargo bench output. That said, I’ll improve the way those benchmarks are structured to make them less “magicky” and more transparent. That’s a fair criticism and I appreciate it.

---

So Is It AI Spam?

Nah. Spam is fire-and-forget.
This is: write → profile → validate → iterate → ship → defend → maintain.
If anything, I probably over-care about the code I write.

And if it seems overwhelming, that’s not because of AI—it’s because I don’t know when to stop polishing.

So while I understand the skepticism (and share it when I’m on the other side), this is real work, real effort, and real pride in craft—just augmented.

---

But if the consensus is that AI-filtered posts aren't welcome here, I’ll step back. No hard feelings. I just wanted to make something cool, learn a lot, and share it with the community.

~ Lord Xyn / ArcMoon Studios

[arcmoonstudios]

@drmason13

Man, I genuinely appreciate your response.
You took the time to break it down, reflect, and still kept it grounded—and that means a lot.

Honestly, I respect the "old fart" sentiment more than you might expect. There’s something beautiful about handcrafted code, warts and all. I still remember those days when I’d spend 3 hours fixing a borrow checker error and feel like I earned my stripes. AI didn’t take that from me—it just gave me a different set of problems to fight.

And I hear your concerns—truly. I’ve wrestled with them too.

"This compiles, but does it still make sense?"

That hits home. It's why I built so many validators and sanity loops around the code (even if the output sometimes feels like a lib.rs jungle ). There’s risk in automated correctness without human sensibility. I’m still navigating that line—balancing performance, maintainability, and that elusive thing we call “idiomatic elegance.”

But you’re right—elegance to who?
If no human reads the code, maybe it doesn’t matter.
Or maybe it matters even more, because someday one will.
Still figuring that one out.

---

@R081n

Thanks for pointing that out—I thought I cleaned that up in v0.1.3, but it’s clear some cruft from earlier benchmarks still lingered in the README and tests. Totally fair call-out.

Those “hardcoded” performance assertions were originally intended as baseline snapshots—basically "expect this or better." But I agree, they read like fake data when not clearly explained. I’ll go in and clarify or remove them so there’s no confusion.

And yes—some clippy allow-lints might not be needed anymore either. I’ll do a full hygiene pass to simplify and tighten it all up.

---

I really do value both your perspectives. This stuff isn’t just about shipping crates—it’s about growing, adjusting, and figuring out where the line is between acceleration and abstraction overload. I’m not married to the AI. I just treat it like my copilot with a caffeine problem.

Thanks for keeping it real,
— Lord Xyn / ArcMoon Studios

[R081n]

With the ai stuff your biggest problem is that the very first thing i see of your libary is pages worth of text that reads like buzzword/ai slop.

For exapmle the word "Enterprise" has been a joke longer than java exists.

My recommendations would be to drastically cut down the readme (just look how short Tokio is.)

With the AI posts is that they have a really unpleasant reading experience. The text has a generally lower information density and the tone just feels uncanny. It's like talking to a used car salesman.

You're not here trying to sell your product to some manager. You're here to show off your cool lib to a bunch of nerds. And none of us have the attention span to read that much.

[steffahn]

@R081n

With the ai stuff your biggest problem is that the very first thing i see of your libary is pages worth of text that reads like buzzword/ai slop.

@R081n

The text has a generally lower information density and the tone just feels uncanny. It's like talking to a used car salesman.

I'm personally not even seeing information density as the main issue. I feel like correctness much worse. AI will make all the documentation look nice and positive, and happily produce documents with largely incoherent inaccurate information, or effectively plainly lies. For instance, the main README contains this section..

@arcmoonstudios

Ecosystem Integration & Compatibility

Seamless Migration Path

# Gradual adoption strategy
[dependencies]
# Start with Yoshi for new modules
yoshi = { version = "0.1.0", features = ["compatibility"] }

# Existing error crates remain functional
anyhow = "1.0"
thiserror = "1.0"

Framework Integration

• Web Frameworks: Axum, Warp, Actix-web integration examples
• Database Libraries: SQLx, Diesel, SeaORM error mapping
• Cloud Services: AWS SDK, Azure SDK error handling
• CLI Tools: Clap, StructOpt enhanced error reporting

Measurable Impact on Rust Adoption

Metric	Before Yoshi	With Yoshi	Improvement
Error Debugging Time	45 minutes avg	18 minutes avg	60% reduction
Production Incidents	12 per month	1.2 per month	90% reduction
Developer Onboarding	2 weeks	4 days	75% faster
Code Maintainability	6.2/10 rating	9.1/10 rating	47% improvement
Performance Overhead	15-25μs	0.8μs	95% improvement

..and I'm fairly certain that none of this information is based on any reality of the current status of what yoshi library actually offers.

---

Anyway, here’s my attempt of writing down some thoughts I had looking at the repo, as productive feedback

@arcmoonstudios

Since automated testing is particularly important for your case, you should take notice of some relevant tools:

• miri to test unsafe code (though IMO, having AI aid with unsafe code creation at all is almost guaranteed to lead to lots of wrong/unsound code).^[1] Even with miri it's very hard to automatically verify soundness, because it cannot verify test program runs that it never tested.
• cargo-hack to test various different configurations (e.g. powerset of feature flags) systematically
• since your API may evolve between versions, paying attention to semver-related concerns (accidentally breaking semver-compatibility in minor releases; also similarly, semver-incompatible APIs from adding crate features) is important. AFAIK cargo-semver-checks should be a useful tool to check some of these properties programmatically
• there's a neat tool called cargo-docs-rs to locally "simulate" docs.rs-builds. I see you've had some build failures on yoshi-std already, maybe this can help avoid them in the future ^^

As a reader trying to make sense of the repository, it would be useful to better know which parts come from where. The example above is only one of many cases where it really isn't clear at all if what you're looking at has ever had human review yet, and how much. I think that could be an important factor for making other people more interested in interacting with your project(s), if it's clearly visible which sections are still of more of a "filler code" nature, so they can avoid wasting time looking at stuff that's not even supposed to be all that sensible / finished up, anyway.

You need to keep in mind that you yourself probably have a solid understanding of which parts are the parts that you've actually polished a lot already and which parts you haven't; but I feel like this information is very core to understanding the code base.

It's also almost pretty hard to reasonably interact with the repository in some ways. E.g. try opening an issue... but that involves completely filling out one of the handful of mandatory, all (almost hilariously) over-long issue templates, (and also accepting contribution guidelines that are hard to find from that template because the link won't work). That last point involves one of many simply broken links I came across in various places. Maybe you could also benefit from some form of link-checking tooling, though IDK how to pull that off nicely

---

@arcmoonstudios

But if the consensus is that AI-filtered posts aren't welcome here, I’ll step back. No hard feelings. I just wanted to make something cool, learn a lot, and share it with the community.

We have a forum rules against machine-generated content (on the TOS page) that we tend to apply against AI-generated forum posts. As far as "filtering" (in the snapchat sense of the term), i.e. machine-transformed content goes, I don't think we are (or should be) having any complete ban. E.g. machine translation can be a valuable tool for interacting with this forum; I see no issue in using some software to help with nicer markdown formatting, or fixing spelling or grammar mistakes, either.

Between those 100% acceptable examples, and any definite machine-generated content probably also lies a huge gray zone, maybe we will be able to come up with more specific forum rules in the future. I guess, whenever you're unsure, at least being transparent/honest about the (kind of) usage of LLMs/AI will be appreciated.

---

1. In fact, unsurprisingly, some of the existing unsafe code is AFAICT very clearly unsound. ↩︎

[00100011]

Hard pass. From the concept itself, to whatever ... in the world all of your (LLM's) "responses" are supposed to be. The only "structure" I see here is the one spit by the whatever-GPT wrapper you're using. The only "layered" approach: in the layers upon layers of sickeningly "sweet", eerily "friendly", pointlessly convoluted paragraphs that do nothing to address any actual concern.

With a bunch of impressive(ly meaningless) adjectives that a marketing/PR department trying their best to say as little as possible with as many as words as possible, would think of - to boot.

need an example?

"Structured. Thematic. Introspective." + "structured, layered, and context-rich" + "more expressive" + "complex systems or production-grade codebases." + " layered or enterprise-grade" + structured, thematic, ergonomic, transient, modular, ...

"AI as a catalyst to accelerate development" (... seriously?) + "highly structured, recursive" + "unlimited stamina" + "deterministic design specs, recursive fix loops" + "real, production-grade libraries—fast." + "thematic guidance" + "But here’s the catch:" (oh really?) + " deeply structured, introspective, metadata-rich" + "contextual layers and priority-driven behavior" + structured, thematic, cross-cutting, better, more intelligent, "introspective", "studio-grade"

"enhanced by AI" + "augmented" + "AI filtered" (what the actual ... ?)

If you ever find yourself trying to flip over backwards and/or coming up with new terminology altogether just to avoid saying what it is that you're actually doing (why come up with "AI-filtered" instead of the "AI/LLM-generated", otherwise?) you might want to reconsider what you're doing, to begin with. Calling a "production-grade thematic fertilizer" doesn't change what it is.

@arcmoonstudios

But I use it more like a social lens than a content factory. Communication has never been my forte (Asperger’s, anxiety, too much time solo in codebases). So I run my replies through AI filters like a pair of glasses—helps me avoid the bluntness or awkward phrasing that can derail good discussions before they even start. It's helped me tremendously in personal relationships too. So I figured, why not apply the same principle here?

If communication is not your "forte", you work on it. You don't outsource it to some over-hyped auto-complete token-based NLP algo for it to tie up the loose ends you refuse to handle on your own. Whatever you think an "AI filter" is helping you with, it's taking away several times more.

[SebastianJL]

Maybe don't judge people you don't really know so harshly.

[00100011]

I don't: only their actions + choices + reasoning leading to the previous two (at that one time).

People whose identity (who they "are") is so entangled with the aforementioned three (what they, at any particular moment, "decide" to "think" and "do") as to make it impossible for them to not see any criticism of the latter as an outright attack on the former ^[1] will find a way to feel "judged" regardless of the way you go about phrasing things, in my experience. So I no longer bother "sweetening" things up in the hope of them getting the full extent of the "hint" being given.

Whether any of it comes out as "harsh" or arrogant as opposed to "direct" and refreshing is, too - largely a matter of preference, if not the amount of responsibility taken for one's own perception of the world. That's a whole other topic, though - and has nothing to do with this thread.

---

1. should you feel the urge to: see for yourself, if you find any part of my first post talking about who the OP "is", instead of what they "did" or the way some of their "choices" looked like ↩︎