[OT] Unity's HPC#

[Ecstatic Coder]

On Wednesday, 27 February 2019 at 19:13:11 UTC, Nick Sabalausky 
(Abscissa) wrote:
> In the vein of keeping our eyes open to the world around us, I 
> found this article fascinating:
>
> https://blogs.unity3d.com/2019/02/26/on-dots-c-c/
>
> Being a high-performance game engine, Unity3D is right smack in 
> the middle of D's strengths and potential.
>
> Traditionally, Unity's core engine is written in C++ (just like 
> pretty much every other high-performance game engine), whereas 
> the game code is written in C# (which is first compiled down to 
> CLIR and then, depending on the target platform, either run 
> directly on Mono or further compiled down to C++/native.)
>
> They have the usual group of complaints about C++ (long 
> compilation, headers, and concurrency difficulties like races, 
> sharing etc). And they also add another C++ gripe we don't hear 
> about quite as often: Lack of guarantees and control over the 
> generated code. (VERY important for game engine developers, as 
> I'm sure Manu can attest.)
>
> So they have a rather interesting solution: They're switching 
> from C++ to a subset of C#, combined with some custom libs and 
> IL-based tooling. Sounds slightly odd, but they make a very 
> convincing case for it.
>
> I think it's very much in D's best interest to be aware of 
> these problems/solutions/rationales Unity presents here, as 
> they would easily apply to other C++ users and thus a key 
> potential audience for D.

As a professional game developer, I use Unity at work on a daily 
basis, so I know quite well the C# subset you are talking about.

And I must tell you that the main interest of this technology for 
Unity users is that it allows to implement the highly-optimized 
data-oriented parallelized parts of our code using a C-like 
close-to-the-metal language.

But definitely not in a C#-like fashion...

For instance, in my company, despite we mostly develop mobile 
games, most of our gameplay code is STILL based on Monobehaviour 
entities, because this C#-subset brings performance at the 
unfortunate price of a much higher verbosity and very low 
expressiveness.

This means that a MonoBehaviour-based 10-liner function will 
require 5 to 10 times more code for the same result in a very 
cryptic data-oriented C-like code. And btw you can also say 
goodbye to physics, networking, etc.

For games involving hundreds of game entities, this may be worth 
the effort, but for most games this isn't worth the effort.

So IMHO, it's much more urgent for D to try to close its gap with 
Go and Crystal by adding a fiber-based http capabilities in the 
standard library, that once again trying to make D become the 
ultimate C++ replacement, because to reach that goal you will 
need to reimplement all the D standard library using C++-like 
reference-counted memory management, which you won't, or loose 
it's current expressiveness and ease of use, which means 
targeting an even smaller development niche...