jandrewrogers

In the earliest days it required expensive GPUs to run well.

Dogs are smart, curious, and capable. They also understand boundaries. If you have a large property it is surprisingly difficult to prevent a motivated dog from leaving it. Some dogs have a strong desire to go on a walkabout on occasion. Chaining a farm dog defeats their purpose, and is arguably inhumane, so for some of them it just comes with the territory.

We had one dog growing up that liked to commune with a particular herd of cattle (in a friendly way) in a distant field on occasion, and nobody and nothing could stop it when it had that inclination. Dog on a mission.

In a lot of ways typical farm cats are more natural than dogs. The distance between those cats and the undomesticated variety isn’t that wide.

Most domesticated cats demonstrably have no issues thriving while feral. They are not well-adapted to every environment they’ve been introduced but they do pretty well in many. Their main issue in places like North America is prodigious predation in the wild, which is mitigated when living near humans.

Cats are a part of nature.

In some parts of the US outdoor cats are an essential bulwark against rodent invasion. It is healthy for the cats and very effective organic rodent control. They do get some birds but the bulk of their activity is rodents. There are places you can’t live without them.

Depending on the situation, outdoor cats can also live a long time. We had farm cats when I was growing up that spent a large part of their time outdoors during the day. They were smart, social, and typically lived 15-20 years before old age caught up with them.

Predation mostly impacts cats that are either obviously stupid or aggressively anti-social in my experience.

The state space of what you must check to ensure correctness in physical engineering is infinitesimal compared to ensuring correctness in software. Correctness in software is qualitatively more difficult by nature and an open problem at a theoretical level.

No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.

It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.

I have no issues with people check invariants at runtime. It is unavoidable. C++ contracts is a mediocre way of doing it. Many C++ code bases don’t use any macros at all for assertions and haven’t for a long time. Their models are much more nuanced than C++ contracts allows.

Why would anyone that already ditched C asserts use C++ contracts when it can’t express what the alternatives already can? This isn’t a new problem. People were creating more expressive assertion replacements than contracts offers a decade ago.

C++ contracts are nerfed. It is less expressive and capable than what anyone that cares about these things already uses. So who is expected to use it?

SIMD is often used to evaluate complex data structures in parallel. A common case is given a row with an arbitrary mix of data types and a query with an arbitrary mix of independent constraints on those data types, to evaluate all of the constraints in parallel in the same SIMD instruction(s).

The idea that SIMD is only good for parallelizing operations over arrays of the same type is empirically false and seriously understates the capabilities of good SIMD implementations. Some SQL-ish implementations work this way on row-structured data.

Most devs seriously underestimate what good SIMD is capable of.

The issue is that contracts are less flexible than the existing capabilities in practice, it is limited syntactic sugar.

Contracts were sold with the idea of aiding compile-time verification, a noble purpose. The combination of concepts + constexpr allows you to do deeper compile-time verification today by other means than contracts can check. It isn’t obvious that this will ever not be the case. This means contracts is relegated to being another flavor of C asserts.

C++26 contracts are arguably unnecessary because we can achieve the same results other ways, sometimes with stronger properties. I’m a proponent of features that clean up the syntax but C++ contracts look like a nod to people that still use legacy C asserts. That’s fine but it also perpetuates an inadequate model of what assertions should be capable of expressing.

People figured out how to do with C++20 better than what contracts promised.

I think you are right to position atomics and variadic templates as among the most consequential features of C++ in the last couple decades. It made an enormous number of things possible.

One thing I give the C++ feature gods credit for is recognizing material deficiencies in systems languages and unapologetically trying to fill those gaps starting with C++11. The addition of atomics, strict variadics, constexpr, lambdas, concepts, lifetime annotations, etc has been transformative for C++.

The subset of SIMD that translates is so narrow that it is almost useless in real code. That’s the problem. Additionally, it is invalid for the compiler to redesign your data structures.

The ability of compilers to use SIMD is no better than it was 20 years ago. Total stagnation for all practical purposes, and the reason is that compilers fundamentally lack the context and freedom to rewrite the code architecture appropriately for SIMD optimization (even if they could).

