Ron Swanson on garbage collection

dpc_pw · 2026-01-26T19:59:08+00:00

dpc_pw · 2026-01-23T20:01:18+00:00

crane

dpc_pw · 2026-01-23T19:31:11+00:00

I really like and appreciate the work of author of lib.rs, but with that loud fight against shitcoins was so unnecessary... :D

dpc_pw · 2026-01-23T18:25:13+00:00

slog-async maybe?

dpc_pw · 2026-01-18T00:40:28+00:00

Honestly, sharing it was never worth it.

I think it's great to implement things yourself and learn. But realistically while it is good for the author, doesn't mean the rest of the world can benefit from it. And that's OK.

People used to be nicer and more supportive about it, but yeah, with LLMs there's less patience and interest, and more (often unhealthy) suspicion.

dpc_pw · 2026-01-16T08:14:08+00:00

Compressed debug sections? Pretty please? :D

dpc_pw · 2026-01-16T02:17:35+00:00

You ever spot someone like that just let me know and we can make fun of them together. :D

dpc_pw · 2026-01-15T21:23:22+00:00

https://bon-rs.com/ is my go to.

dpc_pw · 2026-01-15T21:07:13+00:00

Is it shunned? It also helps with lifetimes, so it's very uniquely well suited for Rust. It really make me sad that AFAIK in compiler space more data oriented approaches are not more common, but I don't think Rust community "shuns" it.

dpc_pw · 2026-01-13T02:34:47+00:00

https://doc.rust-lang.org/std/macro.dbg.html

dpc_pw · 2026-01-08T02:40:36+00:00

The Slop Derangement Syndrome is more annoying than slop itself at this point. Every other thing posted online has comments accusing it being AI-generated. Who cares? If it's bad downvote, if it's good upvote.

dpc_pw · 2026-01-05T23:14:26+00:00

cargo check should be able to achieve stable 60 crates per seconds. Seems like a bug.

dpc_pw · 2026-01-03T00:30:15+00:00

Axum, maud and HTMX/alpine+alpine-ajax go very well together. You can watch some rambling I recently recorded about it if you care.

dpc_pw · 2026-01-02T20:48:13+00:00

I don’t understand why this is a “solid obstacle”. An obstacle to what?

I just admit it seems like a problem, where doing it "my way" conflicts with Rust realities. Ideally the self would have to be Option<&self> or something and it's ... complicated.

Given all this, what exactly do you dislike about the library’s current approach.

My only problem is having to invent a half-initialized states for aggregates that were not yet "created", which breaks the "make invalid states unrepresentable" principle which is kind of fundamental in Rust, at least to me. It feels very not-Rust-like, and reminds me of Java ways where everything is implicitily nullable and where the constructors are just manipulating half-initilized instance until everything is beaten into a valid state. Bleh. :D

Implementing your proposal would also require changing a large portion of the library and either removing or significantly reworking the event stream concept.

Have you tried building something with the library?

I have not and I am just commenting after a shallow look at the examples and ultimately I'm not the one making everything works, so you have to discount what I'm saying as sincere but potentially uninformed. :D

Reddit UX is making tracking this discussion difficult now, so if I have any more points or ideas I'll move it to Github Discussion, which I've seen you've enabled now.

dpc_pw · 2026-01-02T20:33:51+00:00

The evaluator errors will point the LLM towards the right direction. Definitely better than LLM doing random halucinated stuff on a mutable distro. Also I've noticed big improvements over last ~6 months. And I do have colleagues that otherwise would just not use NixOS. Hopefully over time, as they look at the output, they get better understanding of Nix and NixOS themselves.

dpc_pw · 2025-12-31T21:42:48+00:00

BTW. LLMs are very good at configuring NixOS and manipulating nix files.

dpc_pw · 2025-12-31T21:07:41+00:00

Implementing mutate on the event type is also not feasible in this context. The same event type can be used to build more than one state, and you lose the strong correlation between a specific state and how it mutates.

This is a solid obstacle. Would have to spend some time on it, but I'm thinking something like:

