Earlier quoted context omitted.
> I'm not a fan of the C++26 linalg stuff. I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning. With C++26, anyone can simply jump into implementing algorithms. If anything, BLAS support was consp…
Except the devil is in the details as usual, the way linalg is specified doesn't guarantee numeric stability across library implementations or compilers. Just like the std::random mess, most people are in for a surprise when they attempt to write portable numeric code with it.
I think this criticism is silly. You're complaining about the C++ standard not enforcing something that is virtually impossible and no implementation under the sun even suggests it would conceivably support. And we should just assume C++ would be able to force it across implementations, target platforms, and even architectures? Ridiculous.
> Just like the std::random mess (...)
The comments I've seen regarding std::random mainly refer to gotchas, such as std::rand returning values in [0, RAND_MAX] and the latter being a platform-specific constant.
There is a reason after all why you only throw vague complains of "mess" instead of pointing out specific concerns or grievances. You need to complain, regardless of merit.
Overall, this blend of criticism is no different than the cliche criticism targeting the STL. Sure, some niche applications can and do have better ways to scratch their niche itches. In the meantime the STL perfectly serves the need of 99.9% of all common usages. Is this not the point? Doesn't linalg and rand achieve this?
Of course vapid nitpickers can still pull out the last resort card of complaining that the implementation is too complicated, a grievance also directed at the STL. But that's just the extent where this silliness goes.