Regent does also support loop auto-parallelization, though it's not the focus of the language and not generally how people write idiomatic Regent programs. Regent fundamentally is a task-based programming model. "Task" is a fancy word for a function that can run in parallel. The key is that (a) tasks execute with sequential semantics, and (b) inside of a task, you can do basically whatever you want. The compiler doesn't need to analyze the code aside from verifying that you're passing data around correctly. This means the set of programs you can write in the "nice" subset of the language is much, much larger. The vast majority of Regent programmers never encounter any explicitly parallel programming constructs, there is no way to make code that deadlocks or races, etc. On the other hand, organizing programs in terms of tasks does still take effort and a degree of cognitive shift. You still have to divide the program into parts that can be parallelized, even if you're not responsible for parallelizing them.
If by "industry" you mean in areas related to HPC, then Regent is likely to be applicable to what you want. The further you get away from HPC, the less likely that would be. You probably wouldn't use Regent to write a web server, though it's not impossible....
Right now my biggest item is making sure we support all the DOE supercomputers, which means adding support for Intel GPUs. (Regent currently supports NVIDIA and AMD.)
[1]: https://theory.stanford.edu/~aiken/LegionRetreat22/slides/ch...
I wonder if it would be possible to easily set it up on our university's HPC cluster (which is not a supercomputer, but still has SLURM and everything there).
https://legion.stanford.edu/pdfs/pygion2019.pdf
And code samples:
https://github.com/StanfordLegion/legion/tree/stable/binding...