I stopped reading after I saw the bullet point stating Zig doesn't have undefined behavior.

Hahaha that's where I stopped too.

> One database query took longer than expected. That blocked an async task. Which held up the executor.

This only happens if you're using blocking code in the event loop, right? This article seems like an admission of over-engineering from the get go.

I don't believe so. It is however shared on sourcehut.

> ...and it still results in cache-miss, even when the request comes from the same location and edge.

I'm sure they have multiple data centers in each location. Especially if it's a high traffic interconnect.

I think the point they are making is that Cloudflare makes no guarantees that it will cache your content (vs Akamai that you can purchase a specified storage and expect that it will get used).

I'm failing to see how this could have as much or more utility than a Tacoma. I don't see any mention of towing or payload. Not to mention, the clearance will be limiting for anyone who wants to venture off road at all.

Payload's around 1700-2000 pounds, TBD.

Towing is possible but limited-- this is a weak point for all electric vehicles-- but good enough to haul a trailer to the dump or a boat a small distance.

But the bed is better in some ways than the Tacoma.

Big question is whether they can reach production and really deliver for this pricing, etc. They have ~11k preorders and could develop a lot more.

Appears to be a separate incident: https://news.ycombinator.com/item?id=44261064

Two big cloud provider outages at the same time? Has to be related surely.

Reading the latest stable documentation [0], it appears that you have to use async?

[0]: https://rocket.rs/guide/v0.5/upgrading/#stable-and-async-sup...

Sorry, so you can use synchronous functions for writing middleware and routes, but the rocket core does use tokio.

Not all async Rust webframeworks let you do away with async and futures entirely in your business logic.

So the caveat is you need to call `spawn_blocking` with synchronous functions. I see.

With a framework like Axum, yes, but with Rocket, no - you can just declare synchronous functions and pass them as a route handler, e.g.: https://github.com/Qwuke/recurse-ring/blob/main/src/main.rs#...

If you're averse to touching async fn's or tokio APIs _at all_, it's nice devex.

I don't know much about what an Amish lifestyle entails but I have to imagine their limited or non-existent exposure to modern carcinogens helps as well. I think of all the awful things I've been around only to learn later it could adversely affect my health.

Or maybe the cases just aren't recorded.

Deaths are always recorded, though. And Amish men live longer than non-Amish men, indicating that they are overall healthier.

The Amish are also overall happier. Maybe that contributes to the longer life?

Where would one even start learning more about front-end development in today's world? Ignoring the dizzying amount of frameworks, how could I become knowledgeable enough to connect my back-end experience to design the "full stack?"

I think truly full stack is probably too much to ask: just accessibility is a huge area of knowledge, for example. I can fiddle around with back-ends, but I want someone more experienced to check my work or just directly help out with e.g. scaling or observability.

That said, if you truly want to learn, MDN is the reference, and they have a pretty good curriculum too: https://developer.mozilla.org/en-US/curriculum/

Also, ignore the dizzying amount of frameworks. Learn web technologies, and then React. There are millions of back-end tools as well, but in practice, you only use a limited set. Front-end is the same.

The minimum to be a broadly employable frontend dev is to have knowledge HTML + CSS + JavaScript/TypeScript + React/Vue.

Svelte is pretty niche. I'm not saying you shouldn't learn it, but that you should focus on the common tools first. This is just like you might tell a friend learning programming to learn Java/Python/Go etc. before getting into Lisp/Haskell/Prolog.

All are useful and have their place, but one set of languages is definitely more likely to be used in a workplace (unless you're lucky!).

If you want my opinion on a cool/trendy framework to use, I really like Astro [0], but, again, I doubt anyone will hire you unless you also have experience in React/similar.

[0]: https://astro.build/

Would you use Astro for other type of sites apart from static ones?

I'm not sure if I understand well its use case. It's not for cases when there's complex backend logic, right? What other technologies can be replaced by Astro, to have an example?

Astro is _really_ great for static sites. It doesn't feel heavy like Gatsby and Hugo do. I understand what's going on and I get to write JSX that compiles to static HTML.

> What other technologies can be replaced by Astro, to have an example?

As I mentioned above, and you hit on this too, I think Astro can replace static site generators. It wouldn't replace React (or your favorite framework), but it would use those frameworks to reduce your overall reliance on JavaScript and let most of your site be static HTML.

Astro has "island" pattern which allows you to selectively use JS frameworks on portions of pages where interactivity is required. You can use React, Vue, Svelte, etc.

The big benefit of islands is that the majority of your site is static HTML and only the bits of each page that actually need JS rely on it vs React where your entire site would use JS.

I haven't used this feature but I have heard that people really like it.

https://docs.astro.build/en/concepts/islands/

Play around with some stuff and see what works for you best. Personally, I didn’t get frontend at all before React came by, and then switched to Svelte because it fits my mental model exactly.

If you don’t like anything – no worries! Classic SSR with templates and stuff is a thing too, as another commenter pointed out.

Edit: no matter what, make sure you write good HTML first and foremost. Use proper semantic tags, don’t add dozens of nested divs, use native controls when possible etc. Make sure to check accessibility, but it should be OK if you don’t do any weird stuff. MDN is a great starting point.

I just ignore the whole “frontend stack”. I would suggest to stick with traditional server side rendering and for interactivity use htmx/alpinejs.

Pick a stack and dive into it. If you find yourself getting analysis paralysis, just pick one arbitrarily; you're not getting married, you're just getting started. Make things and get feedback on them.

At the end of that process you'll have the background to reevaluate your decisions.

I am an amateur but the reason I love React is because there is so much learning material. Robin Wieruch's The Road To Learn React book started with building a HN reader.

I think Claude/ChatGPT works exceptionally well with React code.

I tried to learn Svelte but React/Tailwind plus a language model is just incredible.

Much React hate I think is the way I view the band Metallica. They were way cooler in my head when they were not as popular.

React is still the most popular framework by a good margin. If your goal is to find work I'd start there, love it or not.

Just write Vanilla JS honestly. It's probably enough

Just choose one.

I would love to see a blog post or more detail about how this implementation works and why it can beat rayon in some cases.

The README of Spice has detailed explanation of the approach: https://github.com/judofyr/spice

This previous discussion of Spice on HN may help a bit: https://news.ycombinator.com/item?id=41230344