emmanueloga_

Would it be hard to translate to Spanish? I'd love to share with some friends that love books but don't speak English!

good point, could be some 10 years ago now, I think...

I got into OCaml for a while, which naturally led me to try F#. What pushed me away back then was that the tooling lagged behind C#, especially in VS Code, and the C#/F# interop wasn’t as ergonomic as I expected. I liked the idea of using F# for the core and C# around the edges, but it didn’t feel smooth in practice. This was years ago, so maybe the tooling has improved since.

I’ve always wondered whether tighter integration with C# would have led to broader adoption, though that might have changed the character of the language.

How about framing this in terms of two orthogonal axes the article doesn’t name: concurrency (actors) and continuity (durable execution).

* Durable execution: long‑running, resumable workflows with persistence, replay, and timeouts.

* Actors: isolated entities that own their state and logic, process one message at a time, and get concurrency by existing in large numbers (regardless of whether the runtime uses threads, async/await, or processes under the hood).

Combine the two and you get a "Durable actor", which seems close to what the article calls an “async agent”: a component that can receive messages, maintain state, pause/resume, survive restarts, and call out to an LLM or any other API.

And since spawning is already a primitive in the actor model, the article’s "subagent" fits naturally here too: it’s just another actor the first one creates.

I’ve been thinking that defaulting to durable execution over lower‑level primitives like queues makes sense a lot of the time, what do you think?

A lot of the "simple queue" use cases end up needing extra machinery like a transactional‑outbox pattern just to be reliable. Durable‑execution frameworks (DBOS/Temporal/etc.) give you retries, state, and consistency out of the box. Patterns like Sagas also tend to get stitched together on top of queues, but a DE workflow gives you the same guarantees with far less complexity.

The main tradeoff I can think of is latency: DE engines add overhead, so for very high throughput, huge fan‑out, or ultra‑low‑latency pipelines, a bare‑bones queue + custom consumers might still be better.

Curious where others draw the line between the two.

Tried writing an electrostatic particle simulator in Turbo Pascal 7 with BGI as a teen, a handful of particles before it crawled. Then saw a galaxy collision sim on a CD-ROM magazine disc handling thousands of bodies smoothly. Thought it was assembly tricks.. now I'm sure it's algorithmic (avoiding N**2 runtime) but never dug into the specifics. Are charges vs gravity sims essentially the same n-body problem?

I haven't used ruby in more than a decade, but I remember there was always some controversy around the corner. Up next: Zed Shaw comes out from his cave, joins forces with the mummy of _why to combat DHH's anti-woke agenda.

How about... inlining children:

    const age = 40;
    const children = [<div ~ "Moe" />, <div ~ "Larry"/>, <div ~ "Curly" />];
    return <div age ~ children />;

Rationale: single child elements are ubiquitous in web dev, but most JSX formatters will require 3 lines of code even if there's a single child.