Panzerschrek

That's why I do such things in my language in a different way. Optional and union types are just library container classes. More methods may be added if necessary, internal layout may be changed, etc. without changing the language core itself. But in such an approach the language itself should provide necessary means allowing creation of such library abstractions.

  var value = maybeValue.notNil // I know what I'm doing

It's not true for typical use-cases, when objects aren't processed one by one, but in bulk.

> Next, you have type bloat

What's the problem? Do you pay a special tax each time you need create a new type?

> Prepare for a lot of this

That's not how it's done in C++. You typically have a template for handle types, so that PlayerHandle is just Handle<Player>.

> Handles are also a lot bigger.

The article mentions, that handles are typically smaller than pointers. A pointer is 8 bytes (on 64-bit machines), but handles can be smaller if not so many objects are needed to be created.

> Next, you have the issue of resizing your memory array.

There is only problematic to resize it down, which is almost never needed.

> dozens of arrays

> manage the lifespans and scope of all these object pools

It's not a problem. Each subsystem owns its arrays and destroys them only when the subsystem itself is destroyed.

Knowing that Github is owned by Microsoft, they probably are fine with it.

But I agree, that using an "AI" tool may be a serious temptation and thus way less new porting projects will be done with such care.

Is there such thing as "community" at all? As I know, the majority of open-source projects are developed by a single person, where others only contribute bug reports (in best case). It's not a community, if there is such imbalance in contribution and power.

Only a handful of projects (a small percentage) has actual community with many members doing meaningful contribution. But they are most notable ones, so that one may think, that all open-source projects function like this.

  for( size_t i_plus_one = count; i_plus_one > 0; --i_plus_one )
  {
      const size_t i= i_plus_one - 1;
      // actual loop code
  }

This sounds too easy to be true. As I understand, that's the core of the whole approach - to find a table filled with some magic values giving perfect hashing. And it shouldn't be that simple, since search space is huge (a table with 256-values each with 8 bits size at least).

I doubt this can work well in all cases. Sooner or later one needs proper heap.

C++ is a good example of this. It had duck-typing in templates for decades. Then some sort of trait-like mechanism named concepts has been introduced. The only benefit of them seems to be slightly better error messages if someone misuses a template class/function.

   if ($LastExitCode -ne 0)

It's a bad advice. It's preferred instead to have a connect function returning a database instance in a successful case or an error otherwise.

I can add more:

Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior, Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.

In such case stack-like allocator isn't the best strategy. One can use some sort of cyclic allocator instead. As I know Quake did this for surfaces cache.