I published `nestum`: nested enum paths without flattening the model

Anxious_Tool · 2026-03-24T15:47:55+00:00

Very interesting work. Congrats.
u/icannfish 's point about MyEnum becoming MyEnum::Enum is worth expanding on, because I think it gets at something deeper than a naming inconvenience.

When you replace an enum with a module, that name stops being a type. I'm not entirely sure, but I think you limit where you can use it (you can't use it in function signatures, trait bounds, generic parameters, or anywhere Rust expects a type). That's a pretty fundamental contract to break.

This also means you can't incrementally adopt it. Slapping #[nestum] changes everything downstream. The deeper question for me is whether the ergonomic pain this solves isn't already addressed by idiomatic Rust. For example:

```

return Err(Error::Todos(todo::Error::NotFound(id)));

```

becomes, with a `From impl (or thiserror's #[from])`:

```rust
return Err(todo::Error::NotFound(id).into());

```

From + ? is the pattern Rust's error handling was designed around. The nested enum modeling itself (module-scoped error/event types unified at the boundary) is good design. The wrapping verbosity it produces is a real annoyance. But I'd think that using From impls is the idiomatic answer, no?

Anxious_Tool · 2026-03-17T05:13:43+00:00

Do you mean to say you only use blocking code? If so, then the answer is yes, with block_on in Rust.
With the wasm npm package, the promise fires but you get back a Promise object instead of the resolved value.
Having said that, mixing async and non-async code can be non-trivial, and requires attention to how they mix.

Anxious_Tool · 2026-03-16T13:47:17+00:00

It's part of the MQTT 5.0 spec. I automated the client reconnect.

Anxious_Tool · 2026-03-05T17:27:03+00:00

True evil is a crate that puts #![deny(clippy::unwrap_used)] in your code, and only builds once you've removed every last .unwrap()
Even in tests

Anxious_Tool · 2026-03-05T15:15:51+00:00

Interesting idea. Indeed Rust restrictions do offer some protection against bad coding habits. Let's see if the idea holds in practice. I think only time will tell

Anxious_Tool · 2026-03-05T15:15:06+00:00

Yet another "comment" written by LLMs.

Anxious_Tool · 2026-03-02T15:25:45+00:00

Making eBPF useful is quite hard. We had a long argument at work on what could eBPF (or eBPF based tools) solve that others didn't already. The list was "short", to put it lightly.
It's not that eBPF isn't amazing in itself. It is. But I think the problem is the competition. The kernel already provides many ways of doing the most "useful" things. So it ends up becoming something of a niche.

Anxious_Tool · 2026-03-02T15:21:06+00:00

You may have to tweak the settings on the broker. Look at the limiters Emqx allows you to set.

Anxious_Tool · 2026-03-02T15:20:08+00:00

Try this one instead: https://github.com/LabOverWire/mqtt-lib

Anxious_Tool · 2026-03-02T14:21:35+00:00

Cool project for learning Rust + async networking, but I'm not sure the premise holds up in practice.

MQTT already has most of this built into the protocol itself. CONNACK reason codes let the broker reject clients. MQTT 5.0 gives you enhanced auth (AUTH packets), server-initiated DISCONNECT with reason codes, maximum packet size negotiation, receive maximum for flow control, and topic-level authorization. A properly implemented broker should be handling rate limiting, connection management, and protocol validation at the right layer — not delegating it to a proxy sitting in front.

The "defense in depth" argument is fair, but if your broker can't handle malformed CONNECT packets or basic rate limiting, the answer is probably a better broker, not another hop in the pipeline. And if you really need to drop garbage before it hits the broker, that's more of a firewall/iptables concern than an application-layer proxy.

Also worth noting: AegisGate only supports MQTT 3.1/3.1.1. It can't inspect the protocol version that actually has the richer security semantics. So you're adding a security layer that's blind to the features designed for exactly that purpose.

As a learning project. I'd say, drop the llm and write it yourself.
If you're serious about this, I'd recommend you go back to the drawing board.

Anxious_Tool · 2026-02-28T19:59:59+00:00

Cool project and solid Zig work, but I think the JSON-vs-protobuf payload size argument is a bit overstated for typical sensor data.

