RFC in Comparison between Rust, D and Go

[Chris via Digitalmars-d]

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.