This is more likely the actual incident report:

A change made to how Cloudflare's Web Application Firewall parses requests caused Cloudflare's network to be unavailable for several minutes this morning. This was not an attack; the change was deployed by our team to help mitigate the industry-wide vulnerability disclosed this week in React Server Components. We will share more information as we have it today.

Edit: If you like reading

That title should be illegal lol.

Congrats to everyone who made this possible!

1500 tests is a lot. That doesn't mean anything if the tests aren't testing the right thing.

My experience was that it generates tests for the sake of generating them. Some are good. Many are useless. Without a good understanding of what it's generating, you have no way of knowing which are good and which are useless.

It ended up being faster for me to just learn the testing libraries and write my own tests. That way I was sure every test served a purpose and tested the right thing.

Weird cutoff on the title. This is the full sentence:

Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure.

I'm interested to see how this goes. Maybe they could work with the gitoxide devs to see if there's some work that's already been done.

Not really sure myself if Git needs to be RiiR, but that's their call to make I guess.

Localization is a hard problem, but storing your translations in the DB is a bit unusual unless you're trying to translate user data or something.

I'd recommend looking into tools like Project Fluent or similar that are designed around translating.

As for the schema you have, if you're sticking with it, I would change the language into an IETF language tag or similar instead. The important part is that it separates language variants. For example, US English and British (or international) English have differences, Brazilian Portuguese and Portugal Portuguese have differences, Mexican Spanish and Spain Spanish have differences, etc.

Using an ID instead of the text content itself as part of the PK should be a no-brainer. Languages evolve over time, and translations change. PKs should not. Your choice of PK = (TextContentId, Language) is the most reasonable to me, though I still think that translations should live as assets to your application instead to better integrate with existing localization tools.

One last thing: people tend to believe that translating is enough to localize. It is not. For example, RTL languages often swap the entire UI direction to RTL, not just the text direction. Also, different cultures sometimes use different colors and icons than each other.

There is some irony in heapless::BinaryHeap.

Cool library though.

But this case is bigger than JavaScript. It’s about whether trademark law works as written, or whether billion-dollar corporations can ignore the rule that trademarks cannot be generic or abandoned. “JavaScript” is obviously both. If Oracle wins anyway, it undermines the integrity of the whole system.

If the law costs $200k to enforce, then the law already doesn't work as written.

Anyway, good luck Deno! We're all hoping you win this.

By which I mean maybe the author enjoys different parts of coding than you do.

It seems to me like the part of coding the author enjoys least is coding.

Trying to wrangle AI into writing something decent is generally an exercise in frustration for me.

This is my issue with it. The output of these tools, unchecked, evolves into something abysmal over time. I find it quicker to just rewrite the output than to try to prompt it over and over again to produce something good.

The conclusion of this experiment is objectively wrong when generalized. At work, to my disappointment, we have been trying for years to make this work, and it has been failure after failure (and I wish we'd just stop, but eventually we moved to more useful stuff like building tools adjacent to the problem, which is honestly the only reason I stuck around).

There are a couple reasons why this problem cannot succeed:

1. The outputs of LLMs are nondeterministic. Most problems require determinism. For example, REST API standards require idempotency from some kinds of requests, and a LLM without a fixed seed and a temperature of 0 will return different responses at least some of the time.
2. Most real-world problems are not simple input-output machines. When calling, let's say for example, an API to post a message to Lemmy, that endpoint does a lot of work. It needs to store the message in the darabase, federate the message, and verify that the message is safe. It also needs to validate the user's credential before all of this, and it needs to record telemetry for observability purposes. LLMs are not able to do all this. They might, if you're really lucky, be able to generate code that does this, but a single LLM call can't do it by itself.
3. Some real world problems operate on unbounded input sizes. Context sizes are constrained and as currently designed cannot handle unbounded inputs. See signal processing for an example of this, and for an example of a problem a LLM cannot solve because it cannot receive the input.
4. LLM outputs cannot be deterministically improved. You can make changes to prompts and so on but the output will not monotonically improve when doing this. Improving one result often means sacrificing another result.
5. The kinds of models you want to run are not in your control. Using Claude? K Anthropic updated the model and now your outputs all changed and you need to update your prompts again. This fucked us over many times.

The list keeps going on. My suggestion? Just don't. You'll spend less time implementing the thing than trying to get an LLM to do it. You'll save operating expenses. You'll be less of an asshole.

Browsers have supported the javascript: scheme for a long time, so I guess it just abuses that.

This doesn't represent the mutual exclusivity through the type system (which is what the article is all about).

I love clap and I use it a lot, but the only way to represent the exclusivity through the type system in Rust is through an enum.

The high-level directory structure looks reasonable, but every language and build tool has its own recommended structure that people should use instead. For example, by default, cargo looks for a src/main.rs or src/lib.rs as an entrypoint. uv expects one of a couple different project structures before you need to touch the pyproject.toml. C# will create namespaces for each of these nested subdirectories if you don't carefully configure it in your .csproj file. And so on.

It's best to just use whatever's recommended for your environment by your tools. Maybe this directory structure works well for Guile Scheme, but I wouldn't touch it at all if I were writing Rust.

Because if it never returns, then it has no return value.

Then how would you annotate having no return value?

A lot of code doesn't really care where the error came from. This can be useful when using anyhow in application code, for example.

For library code, I don't see myself really using it, so it'll live next to all the other functions I don't use there I guess.

I was able to turn the string into a char iterator, but I could not figure out how to change elements of said iterator (this can be seen at line 55).

You have a few options here, but the easiest is to collect into a Vec<char>, replace the character there, then do a String::from_iter(chars) to get it back as a string.

You can also manipulate the original chars iterator directly through takes, skips, and so on and collect it into a string, but that's more complicated.

Also, "character" is such a complicated concept because unicode is not simple. If you can work directly with bytes though, you can convert the string to a Vec<u8> (which is the underlying type for String), manipulate that directly, then do String::from_utf8 (or the same method for str) to convert it back to a string.

I am interested to see if these tools can be used to tackle tech debt, as often the argument for not addressing tech debt is a lack of time, or if they would just contribute it to it, even with thorough instructions and guardrails.

From my experience working with people who use them heavily, they introduce new ways of accumulating tech debt. Those projects usually end up having essays of feature spec docs, prompts, state files (all in prose of course), etc. Those files are anywhere from hundreds to thousands of lines long, and there's a lot of them. There's no way anybody is spending hours reading through enough markdown to fill twenty encyclopedia-sized books just to make sure it's all up-to-date. At least, I can promise that I won't be doing it, nor will anyone I know (including those using AI this way).

I think the devs have already been made aware, but warp is also the name of a well known web framework for Rust.

My job has AI usage as an objective as well. It's ridiculous. If a tool will make my job easier, then I'll be the one to tell you, and I'll be the first person advocating for it. The people in charge aren't doing my job, so they can fuck off with the micromanagement.

Mentioned this to the other commenter, but this doesn't use the type system to enforce the mutual exclusivity constraint. In Rust, the main way to do that via the type system is through enums.

I mean, I find TypeScript fun to write. The only thing I really dislike about it is configuring the tools (tsc, eslint, etc). It's a great language when everything's setup and you disallow all the ugly JSisms with your linter and tsc.