Not GP, but IME researchers often run big, complex simulations, and often have to care deeply about performance. Correctness, less so, unfortunately. A lot of research software is written by researchers themselves with very little understanding of good software development principles and practices, and end up messy, overly complex, and buggy. That said, being a software developer within research can be the best of both worlds. You should be able to demonstrate (using perf tools, and comparing with existing comparable software) that you're squeezing a lot out of the hardware, while being able to construct maintainable, tested software.
The only one I have hands-on experience with is financial trading. My workplace is expanding into a new asset class and we're using Haskell for this. The company next door from us is a crypto-trading company using Rust.
I can only speculate about other sectors where it might make sense:
- Hardware synthesis (i.e. the software used to design silicon chips);
- Aerospace;
- Defense;
- Smart city devices;
Not PP, but I used to work for an automotive subcontractor company, and I've heard a few stories about fatal car accidents that lead to lawsuits, which proved that the car design was the reason for the accident, yet the car manufacturer just payed "damages" to the relatives (or settled out of court, maybe) and never bothered to change the design. Apparently, it was more expensive to reconfigure their production pipelines than pay for an occasional death.
That said, this is probably what any big enough company would do. So your point still stands, maybe car manufacturers are no different.