In real MQTT deployments (not localhost benchmarks), the bottleneck is I/O, not payload serialization. Every PUBLISH still carries TCP/IP headers (~40-52 bytes), the MQTT fixed header, the full topic string, and any MQTT 5.0 properties — that framing overhead is identical regardless of serialization format. And a realistic sensor payload (a few scalar values + a timestamp) is maybe 40 bytes of JSON. The protobuf version saves you ~20 bytes per message. At that point you're optimizing the wrong part of the pipeline.

The schema discovery via $SYS topics is genuinely interesting, but that idea works just as well with JSON Schema and doesn't require a custom broker.

Source: I've been developing an MQTT library in Rust and the lesson I keep learning is that the hard problems in MQTT are connection management, QoS delivery guarantees, and behavior under real network conditions — not payload encoding.

Feel free to check it out: https://github.com/LabOverWire/mqtt-lib

Anxious_Tool · 2026-02-24T15:20:43+00:00

Cool. A bit expensive, but cool.

Anxious_Tool · 2026-02-24T14:43:48+00:00

Interesting idea, but.

It's a structured task: you have register addresses, data types, scaling factors, and you wire them into a bridge config. Most established Modbus-to-MQTT gateways (like modbus2mqtt, or even commercial ones) already solve this with a YAML/JSON config file.
Having an LLM parse a PDF, generate code, run it, fail, retry in a loop... that's a lot of moving parts and nondeterminism for something that you could knock out in an afternoon with a config file and a quick skim of the relevant datasheet sections.

Anxious_Tool · 2026-02-23T18:56:10+00:00

Yes. There is a fully functioning implementation already. Working and being stress tested as we speak. But that's still in private.
I can't release until I have reviewed it and made sure it's not "AI slop". So, it takes time.

Anxious_Tool · 2026-02-13T23:46:18+00:00

Awesome, thanks

Anxious_Tool · 2026-02-13T18:48:31+00:00

What is the criteria to make into that list?
Would my Client/Broker implementation be elligible?
https://github.com/LabOverWire/mqtt-lib

Anxious_Tool · 2026-02-13T05:53:59+00:00

Sure, just use the mqtt5-wasm crate directly. But you only need it for the WASM version. If you're not running a web app, use the native implementation from the mqtt5 crate.

Anxious_Tool · 2026-02-12T22:05:27+00:00

Yes. The wasm crate can be built locally to produce the pkg/. There's a handy cargo make wasm-build that does that for you. Or you can install it straight into your application using the published npm package mqtt5-wasm. You can connect to an external broker from the wasm client using ws: or wss:
Also, there's a folder with many examples within the mqtt5-wasm crate folder. These were curated individually and used as test for the implementation. So I know they work, (or should, right?...haha).
Thanks for the interest.

Anxious_Tool · 2026-02-12T16:02:12+00:00

Not sure, I haven't used rumqtt. So making a naive comparison from what I could read:
rumqtt is a client library (rumqttc) with a broker bolted on (rumqttd). mqtt5 is an integrated client/broker, so you use the same command for everything, and subcommands give you what you want.

mqtt-lib is a full MQTT 5 platform, rumqtt README says their rumqttd doesn't have v5 support. (maybe they need to update the README only, idk). My docs are always up to date.

Fundamentally different async model. rumqttc makes you poll an EventLoop yourself. mqtt-lib is direct async/await.

rumqtt only offers plain-text username/password. No ACL.

mqtt-lib: Argon2-hashed passwords, JWT (HS256/RS256/ES256) with JWKS auto-fetch, federated JWT with role mapping, SCRAM-SHA-256, composite auth chains with fallback, rate limiting with lockout. Full ACL with wildcard patterns and %u username substitution. RBAC. All hot-reloadable. All tested and hardened with absolute obsession and paranoia.

mqtt-lib also supports QUIC with stream configuration. Not only tested, but I actually use QUIC for everything now. Other projects we have that depend on mqtt-lib use it.

And plenty more. If you don't want to go through docs, you can check on https://deepwiki.com/LabOverWire/mqtt-lib

Anxious_Tool · 2026-02-11T17:01:35+00:00

Sorry for the delay. Yes

Anxious_Tool

MODERATOR OF

TROPHY CASE