--

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

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.

* 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.

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.

    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

    const age = 40;
    const children = [
, 
, 
];
    return 
;

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

--

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

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.

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

--

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

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

    

        ...
    

--

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

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/

Comments URL: https://news.ycombinator.com/item?id=44675536

Points: 2

# Comments: 1

--

1: http://jankfree.org/

--

1: https://sdsa.ai/