> When an iPhone user is not identified as being at a familiar location

> equipping police with new powers to search properties without a warrant where stolen goods have been electronically located

> facial recognition to cut the number of grabs on the capital's streets

This all means total surveillance. What could possible go wrong with this?

That's the core feature of the language. Not using it doesn't make any sense.

> Don’t use stream (, , etc.), use printf style functions instead.

printf is type-unsafe and bug-prone. Also modern C++ standards have better formatting utilities.

> Don’t use anything from STL that allocates memory, unless you don’t care about memory management.

In 99.9% of the time one should not care. Using something like std::vector is perfectly fine.

Overall I find such "Orthodox" C++ harmful. I call it "pure C heresy".

With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.

You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice.

> single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification

It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.

WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.

  void DoSomething(
   _In_reads_bytes_(numBytes) const void * p,
   _In_ size_t numBytes );

I don't think someone used this approach in 1993. Textures were drawn by hand. But I think it's still fine to use such modern way of generating textures, since it may produce better-looking result.

I suggest to use not only darker variants, but also brighter ones - for bright map areas and maybe for some lighting effects like flashlight.

It's sad. That's why I never finished playing Wolfenstein 3D - it looks too boring. In the other hand I enjoy playing Doom, mods for it and games using its engine.

I hope the author can still add some improvements to allow such boring look typical for raycaster engines.

Creators of some keyboards placing a sleep button right above arrow keys didn't bother doing this.

> I feel like I sit along a different axis in the safe versus unsafe discourse

I can't believe someone can be neutral in this question. If you do actually write code in unsafe-languages, you are eventually forced to find a fix memory-related bugs and other bugs caused by their unsafety. Maybe you just don't need writing such low-level code and use some high-level language without direct memory access instead?

> what choices where made and why

In many cases there is no answer. My experience shows that many design decisions are made without thinking too long. One often just needs something to work right now rather than spending much time carefully designing each language feature. It's especially true for pretty-young language projects like Mach.

It's incorrect. In many programming languages there is a clear separation between safe and unsafe code - via special unsafe blocks or something similar. Languages without such separation are always unsafe or (rarely) always safe.

So, I assume Mach is fully unsafe, like C is.

Is it yet another LLM-generated project with little human-written code?

In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.