If you have really done physics or engineering, you would never believe this. Simple and elegant formulas usually can only solve the "spherical chicken in a perfect vacuum" kind of problems. The real world is incredibly messy. Beneath those clean and beautiful-looking partial differential equations lies a mathematical nightmare. And these equations often only hold at certain scales or rely on extremely strict boundary conditions.
Template metaprogramming isn't really suited for this task, the prime sieve here serves only as a proof of concept, meant to show the capabilities of this style. But there are cases where `constexpr` is not applicable, especially when involving type manipulations.
On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
We have seen similar situations countless times before. Just as the Internet allowed people to bypass publishers to release text, and YouTube allowed creators to bypass TV stations and cinemas to release video, AI now allows people to bypass lawyers to read legal texts, which are often deliberately written to be indecipherable to an average person. AI will not destroy institutions, but it will pose challenges and lead to restructuring.
I don't want a Rust language without a borrow checker. I want a C language with a Borrow Checker. Rust's complexity is already approaching C++, and removing the Borrow Checker would turn it into a similar disaster. Austral looks like a good option to me, but it's not mature enough yet, and the Pascal-like syntax is also difficult to get used to.
Although it's a toy not for production, it's very interesting that the idea of traits/concept/typeclass just "emerge" out of the code, which made me suddenly understand why STL come into being.
It's very dangerous to write a http parser from scratch in C. This can be very vulnerable without rigorous testing. To get a useful web framework for production in C, I think it's a better idea to start from libmicrohttpd, libevent_http, or even fastcgi, which are battle-tested.
No, the acos() call is not expensive at all. There is hardware acceleration.We can calculate acos() with in 12 CPU instructions.
https://git.musl-libc.org/cgit/musl/tree/src/math/i386/acos....