> C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities.

C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).

> In general case code should be readable to anyone who is familiar with C language.

Most C++ already is? Even very template heavy C++.

> Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”.

A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.

> Don’t use exceptions.

Optional but irrelevant.

> Don’t use RTTI.

.. Why? Reimplementing RTTI in C will give you almost the same overhead.

> Don’t use C++ runtime wrapper for C runtime includes (, , etc.), use C runtime instead (, , etc.)

.. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include . Near 0 compiletime overhead?

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

This is a design decision.

> Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity.

There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.

> VCs think, 'Apps are risky, infrastructure is safe,' so they invested in AI infra.

First off, this isn't even infra in the infra sense of the word. Infrastructure implied something physical, a pure software product can almost never be considered 'infra'. A tool maybe, but not 'infra'.

VCs can also be irrational and driven primarily by personal connections rather than reason. I didn't do a deep dive in this project/leadership, but often who you know is some important than what you produced. There's a reason why a lot of VCs go for the old motto of "I'd rather invest in an A team with a C product; than invest in a C team with an A product".

I feel like this is really going to change the software industry moving forwards. Historically it was tedious and time consuming to actually develop tailored dev tools which is why so many organizations relied on third party solutions. When nowadays you can easily half bake something in a few hours and get it working, tailored _specifically_ to your needs.

Sorry, but most of these discussions reek of extreme gatekeeping. First off, neither of these things are impossibly difficult and are easily doable with some dedication by hand. LLMs simply accelerate the process, the human still has to come up with the architecture, _idea_ and plan to do something like this.

Do you have evidence that it's Claude written? Looking through the source it isn't clear to me, at all. Plus, even if it _was_ Claude/LLM assisted, why does that take away from the project?

would be something like

template void DoSomething (const T& ref) or void DoSomething(const T& ref, size_t numBytes) or C++20-y void DoSomething (const auto& ref)

If the class you're passing in already qualifies a size like member fn, template requires requires(T t){ t.size(); } void DoSomething(const T& x){ ... x.size(); }

> void DoSomething(const uint8_t* p, size_t numBytes)

This is awful you lose type info irreversibly.

> template void DoSomething(std::span data)

You can do this but the above examples work just as well.

> Or maybe something even more complicated, like this?

template void DoSomething(std::span data)

// Or this? template void DoSomething(std::span data)

This is more explicit, not more complicated...

> In this way, we still keep the clarity and simplicity of the function invocation: > DoSomething(&data, sizeof(data));

Stripping types is not a good idea, especially because you'll run into object lifetime issues _REALLY QUICKLY_. You need to guarantee that the object is trivially copyable.

I don't like the explicit split of Newtonian and relativistic gravity, this is often how it's presented in educational content, but it creates too much confusion; for instance it gives the illusion that they are somehow separate theories even though Newtonian gravity is a limiting case of Einsteinian gravity when v << c and gravitational fields are weak (see Poissons eq for Newtons gravitational potential.

Lastly, you should consider rendering spacetime similar to Alessandro Roussels spacetime visualization https://www.youtube.com/watch?v=wrwgIjBUYVc; probably the best and most innovative one I've seen.

The anti-LLM propaganda is getting ridiculous at this point. No project "needs 10GB" to compile, unless you're working with astronomically massive repos, and _no_ LLM will _ever_ generate that. Lint errors (depending on cause) are either meaningless or a result of poor prompt engineering. If you want your project linted/formatted a certain way make it clear to the LLM.