D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[ZombineDev via Digitalmars-d]

On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:
> Hi guys,
>
> I read from some of the other forum threads that D is being 
> criticized for not being usable for real time / low latency 
> systems because it has a GC.
>
> First of all, such system are already being written in Java. 
> Google "Martin Thompson" and LMAX and you will see. Or Aeron 
> (also Java and Martin Thompson).
>
> Second, when Java has been used to develop such systems, the GC 
> has been avoided as much as possible - which is even easier to 
> do with D than Java.
>
> So, it's a load of BS that D's GC should somehow make it 
> impossible to make real time / low latency software.

While developing a real-time system with a GC maybe possible, I 
think D makes things much easier by:
+ Having deterministic GC - the GC will only run if your code 
triggers it. If you don't want to use the GC, don't write code 
that triggers it.
+ Being usable without the GC - that way turning into a better C 
/ C++. You can manage all resources yourself, just like you would 
if you were using C/C++.
+ It's not that hard to write your own GC for D. The hard part is 
making it high-performance which is intrinsic to the problem 
domain and not to D specifically.
+ Another good strategy is to start with a GC and when you reach 
the point where you know (e.g. by profiling) where are your 
performance critical parts of your system you can rewrite them 
with high-performance D code (taking advantage of the 
understanding of the problem domain that you've gained in the 
process).
A general advice is to prefer free functions to OOP heirarchies, 
because OOP inheritance often leads to needles coupling. Use 
static polymorphism instead of dynamic dispatch, where possible. 
Often classical OOP polymorphism is unneeded. And in the few 
places where you need to take runtime decisions, switch 
statements are easier to debug. Reduce mutable shared state - 
ranges, functional programming and the 'shared' atrribute really 
help with that.

Bottom line is, if you are competent enough, you can be 
successfull with D, just like you would be if you were using 
C/C++. D's superior compile-time meta programming allows you to 
express zero cost abstractions give you the edge that makes 
things more enjoyable.

There are several open-source kernels written in D that are proof 
of the above:
https://github.com/Vild/PowerNex
https://github.com/Bloodmanovski/Trinix
https://github.com/xomboverlord/xomb
Adam Ruppe has a chapter about bare-metal programming with D in 
his Cookbook.