On Tuesday, 10 November 2015 at 00:43:48 UTC, Andrei Alexandrescu wrote:
>> One correction - AFAIK Rust also does have native C interop via
>> https://doc.rust-lang.org/book/ffi.html
>> Convenience / syntax / style aside actual capabilities seem to be on
>> part with D.
>
> I was aware of that, and convenience, syntax, and style are not to be discounted. -- Andrei

Sure, I simply wanted to point that this bit can be noticed as somewhat more arguable by outsider in otherwise very honest and precise answer.

On Wednesday, 11 November 2015 at 12:22:24 UTC, Walter Bright wrote:
> On 11/9/2015 3:11 PM, Vladimir Panteleev wrote:
>> Great post, though languages that compile to C (e.g. Nim) are probably even
>> better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
>
> I'd like to know of any language (other than C++ and O-C) that does a better job interfacing to C and C++. How does Nim do any part of it better?

Nim does everything according to their marketing department. The engineering department remains to be found.

On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
> On Wednesday, 11 November 2015 at 12:22:24 UTC, Walter Bright wrote:
>> On 11/9/2015 3:11 PM, Vladimir Panteleev wrote:
>>> Great post, though languages that compile to C (e.g. Nim) are probably even
>>> better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
>>
>> I'd like to know of any language (other than C++ and O-C) that does a better job interfacing to C and C++. How does Nim do any part of it better?
>
> Nim does everything according to their marketing department. The engineering department remains to be found.

Please elaborate. I'm all ears.

On Wednesday, 11 November 2015 at 19:54:16 UTC, Chris wrote:
>> Nim does everything according to their marketing department. The engineering department remains to be found.
>
> Please elaborate. I'm all ears.

There is not much to be said really. Many doubtful decision like compiling to C (Walter made a very clear sum up of why it is a terrible idea, I'm in agreement with him) and generally, I haven't read anything that really pushed to try it. It is always grandiloquent sounding but with very little meaning statement.

It as a "friendly syntax", it has a "real time GC", it has "static typing", and so on. That's PR buzzword, not what I, as an engineer, am interested in.

On Thursday, 12 November 2015 at 08:30:35 UTC, deadalnix wrote:
> On Wednesday, 11 November 2015 at 19:54:16 UTC, Chris wrote:
>>> Nim does everything according to their marketing department. The engineering department remains to be found.
>>
>> Please elaborate. I'm all ears.
>
> There is not much to be said really. Many doubtful decision like compiling to C (Walter made a very clear sum up of why it is a terrible idea

It is the most common target for new languages. It limits language semantics, but it is a proven approach for new languages. You get a lot for free when making C your first target. Including asm.js.

I haven't tried Nim yet, as they are in early stages, but it looks interesting. I also see that they have pure Obj-C ref counting on the roadmap.

On Wednesday, 11 November 2015 at 10:49:02 UTC, Ola Fosheim Grøstad wrote:
> I wish you would streamline template definitions even more in D, though.

What were you thinking?

On Wednesday, 11 November 2015 at 12:19:40 UTC, Walter Bright wrote:
> On 11/9/2015 3:26 PM, deadalnix wrote:
>
> I've looked into generating C code as an output format. I found the problems to be endemic and working around them was harder than just generating native code:
>
> 1. You're at the mercy of bugs in the C compiler you cannot fix.
> 2. C leaves quite a lot as "implementation defined", causing endless compatibility issues with various C compilers.
> 3. C's integral promotion rules.
> 4. Generating exception handling code for C is miserable and inefficient.
> 5. Your compiler is going to be slower than C.
> 6. You'll suffer from endless bug reports caused by a mismatch between your compiler and the user's C compiler, whatever that might be.
> 7. You cannot generate symbolic debug info in a format that looks like your language's definitions.
> 8. C's symbols will differ from your program's symbols, again making use of a debugger about like debugging code with an asm debugger, only much worse.
> 9. The generated C code will look awful.
> 10. The order of evaluation of C code expressions is implementation defined.
> 11. Installation problems, again, because you don't control the user's C compiler.
> 12. If your language supports a basic type that isn't supported by C, tough noogies (think SIMD types).
> 13. C has no concept of immutability or purity, so no hope of getting the C optimizer to take advantage of that.
>
> ... and on ...

Nice list. I was always wondering, if it made sense to generate C.

So D does a better job at interfacing to C/C++, because it uses the same memory model as C/C++, as opposed to outputting C code like Nim. This is actually very clever.

On Friday, 13 November 2015 at 14:31:08 UTC, Chris wrote:
> So D does a better job at interfacing to C/C++, because it uses the same memory model as C/C++, as opposed to outputting C code like Nim. This is actually very clever.

err... No. You get better interop by transpiling to C/C++.

With C it is easy, you don't use C's typesystem after all. Many languages do it. C++ is more complicated if you want to generate code that looks like C++...

On Friday, 13 November 2015 at 20:51:54 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 13 November 2015 at 14:31:08 UTC, Chris wrote:
>> So D does a better job at interfacing to C/C++, because it uses the same memory model as C/C++, as opposed to outputting C code like Nim. This is actually very clever.
>
> err... No. You get better interop by transpiling to C/C++.
>
> With C it is easy, you don't use C's typesystem after all. Many languages do it. C++ is more complicated if you want to generate code that looks like C++...

What you need is ABI compatibility, and it doesn't matter if you get it by transpiling to C or not. Even if you tranpile you declaration from language X to C, you need to make sure the generated C is the same as in the C code you interact with, and this isn't any simpler than generating the ABI directly (in fact, it is probably easier to map ABI directly as its semantic is much simpler).

But yeah, you'll debate everything to death even when it doesn't make any sense whatsoever.

In C the OS/hardware vendors define the binary interface and provides the tooling... So what is your point?

Plenty if useful tools and languages compiles to C successfully. That's a undeniable fact. That's reality.