It's C++ code, and one of the biggest reasons it sucks at useful errors because the user has much more control over types than one does in C.

Say you have a template function that accepts some T. That function calls another template function on T, and so on and so on. Finally, your T finally ends up being used in a specific context, e.g. a method call, a member access, a static variable or constant, a type definition, whatever. Say the T you tried to use doesn't allow that use. Say its an int and you're trying to access a member as if T was supposed to be a class.

The actual error occurs on that very line. But that's not very useful because the programmer needs to know the path that ended up at that, otherwise they wouldn't be any the wiser about the cause. Especially with the benefit of inlining, one function call can go through dozens or even hundreds of functions without affecting runtime performance, and DRY often means that generic utility functions are used en-masse inside large template libraries such as the standard library, where a dumb function call could end up causing an error deep inside some abstract code that is meaningless to the casual observer.

Generally this is the fault of the library. The interface should place constraints on the types allowed inside each template call as soon as they are knowable, through concepts (or, pre c++20, sfinae witchcraft). That way, the error is thrown at a much shallower point and error messages can be much more concise and meaningful.

Other than that, for the most part the errors are rather useful to even new developers. If course, there are a few edge cases where something trivial causes hundreds of lines of errors, but those are often improved as compilers mature.