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)

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.

On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
> On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda wrote:

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


> 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.

I was going to say the exact same thing, but I do think it's worth putting some emphasis on "more care" here. It's true that it normally is not a problem, but it's precisely the abnormal cases that you will miss when you aren't paying attention.

On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
> On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda wrote:
>> 5. Debugging (ease of accessing C parts when debugging)
> 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.

To add to this, as long as you're on anything but OS X, you're fine. Debugging D on OS X is, to put it plainly, fucked.

On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer wrote:
> On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
>> On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda wrote:
>>> 5. Debugging (ease of accessing C parts when debugging)
>> 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.
>
> To add to this, as long as you're on anything but OS X, you're fine. Debugging D on OS X is, to put it plainly, fucked.

Never had any real problems with it, but I don't expect much from my debuggers. Breakpoint, backtrace, disassemble, register dump. Maybe some stepping about once a year.

On Thursday, 10 December 2015 at 15:18:18 UTC, John Colvin wrote:
> On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer wrote:
>> On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
>>> On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda wrote:
>>>> 5. Debugging (ease of accessing C parts when debugging)
>>> 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.
>>
>> To add to this, as long as you're on anything but OS X, you're fine. Debugging D on OS X is, to put it plainly, fucked.
>
> Never had any real problems with it, but I don't expect much from my debuggers. Breakpoint, backtrace, disassemble, register dump. Maybe some stepping about once a year.

https://issues.dlang.org/show_bug.cgi?id=14927

If you've gotten GDB on OS X to work, please let me know. Trying to debug NULL pointer bugs without a debugger is like breaking down a wall by smashing your head into it over and over.

On Thursday, 10 December 2015 at 15:29:46 UTC, Jack Stouffer wrote:
> On Thursday, 10 December 2015 at 15:18:18 UTC, John Colvin wrote:
>> On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer wrote:
>>> On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
>>>> On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda wrote:
>>>>> 5. Debugging (ease of accessing C parts when debugging)
>>>> 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.
>>>
>>> To add to this, as long as you're on anything but OS X, you're fine. Debugging D on OS X is, to put it plainly, fucked.
>>
>> Never had any real problems with it, but I don't expect much from my debuggers. Breakpoint, backtrace, disassemble, register dump. Maybe some stepping about once a year.
>
> https://issues.dlang.org/show_bug.cgi?id=14927
>
> If you've gotten GDB on OS X to work, please let me know. Trying to debug NULL pointer bugs without a debugger is like breaking down a wall by smashing your head into it over and over.

When I hit problems like that I swap to llldb. Much less D support, but it works well enough for my limited needs. I don't mind looking at mangled names most of the time.

Still, it should definitely be fixed, I understand that other people have different needs/workflows.

On Thu, 10 Dec 2015 13:33:07 +0000, 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)

C calls use the C calling convention. That's the only runtime difference. The C calling convention is fast, of course, and D's is comparable.

From what you're saying about Go, it sounds like someone implemented the C calling convention at runtime. A few years ago (circa 2008, I think?), I implemented something like this in D (call a function with a series of boxed values, specifically). It was about 150 times slower than just calling the function directly in my brief tests.

You can use packed C structs in D, which is one thing that cgo doesn't allow.

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

For C interop?

You can allocate memory in D and pass it to C functions. This requires some caution. If you send a pointer to a C function that allocates memory on the heap and stores that pointer in that memory, the GC doesn't know about that.

If you are writing the code on both sides, you can forbid that pattern. If you are uncertain, you can hold a reference to anything you pass to C code until you know it's safe to discard it.

Finally, if the C code takes ownership of the pointer (and expects to be able to realloc / free it), you must use malloc. realloc and free may well crash if you try to realloc pointers they don't know about.

If you're using D and not calling C functions, you can easily write memory-safe code, and there's a garbage collector to boot.

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

On the other hand, coroutines are coroutines, and D has a coroutine implementation (core.thread.Fiber).

In Go, all IO is tightly integrated with the coroutine scheduler. The reason it requires caution to use C from Go is that, if you perform a blocking operation, your entire program will block, unlike what happens if you use Go IO functions.

If you are using vibe.d, you have a similar IO model and need similar caution. That's about it, I think. Since you can call D from C/C++, you can implement coroutine-aware code in C that will yield at the appropriate places.

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

DUB, the D build and dependency tool, produces static libraries by default.

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)

Some reading:

https://dlang.org/spec/interfaceToC.html
http://wiki.dlang.org/D_binding_for_C

On Thursday, 10 December 2015 at 17:16:43 UTC, Gary Willoughby wrote:
>
> Some reading:
>
> https://dlang.org/spec/interfaceToC.html
> http://wiki.dlang.org/D_binding_for_C

I can't recall if Ali's book has a section on this, but I'm not a fan of those links.