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.

Yes, Rust gives you great access to low-level code on different platforms, including SIMD. It is also alias-free by default, and gives you excellent primitives to write multi-threaded code with compile-time correctness guarantees, which is how projects such as zlib-rs end up significantly faster than their C counterparts.[1]

It's about as good as it can get for this kind of code.

[1] https://www.reddit.com/r/rust/comments/1ixt1ei/zlibrs_is_fas...

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?

Trump was elected by the electors, not by the people. Not entirely dissimilar from how VDL was elected.

Breaking an illegal monopoly takes decades but, as it happened with Internet Explorer 6, it's finally happening for Windows.

However "world models" have been a thing for the entire history of computers. They have changed names over time: "rules engines", "expert systems", "semantic web", and so on and so forth.

And they have failed every single time.

The bitter lesson essay was written precisely to dismiss that approach, which used to dominate conferences and scientific publications of the era. A general learning system, given sufficient computation power, will always outperform specialized crafted systems in the long run.

Think of it like this: if a world model is a useful abstraction, the general learning system will create it by itself during its training, without us needing to implement it by hand. This is the bitter lesson. And it comes for us all.

If BEM is regular CSS, why would I use BEM instead of the actual thing? It's a layer of indirection for no reason if it's the same.

You use Tailwind in the same way you use BEM: becuase it makes it easier for frontend developers to write correct CSS.

Replace paper clips with data centers and we are already there…

If that is so, why are people getting up in arms about tailwind?

The poster I responded to, specifically asked for how to implement this in tailwind, with a worry about "do you really style each component separately for dark mode? Repeating the same modifiers over and over?"

I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.

That’s exactly how I’m doing this using tailwind and daisyui though, so I’m not sure what point you are trying to make?

My global tailwind.css defines two sets of css vars for the light and dark theme, and it all gets applied globally with a single line in my root html template. I don’t need to touch my markup. Tailwind simply compiles this down to a single css file in the end.

You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time.

That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.

All the evidence is against you here, sorry. Just read the google or microsoft security blogs, linux kernel mailing list, or any of the published security research about bug density in Rust vs C++.

Or you can bury your head in the sand while the rest of the industry is moving on, I guess.

It is obvious that you are just trolling, but for other readers: our production app went from 50-100 unexplained sentry errors in typescript to 0 sentry errors in rust.

The language absolutely helps fix logic errors.

It's something that becomes immediately clear as soon as you start using the language in earnest.

Fat services, thin routes. Try moving your business logic to a library and consume it from both your UI and API routes. That minimizes duplication and decouples your public API resolvers (with backwards compatibility requirements etc) from your private UI resolvers (which you want to evolve rapidly to optimize your UIX).

That's what we did and it works pretty well in practice.

Having used both in anger, I find d* has a lot of very real advantages over react if you care about performance and application stability.

It's simple enough that you don't need training or lengthy guides about "the rules of books etc".

It's small enough that an LLM can store the entire thing in context and answer your questions.

And it doesn't npm or a build step.

You either buy a datastar license to get their debug tools, or you spend a couple of hours to build your own. I'm sure you can find something on GitHub too.

One of the cool things is how extensible d* is. Everything is a plugin, and you are free to extend it to suite your needs. We've invested a few days building a few specific data-* attributes for our application and it's super convenient.

Our UI is highly interactive: think 3d visualizations with toggle-able overlays, various display settings, searchable lists, drawing tools etc.

We made a lot of progress with htmx, but eventually hit a complexity wall where we were spending more time fighting the tool than solving the business need. Note, I'm not blaming htmx here, the documentation is clear about its strengths and limitations, and the hypermedia approach is still fundamentally right. But even with alpinejs in the mix, we just weren't able to achieve the smooth developer experience we were looking for.

So we tried datastar, and it basically addressed all the friction points we had:

  - No more DOM hunting to figure out why the hx-get ended up in the wrong spot or why OOB swap is glitching out. D* morph just works.
  - No need for hidden form <input> to submit client state, D* signals are cleaner and easier to use.
  - No more micro-routes for targeted element updates to avoid hx-swap butchering page state. One route per page, just render the whole thing and morph takes care of the rest. Immediate-mode rendering and fat morphs removed ~50% of our routing table.
  - SSE + fat morph is a superpower. This is view = f(state) done right.

We've had very few issues, D* just works and gets out your way. The team has really created something quite exceptional.

The great news is htmx4 is adopting many of these ideas, so I recommend trying both and seeing what fits you best.

I highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs.

We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering.

First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, the browser doesn’t even flash - there’s no massive js bundle to parse, so it can start rendering instantly.

But the most staggering result is that in-document navigation over SSE achieves up to 5000:1 compression ratio for network requests within the Brotli compression window. Yes, 5000:1, you read that right. When changing server state we rerender the entire page, like an immediate-mode game engine, and push it to the client over an SSE “fat morph”, in about 100 bytes.

It’s so fast and so much more stable, our users are literally having fun. With a medical device.

And this ends up ~50% less code to maintain for a VASTLY superior UIX.

You are really missing out if you don’t learn how this works. It can give you a significant competitive edge if you care enough to try.

Edit: Big BIG thanks to bigskysoftware and the datastar team for making the web a sane place again. You really deserve all the props.

The Rust type system helps you catch logic errors at compile time. Same with Haskell or Ocaml.