I think a point people miss is that highly optimized SIMD code is almost never about parallelizing loops. It is about deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types. SIMD allows you to do this, and it is fantastically efficient, but a compiler has no conceivable way of understanding this.

For this reason, SIMD optimization has often been classified as an AI-Complete problem in computer science.

Essentially all high-end systems code for high-performance and high-reliability systems is still written in modern C++. That language has many attractive properties, including safety features that Rust does not currently support.

Additionally, for pure performance requirements, C++ is still materially faster than Rust in practice. That may change some day. C++ has many issues but it is also objectively excellent at many things.

To be clear, I have a lot of issues with the contracts proposal. I probably wouldn’t use despite living out on the standards frontier. I don’t even use C asserts already because they are not expressive enough in important ways. This proposal kind of reifies the inadequacies.

I think the risk is that C++ contracts become an evolutionary dead-end that hang around forever in code bases because they were standardized. It wouldn’t be the first time this has happened.

SIMD cannot be solved at the compiler level. The capabilities of silicon SIMD implementations are fundamentally so disjoint that code using SIMD requires contextual and platform-specific data structures and algorithms.

SIMD on different silicon is incompatible at layers of abstraction far above the codegen manipulation a compiler can do.

That’s exactly my point.

Contracts notionally offer the ability to lift some runtime assertions to compile-time. That is how it was sold. Except they don’t in practice.

Meanwhile, concepts + constexpr if used artfully deliver that in practice, including for many cases that contracts were supposed to solve.

I push all verification to compile-time to the extent possible.

C++ concepts evaluate the properties of types at compile-time. You can inject arbitrary constraints on type properties anywhere in the code including conditional codegen. It is a way of asking if a type “can express this complex set of abstract things or has this enumerated set of properties” with almost arbitrary detail. They are extremely powerful in terms of expressiveness and specialization of code. Insanely good for performance and reliability engineering.

One of the best features to be added to C++ in many years.

C++ contracts are an attempt to bring C asserts into the C++ age. The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts. If you really care about this type of thing, you probably already have a custom C++ assertion framework that is at least as capable if not more.

The promise of C++ contracts is that they can aid formal verification, which would be great. As delivered, it can’t do much more than was already possible, which will inhibit adoption.

As someone who writes high-reliability C++ but is completely outside the standards process, I see the issues with C++ Contracts. It isn’t clear that it solves a problem that anyone has in real codebases, especially after C++20 concepts.

If you were already writing high-reliability C++ then the benefits are difficult to quantify. If you weren’t writing high-reliability C++ then it saves you almost nothing over doing the standard idioms of high-reliability C++ that were already available to you at very marginally more cost. It does standardize expression of it in narrow cases but the payoff seems minimal.

Most of what C++ Contracts delivers is a mashup of what you can already do with constexpr and C++20 Concepts. I like reliability features but this feature, as delivered, looks fairly useless if you already use reliability features. A compelling standard would need to make much deeper guarantees out of the box. And the compiler can already see through most compositions of constexpr and C++20 concepts, which is already very expressive.

C++ Contracts looks a bit like a feature that was designed long before current standard features existed.

The main consumers of electricity are industrial, not homes. Nothing we take for granted in a home would exist without those industrial supply chains, including data centers. The homes are downstream of continued investment in and expansion of the processes that actually consume most of the electricity.

The amount of water being discussed is utterly inconsequential to the food supply. 10s of trillions of liters of water are wasted growing subsidized corn alcohol in the US alone. Natural resources can be used for more than one thing without creating any issues.

By your reasoning everyone should stop bathing so that we don't starve to death.

> "The majority [of water] is used for big agro industries, such as soya, rice, and wood pulping. Now we have Google planning to use enormous quantities of water.”

This is like calling a rubber raft "enormous" after comparing it to an aircraft carrier. Agriculture consumes astronomically more water, often wastefully, for far less valuable purposes. I can't take these objections seriously.

This is just the latest weird moral panic.

