RFC in Comparison between Rust, D and Go

[Walter Bright via Digitalmars-d]

On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote:
> I'm not sure if it reasonable to set aside the preprocessor,

If your new language doesn't have the C preprocessor in it, then you must set it 
aside. If it does have a C preprocessor in it, then it really isn't a new 
language at all, it's just a C permutation.


> but it depends on what you mean by interop:
>
> 1. portability
>
> - A language like Nim obviously has a better portability future since that is
> the one of the primary goal of having portable C source code.

That's all very fine until the that C compiler evaluates expressions in a 
different way than the one you debugged it with, and your language fails on your 
customer's machine with your customer's C compiler, and fails in weird ways.

You can't just dismiss the points I made and say "It's C, so it's portable." It 
isn't. If you're anxious to learn the hard way, feel free :-) It's one thing to 
read the C standard and pontificate about it, it's quite another to actually be 
in the trenches and deal with it.

BTW, although C compilers exist for all kinds of weird machines, the weirder the 
machine is, the worse (i.e. more limited and buggier) the C compiler is for it 
(as a general rule).

Good luck porting your language to a C compiler that has 10 bit bytes in it, or 
one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard 
conforming variations. Nope, none of your "portable" C code will work on it.


> Compile time does not have to be a big issue,

It always is once your project exceeds trivial size. Remember, my experience is 
a factor of 4x slower. And you cannot fix it.