D doesn't do it very well. Carbon doesn't require you to write your own interface. There's also problems with extern(C++) not correctly generating the appropriate assembly. Lots of ABI bugs as it's rolling it's own implementation instead of using LLVM.

I love when people bring up that UE has a GC, if it was written in Java, do you think they would have built a GC on top of Java's GC?

I guess it depends on the GC at that point, 20 mallocs isn't a lot but like the GC in D, it pauses all threads to do it's collection when you allocate. There's also a few games that use C# that have a really bad stutter because of the GC. There's nothing they can do about that though.

There's no "nogc" containers in phobos, or allocators, or an idiomatic way to do safe manual memory management. It expects you to do it the C way. It's also impossible to implement some things because of how D does moving. There's a DIP in the works to change how moving works, but it's overly complicated and bound to introduce even more bugs. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md