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

[deadalnix 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)

No overhead. The only limitation is that you won't have inlining 
between C and D, otherwize it is a direct call, just the same as 
calling a C function from C.

> 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?)

You got to be carefull not putting pointer GC managed memory in 
the C heap. Otherwize, because of 1, you can just call malloc and 
free the way C does and with the same effect/perfs.

> 3. Cgorountes != goroutines (This one may not apply for D)

I don't know much about these.

> 4. Static builds (how easy/straight-forward is this in D?)

D and C use a similar compilation model. You can link both 
together without much trouble.

> 5. Debugging (ease of accessing C parts when debugging)

If the C part is compiled with debug information you'll get 
everything a C debugger can give you. For the D part, support 
tend to be not as good but is fairly decent, especially using 
GDB. It's difficult to assert if it will do for you, but it does 
enough for what I do with a debugger.