The Iridium constellation(s) are very much in active use. They transitioned their business model from pure communications to RF remote sensing. They are among the leaders in some markets for RF remote sensing platforms. AFAIK the businesses in these markets do not use the Iridium name, which makes sense given it is a historical telecom brand.

That's Wyden as Wyden, not because he is a Democrat. Some of the strongest proponents of these intelligence authorities, and in many cases the literal authors of bills expanding these powers, have been leading Democrats e.g. Feinstein.

There is no credible version of history where Democrats as a party are not enthusiastic supporters of these surveillance powers. They've been actively complicit the entire time.

> Rust is a lot easier to make more performant than C++

I have never seen evidence of this in the wild. C++ is still significantly faster than Rust in practice when doing performance-sensitive parallel development in the two languages.

The reason for the performance gap is mostly understood. Rust's codegen is currently somewhat worse for a variety of reasons. Rust's much weaker compile-time metaprogramming features make some optimizations impractical in the language that are easy in C++. Culturally, "unsafe" minimization in Rust pessimizes code architecture.

Rust can get pretty close to C++ but it often requires writing some very ugly Rust.

Much of the difference in optimizability is that C/C++ allows you to do fairly extreme copy elision. This is important because memory bandwidth tends to be a major performance bottleneck.

C/C++ code can trivially reach into some remote bit of state and mutate it directly. The compiler rarely objects, no matter how ugly the access method or pattern. It is up to the programmer to make sure the invariants hold and the compiler can’t always see through it. These elided copies add up, though it usually has a maintainability and safety cost.

It is related to why functional languages tend to be mediocre for supercomputing in practice despite having nice properties for massive parallelism in theory.

> it has created a world where nuclear testing has ended

Or maybe not. China has been credibly accused of starting low-yield nuclear testing in 2020, specifically configured to evade detection, albeit unsuccessfully.

https://www.armscontrol.org/act/2026-03/news/us-accuses-chin...

> since it allocates memory for the coroutine state

Heap allocation is not required, just the default.

You can do static allocation if you wish, though it is a little more complicated than typical static allocation due to the relative unpredictability.

If the objective with using async is performance and scalability then you should almost always "bring your own runtime". Bringing your own runtime is the main reason you might want to use async.

Delegating the runtime nerfs many of the benefits that async can offer. If you are going to delegate the runtime it offers relatively little compared to just using threads.

A big part of modern guidance package cost is rejection of noise and countermeasures. This still requires an expensive sensor implementation even though a cheap camera would work well in ideal conditions.

You are mixing up your facts. Patriots are primarily being use against ballistic missiles, not Shahed drones.

Shahed type drones are killed with APKWS missiles. A single fighter jet can carry ~40 of these missiles and the unit cost is similar to a Shahed. APKWS has evolved a lot during its 15 years in use and the new generations are expected to come in around ~$10k each, cheaper than the drones they are designed to destroy. You can put an APKWS on many different things. The US annual production rate is 35,000 but that could be increased several-fold if needed (it is based on a missile of which the US produces 200,000 per year). The Europeans are working on their own version of this.

These have been used in the Middle East for a long time. Saudi Arabia, UAE, Qatar, and Israel all have orders for 10,000+ APKWS missiles each, so clearly they are effective.

The unit cost has been tipping toward the defender but the systems are not widely distributed yet. More effective defenses require more expensive drones e.g. you can't build an effective anti-ship missile (a type of jet-powered drone) for less than a couple million dollars because anything cheaper has too low of a probability of success.

The article is about the export of mined gold. The US produces ~160 tons of gold annually from domestic mining operations.

This article is kind of dramatic about describing a normal thing. Alpine highways everywhere in the world have to deal with this. The entire Mountain West is built for this, including some parts of California.

Maybe the Federal government has never bothered to invest in some aspects of road safety in Yosemite. That’s somewhat embarrassing. I’m surprised this is even an issue in Yosemite given how many other places have had this forever. Far more remote and unpopular highways have addressed this problem.

It is difficult to paint this as anything but incompetence.