the namespace doesn't load the assembly, but C# 'using' does (also) serve to import visibility of the symbols into the current compilation unit, whereas C++ 'using' does not (the symbols still need to be declared within an #include'd header or similar). so, there is a functional semantic difference between them.

The bolded part is wrong. In C#, if your translation unit doesn't have a using directive for a particular namespace, you can still use symbols declared in that namespace as long as your assembly references the one containing the symbols you're trying to use. The symbols are still visible, it just means that you have to provide a (more) qualified name for the symbol, ie. System.Console.WriteLine() vs Console.WriteLine().

See http://msdn.microsoft.com/en-us/library/sf0df423(v=vs.110).aspx.

what is being described there is more how it is made to look from the POV of the C# code, but this doesn't necessarily map exactly to what is going on in the compiler and linker (IOW: underneath the global namespace abstraction). (just because there is more than one way to do something does not mean it isn't being done).

( ADD / analogy: basically, consider something like the Linux VFS, which looks to programs and code like a single unified tree, but may actually be composed of any number of mounted volumes at various mount-points, and parts of the directory tree are loaded and unloaded in a piecewise manner from the HDD as things are accessed, ... while high-level code doesn't necessarily need to know or care about it, doesn't necessarily mean it doesn't exist... ).

but, whatever, how about it is just stated more directly:

in C++, you need a headers (or explicit declarations, or whatever else) to be able to see stuff which is declared elsewhere, whereas in C#, you don't need headers for this (because the compiler does it instead).

this was the main relevant point anyways.

A C# that compiles to native code. That's all.

Or, in alternative, a Go with generics and operator overloading.

Is there something specific you'd like for C# that compiles to native code that isn't covered by ngen?

Nothing to do with performances... I just wish for:

code that does not decompile to the EXACT source and yes I know about obfuscators...

No runtime needed.

I don't know if you can drop the unmanaged code in ngen on top of generating native (i wasn't thinking of performance at all, but originally you said compiles to native & ngen does exactly that). I see your point there, i haven't checked if it's possible to have a pure jited assembly without the original msil, if it's possible it should be about the same dificulty to decompile as C++ if you use an obfuscator on top (to strip most of the reflection info), if not then yes regular obfuscator is the best you can do and that won't do the job.

Personally i don't mind that it can decompile back to original at all, and obfuscator means crappy bug reports about something craching in square square square weird symbol weird symbol unless you manage it correctly too

I see your point there, i haven't checked if it's possible to have a pure jited assembly without the original msil,

it's not possible. Mono has some sort of AOT compilation, but, when I tried to look into it it felt hacky as hell.

Releasing a C# application really is releasing it as "open source".. it's so incredibly easy to get an assembly, decompile it, generate a VS project out it, change, compile, put it back.. it's not even funny.

Of course, not every game needs to protect their IP as far as code is concerned.. Magicka did just fine releasing without obfuscation.. but not every software project can afford to release the source code bundled.

C/C++ is perfect for me.

I mostly use them as well, but they aren't really ideal for everything, so the question can be raised, what might be?...

not necessarily that such a "one language to rule them all" can actually exist, but it is partly a mystery of what such a thing might look like exactly, like what features would be needed, what sorts of pitfalls would need to be avoided, ...

as well as a lot of "little things", like:

why can't I just type "int[64] arr;" instead of "int[] arr=new int[64];"?... (when the added logic to support "int[64] arr;" is fairly trivial).

then there is things like 'delete', where:

can indicate the end of object lifetime in cases where the compiler and GC may fail to notice it;

but, it can be argued that it is redundant in the case of good static lifetime analysis, and poses a possibility of misuse, ...;

but, OTOH, fully resolving object lifetimes is a difficult problem even with static analysis, basically meaning that pretty much any non-trivial cases end up falling back to the normal garbage collector;

...

in my case, I assume more treating it like a hint, where its exact behavior will depend some on compiler settings. currently the default behavior (in my case) is for the compiler to handle it literally for trusted code and ignore it for untrusted code.

as noted elsewhere, there are a few features which, although potentially nifty, could probably be left out of such a language for sake of "compiler writer sanity", or at least restricted in a few ways, such as requiring the variable scope to be "lexically visible" (basically, where the location of any accessible variable can be determined simply from the lexical context of where the variable reference occurs, *1).

*1: static languages tend to require this as a basic assumption, as do most script languages as well, but not all ways of handling variable scope assume this. decided to refrain from going into too much detail over this one. but, the basic assumption here is that by walking "outward" and jumping through any relevant import/using/... statements, it is possible to reach any variable which may be referenced from a given source location. the contrast is scoping models where the current execution state and/or control flow are what determine which variable bindings are visible and the path needed to reach them. (basically, it then typically either turns into using runtime variable lookups, or trying to handle it with static analysis).

Allocation of objects in RAM should work similiar to allocation of objects through some object manager, instead of all these ugly globals like "new"

can you elaborate more on what you mean by this?...