Of course thats just one mode. LLVM also supports regular compile/run scenarios.

Yes, but if I want the high-level abstraction of C# and .NET with the performance of C or C++, I can't get it because C# and Java are implemented through virtual machines. There's no need for it. If I know I'm only running the program on my machine there's no harm in compiling it right down to machine level. In fact, there's hopefully a performance gain.

What I'm saying is that languages themselves shouldn't be limited to one runtime methodology. All languages should be able to be interpreted, compiled down to byte-code and JIT compiled, or compiled straight to machine level. There's no reason they can't. Eventually, they're executing code on the CPU one way or another. The only question is, how many layers are between the program and the CPU and what's the most optimal solution for a particular use case?

Languages are just a way to communicate the instructions to the computer. The implementation determines how the computer interprets those instructions and there's no reason a language should only be used with one type of implementation.

I don't understand what you are trying to say. Language implementors know this. It's just that some languages/features are easier to map to "native" code (itself a bit of a lie) than others.

I could be wrong, but I think you're confusing ambiguous terminology. The C run-time is, AFAIK, just a regular library that contains the C language implementation. Contrarily, Java's VM is a program that itself processes the Java program (originally, interpreting the byte-code, though now probably JIT compiling it; which it would seem still involves interpretation). One way or another, turning byte-codes into machine instructions.

I'm not suggesting that it's some ground breaking idea. Google's Go seemed to be partially justified as a "dynamic"-like language that compiles down to native code, but they could have instead just developed a native compiler for Java or C# or Lua^[1] (albeit, a new language might well have been a simpler undertaking). The language itself can be thought of independently of implementations (though they usually aren't).

Dynamic linking is beneficial. It means I shouldn't have to rebuild my entire system when an integral library gets a minor update. The performance hit should be relatively minor (and more than likely, the virtual machines that .NET and Java run on probably have their own dynamic linking to do, so that's not exactly getting swapped out for something different).

My point is, there's no technical reason C# has to be compiled to CIL. It could be compiled straight to machine code (as could the .NET CIL it uses) if that was desirable. I'm not suggesting .NET starts building platform specifics into its builds. I'm just saying that on top of the CIL route, Microsoft could implement a compiler that goes straight to native code (for when that's desirable). Considering .NET is mostly Windows only (Mono being the only notable exception I'm aware of), the abstraction is almost questionable. It would make sense if the executables were actually normally used on other platforms, but that doesn't seem to be the case (though it is a worthwhile goal to work towards, Microsoft seems like the last organization that would want to)...

That's an implementation feature, not a language feature^[1]. The whole thing could be compiled directly to machine code, though it would probably be non-trivial to do (you'd need to generate appropriate memory allocation and management code). libc isn't a separate program like the Java VM is. It's part of your program when you link to it. The only reason it's separate is because there are advantages to dynamically linking.

Stackless Python outperforms Google's Go.

Well I don't really care where the language comes from.

If D2 had been presented with a tech talk video like Go was I'd have the same thoughts about it.

Do you have your period, Matt ? ;-)

I agree with you, and as mentioned Java has a compiler that does so. The point I would make, and I think others are trying to make, is that it isn't necessary. A native binary would provide no significant speed improvement over a CIL binary. With .NET's cache, you don't even have the JIT overhead. You mentioned verification being a bottleneck, but that only requires a few, small comparison checks.

For sure. But programming languages "succeed" for mainly non-technical reasons.

Erlang-style concurrency primitives (and implementation!) in a lightweight, imperative language is interesting to me. I don't think D provides that.

I am sure the posterity will appreciate us being blinded by marketing and then writing tons of software in a fundamentally flawed and inelegant language.

The niceness of writing the small percentage of the program that can be parallelized using 'goroutines' is outweighed by difficulty of writing the rest of it using the features (or lack thereof) that Go provides, in my opinion. While it is valid for one person in particular to strongly weigh the 'goroutines' feature such that any language with it will be considered better any other language without it, I question how valid this is for the programming community at large.

Witness: ... any number of examples which I will not bring up, as it will just end up a flame war.

Don't get me wrong. Go definitely has the feel of "worse is better" about it, and I hope some of the warts will be fixed in time. It just seems to me that, for non-technical reasons, Go has a (still small) chance of gaining some sort of traction in the space that C and C++ usually play in. I don't think it's the worst thing that could happen.