C++ does give you a stack trace; you just need to set some things up before it does (namely, use a debugger). Rust does the same except it tells you what you need to do (set an environment variable).
You get this single-line error without enabling backtraces however. So the fact that this is now useful for the common case of "which line caused the error" is a pretty big deal.
Yeah for backtraces to work you also need to have debug info enabled which puts a major burden onto linking time. And once they are enabled, you have to scan the backtrace carefully to filter out the parts that are in the panic library. The line message is displayed prominently and thus allows for a much faster development cycle in finding the error.
Backtraces even without line numbers are still quite useful, as long as they have function names.
I mean, they're better than nothing. But they leave you guessing at exactly where the error is if you do similar operations more than once in your function. A line number is much better.
Offsets are occasionally more useful than line numbers, especially if you have multiple things on one line.
Just as a life tip (regardless of language): Without a line number you would get an offset, which you can use gdb or addr2line to go back to line numbers if you have the unstripped binary or debug symbols available (or the source, but that’s not necessarily deterministic).
There's backtrace_symbols, but to get decent info you need linker flag -rdynamic. I much prefer the stack traces from Rust, or Java (Apples to Oranges comparison there, as comparing a compiled language trace to one from interpreted language). For new projects needing a systems language in permissive environments I see no reason to go with anything other than Rust or Go, though there are other options that might be as good that I'm not familiar with. Unfortunately, there's a lot of legacy code (there are still people getting paid to maintain COBOL programs - not me though), and there are a number of restrictive environments where any technology newer than 8 years is a tough a sell.
To the extent that Go qualifies as "systems", OCaml or even Java would probably be a suitable option.
I know that. I'm trying to point at the difference between experiences without much tooling set up.