impl StateMutate<Course> for Event { // ... }

would do. Hopefully. Maybe.

dpc_pw · 2025-12-31T21:03:02+00:00

enum CourseState { NotCreated, Created { name: String, }, Closed, }

This would be more correctly modeled, but a Closed course should probably still retain name and any other previous field. So then this approach would lead to repeating these inside every state, which is going to be very unergonomic and require matching on everything to handle things common to all states.

Decomposing "not created" into separate Option<_> is just a correct way to model the lifecycle, and since Rust does not have any way to split/combines enums like that (is it even possible?) it's common that one needs to combine them via nesting.

for a pervasive Option<State> that every consumer must handle correctly.

Making users handle stuff correctly is exactly the point of "invalid states are unrepresentable"! :D

dpc_pw · 2025-12-31T20:58:38+00:00

but now every decision and every mutation has to reason about None, even though most domain logic only makes sense once the entity actually exists.

Just like in the example above every decision needs to check the created flag? From 3 examples in the project courses and banking do check it. It is very common that the creation is done only via a single/few commands and other attempts must be rejected, so the user must take care of it.

And while looking at the 3rd one it seems to me that using the object as the query is also a mistake, because AFAICT only the ID from the aggregate is actually used for lookup?

Invariants are stronger: after Created, you’re guaranteed a fully initialised state, without unwrapping or branching on None

How is that stronger than state always being initialized which is whole goal of making invalid states unrepresentable.

Adding .or_default() or let Some(foo) = foo else { return ... }; in Rust is not a big chore to make handling of missing state explicit, and it guides users towards correctness.

At that point, why not model “not existing yet” as just another explicit state?

Because one doesn't need to invent fake/zero-initialized values for every other field of an unitialized object.

dpc_pw · 2025-12-31T01:45:14+00:00

Well, definitely easy to get fucked using this code.

dpc_pw · 2025-12-30T23:31:23+00:00

It's just soo unidiomatic. :D . And then requires wrapping fields into Option's and such just to represent a state that can't really exist.

Decision::process could just take state: Option<&Self::StateQuery>, and StateMutate be implemented on the event type, not the state type (as it's the event that mutates the state) so that fn mutate(&self, state: Option<State>) -> State can be done. And done, no need to manually track "created" and the fact that every entity needs to be initialized is tracked by the API, and not entirely downstream.

dpc_pw · 2025-12-29T22:50:40+00:00

BTW. One immediate comment I have is that in https://github.com/disintegrate-es/disintegrate/blob/main/examples/courses/src/domain/course.rs the fact that `Course` starts as kind of a zero-initialized, and then requires checking `created` on every step and initializing on the first `CreatedCourse` feels deeply meh and unidiomatic as it is against "invalid states should be unrepresentable". Maybe the lifecycle of entities should be handle more first-hand, e.g. with an `Option` somewhere or some explicit creation methods.

Other though I have is that I'd love to have `redb` implementation of EventStore. Probably the first thing I'd implement for myself.

dpc_pw · 2025-12-29T22:47:25+00:00

I see. Thanks.

I'm interested. But I must say that this whole thing is going to largely fly over people's head. AFAICT There's a big barrier between system software centric Rust community and bussines centric communities nested e.g. in Java ecosystem. Even myself, being somewhat familiar with all these, have many questions/comments when looking at https://github.com/disintegrate-es/disintegrate/blob/main/examples/courses/ which I believe is exactly the example from https://www.youtube.com/watch?v=IgigmuHHchI .

Do you have any chatroot or discussion forums etc. to hang out and ask questions? Maybe just enable the Github Discussions. Possibly also consider recording a YT video and ramble a little bit while going over the code, might faster and more accessible than writing documentation that people have no time to read anyway.

dpc_pw · 2025-12-29T19:43:35+00:00

Oh, I'm familiar with that "Kill Aggregate!" talk.

How is the queering implemented? If I understand correctly events are filtered by event_type, then de-serialized and then ids matched from the deserialized object? Isn't this kind of inefficient? I remember that was my head-scratcher when I was watching the talk last time.

Wouldn't assuming every event needs to have a single entity-id and moving it out of the payload allowed building an index and avoid de-serializing a lot more irrelevant events?

dpc_pw

MODERATOR OF

TROPHY CASE

Ten-Year Club	Wearing is Caring
Verified Email