Is the !dlang GC an issue for you as you're interfacing with your C and other non-D code?

There is the -betterC mode, which is still pretty limiting (but no more than writing in C?), but it's being worked on. More and more of the standard library is being made available.

https://dlang.org/blog/2017/08/23/d-as-a-better-c/

There are methods for separating your GC code and your non-GC code in different threads, and you can make sure certain code parts (and everything they call) are free of GC with the @nogc attribute.

There's also always the nuclear option of GC.disable. If you have safe points where you're not under scheduling pressure you can run GC.collect explicitly. I don't think there's a way to make the collection time bounded though, which would have been useful.

https://wiki.dlang.org/Memory_Management#Real_Time

Here's the start of a whole series on what to do about all this:

https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

> It can’t be repeated enough given how often it’s misunderstood: D’s GC will only have a chance to run when the programmer allocates GC memory and it will only run if it needs to. Use that knowledge to your advantage by keeping the allocations small, infrequent, and isolated outside your inner loops.