RFC in Comparison between Rust, D and Go

[Walter Bright via Digitalmars-d]

On 11/11/2015 4:19 AM, Walter Bright 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 ...

I forgot to add:

14. Many C compilers do not emit COMDATs, which cripples flexibility in emitting 
code.
15. C doesn't give access to special features in the object file, which you may 
need, such as weak externs, special sections, etc.