Take care with Go PR, and don't mistake languages with implementations.

Java compilers to native code:

- VMKit

- gcj

- Excelsior JET

C# compilers to native code:

- Windows Phone 8 deployment

- NGEN

- Bartok

- Mono with -aot

Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics.

tikhonj was talking about implementations when he described Go as managed imperative language. Go is compiled to native code in all major implementations. In general, it's extremely easy to determine when people are talking about implementations and when they are talking about the language proper. Implementations are important. The primary implementation shapes the language, the way the standard library is designed and scoped, and seeds the ecosystem surrounding the language. Changing the implementation to a native one after the fact changes very little.

> Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics.

This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#.

> Go is compiled to native code in all major implementations

So is C#, bytecodes are only used as a storage format.

With Microsoft tooling you can JIT at load time, NGEN at installation time, convert to MDIL when uploading to Windows 8 App Store, or convert to pure binary with Bartok in Singularity.

With Mono tooling you can JIT at load time or generate binaries with mono -aot.

With Cosmos OS , it gets compiled to native code.

> This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#.

Please provide an example where Go compilers offer more control than C# ones.

  type T struct {
  	X, Y P
  	J *Q
  	Z [42]struct {
  		A R
  		W [100]S
  	}
  }

Please note that P, Q, R and S are arbitrary types, not just a subset of value types, and an instance of T is contiguous in memory.

Ah ok, now I understand your point and you're right.

I was actually under the impression that any value type could be used in fixed buffers.

You can however workaround that by using fixed byte buffers with serialization, but it is not so programmer friendly.