Regent actually sits on top of a C++ runtime library called Legion[1] that supports very similar abstractions (tasks, regions, dynamic discover of dependencies, etc.). Unlike most runtime libraries, Legion was intended from the beginning as both a compilation target, and as something users could write to directly. So we do actually have experience building it both ways.<p>The advantage that Regent has over a C++ library like Legion is that the language can embody the abstractions we want to provide. With C++, there is always an impedance mismatch between how we want people to think about programming, and what C++ forces us to do. C++ code is more verbose, and the C++ type system doesn&#x27;t capture all the invariants that the programming model requires.<p>Regent code is also a lot more amenable to static analysis. In Legion, if the system needs to know some property of the program, the user needs to supply that information. (And we&#x27;re forced to trust whatever the user says---there&#x27;s no reasonable way to statically analyze arbitrary C++ to validate what they&#x27;ve given us. At best, we can check those properties at runtime, but that isn&#x27;t always feasible either.) In Regent, many of these sorts of things can be analyzed automatically, reducing the number of moving parts users have to think about. This is only possible because we&#x27;ve thought very carefully about what abstractions we need in the language---the type system is already on the edge of what is decidable, so adding anything more would make analysis intractable.<p>To be sure, C++ has its advantages too. Some users will simply never accept a new language. So, that&#x27;s why we&#x27;re doing both. And for those who prefer to stick with C++, that&#x27;s always going to be an option.<p>[1]: <a href="http:&#x2F;&#x2F;legion.stanford.edu&#x2F;" rel="nofollow">http:&#x2F;&#x2F;legion.stanford.edu&#x2F;</a>