RFC in Comparison between Rust, D and Go

[Walter Bright via Digitalmars-d]

On 11/9/2015 3:26 PM, deadalnix wrote:
> On Monday, 9 November 2015 at 23:11:34 UTC, 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 would not trust such language to have a precise semantic. There is way too
> much undefined behavior in C for that.
>

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