How does D compare to Go when it comes to C interop?

[John Colvin via Digitalmars-d]

On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda 
wrote:
> I read this post about the difficulties of using go/cgo to 
> interface with C code: 
> http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
>
> How does D do in comparison? specifically in regards to:
>
> 1. Call overhead (CGo is 100 times slower than native Go fn 
> call)
> 2. Memory management. (I guess D is not immune from having to 
> manage memory for the C functions it calls.. but is there a 
> difference in approach? is it safer in D?)
> 3. Cgorountes != goroutines (This one may not apply for D)
> 4. Static builds (how easy/straight-forward is this in D?)
> 5. Debugging (ease of accessing C parts when debugging)

1) No overhead, extern(C) in D means C ABI (although no inlining 
opportunities without LTO, so C -> C and D -> D calls can end up 
being faster in practice)
2) You can manipulate the C heap in D just the same as in C. 
GC-allocated memory in D being passed to C requires more care, 
but is normally not a problem.
3) Not applicable really.
4) D builds very similar to C, so you shouldn't see any problems 
here. Loading multiple D shared libraries can cause headaches 
and/or not work at all depending on platform.
5) Trivial. From the debuggers perspective it's all just 
functions, you might not even notice the language barrier. All D 
debuggers are also C debuggers and I doubt that's going to change.