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!

Right! [0] Apparently there are not many standard connectors like these, but I found at least one [1] ...

0: https://www.zojirushi.com/blog/design-explained-our-easy-rel...

1: https://www.mcmaster.com/products/breakaway-magnetic-connect...

The excessive size of Go binaries is a common complain. I last recall seeing a related discussion on Lobsters [1]. Who knows, maybe the binary could be shrunk a bit? IMHO 12mb binary size is not that big of a deal.

--

1: https://lobste.rs/s/tzyslr/reducing_size_go_binaries_by_up_7...

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.

Page Object Models trade off clarity for encapsulation. Concrete example [1]. They can make tests look "cleaner" but often obscure what's actually happening. For example:

    await page.getStarted(); // what does this actually do?

    await page.locator('a', { hasText: 'Get started' }).first().click();
    await expect(page.locator('h1', { hasText: 'Installation' })).toBeVisible();

--

1: https://playwright.dev/docs/pom

How about... inlining children:

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

I just found that someone posted a showHN for an utility to solve this issue [1].

I think this reinforces the idea that is something that could be built into verdaccio.

--

1: https://news.ycombinator.com/item?id=44891786

I wonder if anyone use https://verdaccio.org/ to vendor packages?

In theory for each package one could:

* npm install pkg

* npm pack pkg

* npm publish --registry=https://verdaccio.company.com

* set .npmrc to "registry=https://verdaccio.company.com/ when working with the actual app.

...this way, one could vet packages one by one. The main caveat I see is that it’s very inconvenient to have to vet and publish each package manually.

It would be great if Verdaccio had a UI to make this easier, for example, showing packages that were attempted to install but not yet vetted, and then allowing approval with a single click.

Explanation of what this does:

https://github.com/steveruizok/perfect-freehand/tree/main?ta...

TIL about the Scanimate [1] [2].

--

1: https://en.wikipedia.org/wiki/DVNO#Music_video

2: https://www.youtube.com/watch?v=i1aT_CqhyQs

In real projects I typically group the classes in a way that makes it easier to read, something like this:

    <div class={tw(
      "block",
      "transform transition-all",
      "bg-white ring-1 ring-black/5 rounded-xl shadow-2xl",

      "max-w-3xl mx-auto overflow-hidden",

      "group-data-closed/dialog:opacity-0",
      "group-data-closed/dialog:scale-95",

      "group-data-enter/dialog:duration-300",
      "group-data-enter/dialog:ease-out",

      "group-data-leave/dialog:duration-200",
      "group-data-leave/dialog:ease-in"
    )}>
        ...
    </div>

There's been a lot of work in this area but no definitive answer, and few constructed languages speakers [1]. I imagine the wins may be marginal, similar to the wins in dvorak vs qwerty typing.

--

1: https://en.wikipedia.org/wiki/Linguistic_relativity#Artifici...

I'm a fan of the app, one of those rare web apps that have been reliably there for more than 10 years and "just works". Today I found out it has been refreshed and its source released [1].

Congrats Erv Walter for the launch of v2 and thank you for making the app and source available!

For those who haven't seen this before, this is a free web app that makes it easy to chart a moving average of the weight measured with smart scales (Withings/Fitbit), following the ideas on John Walker's "The hacker diet" [2].

--

1: https://github.com/ervwalter/trendweight

2: https://www.fourmilab.ch/hackdiet/

Not just height, anything that causes continuous repaints can become expensive. Search for "jank free" to find more resources on the subject, or check this oldish website [1].

--

1: http://jankfree.org/

Looks similar to https://github.com/kobalicek/mathpresso

Took me a while to find this [1]: "We’re building the next-gen operating system for AI agents."

--

1: https://sdsa.ai/

I like it! Suggestions:

* Clarify relationship with https://hckrnews.com/

* Don't put the settings in localStorage, use URL params. That has a lot of usability improvements including being able to share the state, bookmark it, and heads up the current state. Use Rison [1] for the URL params to make it nice to read.

* The settings overview is too terse. What does something like "Timeline, Top 20, Day, Comments"? Maybe you could turn that into a concise natural language sentence.

--

1: https://github.com/kou64yama/rison2?tab=readme-ov-file

"I understood that the poet's work wasn't in the poetry; it was in inventing reasons for the poetry to be admirable. Naturally, that ulterior work altered the piece for him—but not for anyone else."

  - J. L. Borges, El Aleph [1]

1: https://www.goodreads.com/quotes/8699659-comprend-que-el-tra...

Chrome debugger tools? htop? visidata [1]? Clicker games are interesting in that they start bare and end up filling the screen with controls. Rerun visualizations come to mind too [2].

--

1: https://www.youtube.com/watch?v=N1CBDTgGtOU

2: https://rerun.io/viewer

Cool! I did not know about that book. Added to [1]. :-)

--

1: https://github.com/munificent/craftinginterpreters/issues/92...

Looks great, is it comparable to Monica [1] or is it more business oriented?

--

1: https://github.com/monicahq/monica

a "no brown M&Ms" razor!

That sounds great!

The article suggests running Kuzu in a FastAPI frontend for network access. A caveat: production Python servers like Uvicorn [1] typically spawn multiple worker processes.

A simple workaround is serving HTTP through a single process language like Go or JavaScript, since Kuzu has bindings for both. Other processes could access the database directly in read-only mode for analysis [2].

For better DX, the ideal would be Kuzu implementing the Bolt protocol of Neo4J directly in the binary, handling single-writer and multi-reader coordination internally. Simpler alternative: port the code from [3] to C++ and add a `kuzu --server` option.

--

1: https://fastapi.tiangolo.com/deployment/server-workers/#mult...

2: https://docs.kuzudb.com/concurrency/#scenario-2-multiple-pro...

3: https://github.com/kuzudb/explorer/tree/master/src/server

From my perspective, the article seems primarily focused on promoting React Server Components, so you could mention that at the very top. If that’s not the case, then a clearer outline of the article’s objectives would help. In technical writing, it’s generally better to make your argument explicit rather than leave it open to reader interpretation or including a "twist" at the end.

An outline doesn't have to be a compressed version, I think more like a map of the content, which tells me what to expect as I make progress through the article. You might consider using a structure like SCQA [1] or similar.

--

1: https://analytic-storytelling.com/scqa-what-is-it-how-does-i...