A human will still be needed to review the AI generated PR, no?

I never had similar bug caused by hardware or compiler issue. But I had cases where I thought it could be the compiler.

This article shows that those cases are possible, even though they are very rare.

Which book is presented in the article?

Do AI really write better React/JSX than devs?

Yes, and it’s almost instantaneous. You just have to check that the output achieves the prompt.

This is why some people are concerned and some have nothing to worry about. A machine can replace a street sweeper, because pushing a broom is a low skill task. The kinds of people that design or drive street sweeping machines are not the people replaced.

Then why is there a need for a developer, that supposedly writes poorer code, to check it?

The article is not only about security. Thanks

Agreed. Beyond security, we must consider other critical factors such as cost, ease of maintenance, and operational overhead.

I wrote this because I kept seeing developers (myself included) confuse language-level isolation like Python venv with OS-level isolation like Docker. I wanted to trace the actual technical boundaries between them.

The article maps out the differences between common execution environments—from physical bare metal and VMs to containers, process sandboxes, and virtual environments—to create a mental model of where the "isolation boundary" actually sits for each tool.

Since you mention serverless it might be worth mentioning firecracker and v8 isolates.

Or CGIs running on httpd inside HP-UX Vaults, that is how old the idea happens to be.

> how old the idea happens to be

TFA is missing a host of many a popular isolation techniques like Isolates, Code Interp / Binary Translators [0], Enclaves, Exclaves, Domains/Worlds, (RISC V) SEEs, TEEs, SEs, HSMs, pKVMs ...

[0] https://news.ycombinator.com/item?id=38950949

Thank you for the feedback. I will definitely add them as example solutions for serverless.

>1. Physical Machine (Bare Metal) This is the foundation.

Nobody should ever forget this.

But I would say this next part is about the opposite for bare metal though:

>Use Case: High-performance computing (HPC), large databases, or legacy systems that require direct hardware access.

To get the utmost reliability out of adequate hardware then bare metal is more suitable for almost everything except for special situations.

Unless something is really wrong with the software or the overall hardware/software approach.

Thanks for the feedback. These are typical use cases where the convenience of higher level abstractions may be less important than the benefits of direct access to the hardware.

Did you really write it though? Within the first paragraph it's fairly obvious this is heavily LLM-generated.

It also has weird definitions. Is nix a virtual environment? Is homebrew a virtual environment? Why is a sandbox different to a container? Type-1 vs Type-2 hypervisors are quite different, and there's no discussion about processes vs threads.

I don't know what it is about LLM-generated text, but when I read it I cannot understand the meaning it is trying to convey. The words are all there, but it is fatiguing to repeatedly parse phrasing like "it's not X but Y" and "you aren't just X, you are Y". The entire article is organized as a sequence of these statements, and this is not hyperbole.

Because it is statistical. It has no understanding of the purpose of writing which is to convey information. It can only show you the statistically most likely text, although very good sometimes, it also has its limitations.

Great article! Thank you for sharing. Could these same strategies be applied to C programs?

C++ Has changed so much since C++11. It feels like it is picking features from every other language

I am curious to know what was the contribution of switching to FlatBuffers in that improvement.

FlatBuffers was definitely the majority of the improvements here!

On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.

Insightful. Many thanks.

Flat buffers is know to bloat client code. Was any trick used to mitigate that?

I guess code bloat is proportional to schema complexity, and performance improvement is proportional to volume, so in ad blocker with many large block lists the latter dominates.

The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.