Aeolos

I don't know about your country of origin, but in my country you are certainly liable and can go to jail if your dog seriously injures or kills someone.

Edit: the dog will also be taken from you and put down if it is deemed a risk to other people.

Did you miss the Anthropic and OpenAI blog posts screeching for regulation?

For the last 60 years, whenever AI achieves something revolutionary, some people immediately say "well that wasn't particulary revolutionary".

Every single time.

It's a tired argument, and we should strive for the intellectual humility to do better in this forum.

You audit the code, then you run cargo update and you are pwned. Asking the user to not make mistakes is the c++ approach to security - it doesn’t work.

cargo add + rust-analyzer instantly executes build.rs before you have a chance to audit the code.

Cargo, please PLEASE give me a way to disable third-party build.rs and whitelist the ones I need. And please loudly mark any update that adds a build.rs where there was none before.

The problem is that build scripts run automatically without user consent or intevention.

`cargo add` is sufficient to compromise you, before you have a chance to even vet the code.

We are serving over HTTP/2 and currently testing HTTP/3.

I don't have direct HTTP/1 vs HTTP/3 comparisons, because 0% of our requests are over HTTP/1 today...

The primary problem with SPAs is actually that the server state is duplicated client-side, which inevitably leads to state desync bugs.

The secondary problem is SPAs approximately double the amount of code you need to write compared to a server-side approach for the same level of interactivity.

The library is small enough I simply load the entire datastar codebase in the context when I need to ask how something works.

Once you have sufficient context in your html, this is no longer necessary.

Absolutely not, even on HTTP1.1.

Our webapp is achieving 800:1 to 5000:1 compression ratios pushing down the entire HTML page over brotli and zstd. The first render is about 20:1 compression, every interaction after that is 800-5000:1.

We are using datastar with the recommended "fat morph" approach where we re-render the entire HTML page from scratch on every request. Our typical RTT is <100ms including rendering, then the brotli / zstd compression window cuts down the wire size to literally _bytes_.

This is SO much more efficient than our previous reactjs & graphql render waterfalls with state duplication in the client side. All states lives on the server, all renders are authoritative, and we need to maintain roughly half the code size for better first-render and massively better interactive performance. Appserver and DB pressure is massively reduced too.

(This is a medical device with a highly interactive UI, image viewers, editors, not a boring old static website.)

You do you, but thankfully the rest of the industry disagrees with you.

And trending down.

IE6 was 97%, how did that work out?