

Microsoft asking for engineer to work on a native compiler for C++ and C# - z3phyr
http://programmers.stackexchange.com/questions/177472/will-c-merge-with-native-c-compiler

======
RyanZAG
This changes nothing. You could already compile to native code if you really
wanted. This doesn't affect speed much at all - C++ gets the speed it does
from not doing bounding checks on numbers or arrays, and from the way
templates work, etc. Plus ability to optimize pointer usage, and managing
memory directly so you don't need garbage collection.

It also doesn't help portability at all, since the C# libraries are still all
mono/windows dependent. The CLR itself was never OS specific - it's the
libraries.

Total non-story. People see 'native' and immediately think that making it
'native' somehow turns C# into C++ and enables QT or something...

~~~
UnoriginalGuy
Thank you. It is like nobody has ever heard of the ngen utility before. You
have been able to compile a local copy of a C# application which runs
"natively" since forever.

It does improve performance, but doesn't magically turn it into a ASM/C/C++
executable for the reasons set out above.

~~~
DrJokepu
> It does improve performance, but doesn't magically turn it into a ASM/C/C++
> executable for the reasons set out above.

Isn't that, however, exactly what the Mono folks are doing with MonoTouch to
get apps written in C# run on iOS (and approved in the App Store)?

~~~
RyanZAG
Not really - they're just swapping out the libraries for ones that they can
use on iOS. It's not going to be portable off of iOS, etc. (EDIT: That is, the
iOS specific UI code - obviously non-platform specific library based code will
be completely portable)

Plus it won't be as fast as writing it in C/obj C as it will have garbage
collection overhead, type checking, bounds checking, etc etc. (For iOS style
UI apps this isn't a concern as they're mostly just thick clients to real
calculations done elsewhere, so speed barely matters as you are just relying
on the speed of UIKit for graphics anyway.)

------
mercurial
It's a link to a stackexchange post which contains essentially nothing but the
link to a post on the Channel 9 forums :( Apart from this niggle, sounds
promising.

Actual link here: [http://channel9.msdn.com/Forums/Coffeehouse/MS-working-
on-a-...](http://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-same-
compiler-for-C-AND-C--Not-in-incubation-but-for-production-)

------
candl
Windows Phone 8 applications (C#) get AOT compiled to machine code.

Here's an overview: [http://www.silverlightshow.net/items/Windows-
Phone-8-Compile...](http://www.silverlightshow.net/items/Windows-
Phone-8-Compile-in-the-Cloud.aspx)

Some video sessions:

[Deep Dive into the Kernel of .NET on WP8 - (talk about compilation starts
around the 22 minute mark)] <http://channel9.msdn.com/Events/Build/2012/3-005>

[Inside Compiler in the Clound and MDIL]
[http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-
and...](http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-
Sollich-Inside-Compiler-in-the-Cloud-and-MDIL)

------
ylatuya
Mono already compiles to native code with LLVM: <http://www.mono-
project.com/Mono:Runtime:Documentation:LLVM>

------
nicwise
C# can "go native" right now.

NGEN precompiles the IL into native code if you use the normal framework.

Mono AOT compiles (and links) code into various architectures, but MonoTouch
and Mono for Android (<http://xamarin.com>) would be the major public uses for
it - native iOS / Android apps using C#.

If you wonder "can they be any good": go get the new Rdio app. It's done in
MonoTouch (and their Android one, in beta, is done in Mono for Android)

------
jstclair
The link should probably go directly to the job posting, since the
StackExchange -> Channel9 posts don't really provide any additional
information.

The compilerjobs link
(<http://www.compilerjobs.com/db/jobs_view.php?editid1=648>) has a bit more
details:

"Specifically this work will include:

• Engineering parts of the reader for MSIL

• Creating a native compiler internal representation that the existing
compiler can optimize • Designing and implementing new managed optimizations
to augment the existing optimizer like range check elimination or speeding up
C# constructs on vector machines

• Engineering and co-designing the ability to emit a new object file format
that will support rapid linking

• Fixing all existing phases of the compiler so that managed code can be
correctly and efficiently compiled with the new auot-vectorizing/auto-
parallelizing Win 8 compiler."

So, this sounds to me like an element of high-performance computing (maybe
with the recent work getting Hadoop running on Windows?), rather than a fully-
native toolchain.

------
Yuioup
Misleading title. It should read "Microsoft asking for engineer to work on a
native compiler for C++ and C#".

~~~
z3phyr
Done that!

~~~
Yuioup
Awesome :-)

------
InclinedPlane
C# is probably my favorite language, although to be honest I don't have much
experience with Ruby, Python, or Coffeescript. However, coding in C#
(especially post v3.5) always feels like easy mode. You've got type safety but
you've also got enormous flexibility with lambda expressions, extension
methods, and so much other good stuff. And then the IDE becomes a real force
multiplier instead of just a crutch to keep you from falling down as it can be
with Java and other less savory languages, for example.

It'll be exciting to see how this affects the C# ecosystem.

Although it's even more interesting what this says about Microsoft's plans for
the future of the CLR. It seems as though MS might be coming to the conclusion
that it was a failed experiment, which is interesting given the success of
other VM systems such as the JVM. It'll be interesting to see whether or not
this move helps advance C# adoption outside of the windows platform.

~~~
RyanZAG
Is it just me who doesn't really like VS.net IDE? I like C#, but I would
probably prefer to use something like netbeans or eclipse over VS.net.

Mostly it's just how difficult and annoying it is to fix up a failed build. If
you are trying to build something and it's failing because of strange 32bit vs
64bit incompatible libraries or any similar style of technical issues, you're
left completely on your own with strange and vague build errors. On the
pythin/java/ruby side this stuff is in fairly obvious config files and
generally just seems to work. I can't be the only one who has run into this
kind of stuff?

Also, the docs/code completion just doesn't seem to work as nicely as in Java
where everything has nice big easy to read document blurbs on every function.
For example, Bitmap.create<ctrl+shift> and eclipse gives me an awesome popup
with all the different versions and a big documentation window from JavaDoc
about how exactly to use the function and when/when not to use it.

With VS.net, I'm always having to go read up on MSDN pages in a browser which
are poorly written. Just me?

~~~
roflc0ptic
I'm a junior developer who's been working with C#/.net/VS for about six months
with very little guidance, so maybe take this with a grain of salt, but in my
experience Visual Studio is regularly an impediment. We had a single with our
setup project that took us a week+ of man-hours to resolve, stemming from
someone opening a project up in VS 2010 instead of 2008, and then committing
the changes. Almost every time I check out a project some of the assembly
references are messed up. There are always more errors when I check out code
than when I last checked in the project. It regularly takes me about half an
hour to go from "Hm, let me fire up this project" to "okay, I'm at the
breakpoint". In an environment where I'm working on like five projects, this
seems nuts to me.

Coming from python and php, the syntax highlighting is pretty sweet (but then,
using the python REPL, I hardly needed it. It's sort of like "look at this
problem you didn't have before that we solved!"), and I'm starting to
understand why people like static typing, as it reduces certain classes of
errors.

I think I want to go back to python and Vim or Notepad++, though.

~~~
ebrenes
All abstractions are leaky. Visual Studio and its associated files are meant
to act as helpers and thus abstract away several details of the project, what
it does with them but there's still a process to it all.

Project files are like build scripts and changing them can cause breaks. Just
like wanton changes in a build script can do the same. If you proceed working
with VS, I'd suggest familiarizing yourself with project files and how they're
set up. All automated processes make assumptions and rely on certain
conventions. I've yet to meet an automated process that can adapt itself to
any situation to suit its user's whims.

For new developers I generally recommend they review all changes they commit,
including project files. Just because its an abstraction or things happen
automatically doesn't mean you can just push all changes into the repository.
When you open a 2008 project in 2010 you are prompted that changes will take
place for example, so it's not like it was a stealth change.

Once they're properly set up project files are pretty maintenance free, but
certain behaviors can make them unstable to use.

For example, if you need to support both VS2008 and VS2010, just create
duplicates, it's no different than having build scripts that are not backwards
compatible, you'll have to keep multiple versions around. Or just keep the
VS2010 conversion locally and don't commit that back into the repository.

Anyways, you can go back to a simple text editor and just use msbuild
manually, if you prefer keeping track of everything manually. best of luck!

~~~
roflc0ptic
>> I've yet to meet an automated process that can adapt itself to any
situation to suit its user's whims.

That's pretty valid. We may be living in an edge case, and I trust that if
everyone's experience with VS was as bad as mine, it just wouldn't get used.

Thanks for your thoughts.

------
nopassrecover
Isn't this somewhat related to the goal of the Roslyn CTP
(<http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx>)?

~~~
moreshoes
Doubtful. These are entirely different parts of the toolchain, and the goals
(while similar in wording) are entirely different from each other.

~~~
Permit
No, if you watch the videos, Anders specifically says that they plan to eat
their own dog food on this one and expose APIs to the same compiler they use.
He also says that they're rewriting the C# compiler entirely in C# as part of
Roslyn.

~~~
moreshoes
Exactly, and that has nothing at all to do with the position posted by
Microsoft in terms of this thread.

------
Permit
This is really strange to me as Anders Hejlsberg says they're implementing the
C# compiler in C# as part of the Roslyn project.
[http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-
Me...](http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-Meet-the-
Design-Team)

~~~
noblethrasher
But a managed code compiler could still generate native (and managed) code if
needed.

Or a new C# compiler could be written in some kind of native C# variant that
generates both managed and native code.

~~~
pjmlp
Like bartok, the MSIL->x86 compiler in Singularity.

------
bdfh42
Using the .NET Micro Framework C# can already run pretty close to the metal -
so why not?

See <https://tindie.com/shops/nwazet/netduino-go/> for an accessible example
set up.

~~~
jbester
.NET Micro framework is actually a different beast in that's it's close to the
metal but it's not compiled to a specific architecture. The MF is a bytecode
interpreter vs the mainline dotnet framework which is JIT'd or AOT compiled
(with NGEN).

This approach gives a couple advantages and a couple disadvantages.
Specifically, the advantages the debugging and reloading can be done extremely
quickly, the bytecode is small thus giving a lot of functionality per the byte
of storage space, and it's significantly easier to port from microcontroller
to microcontroller. Downsides, it's pretty slow - typically the heavy lifting
happens in the HAL/MF, and you can't write interrupt handlers directly in it -
although you can indirectly via the managed driver interface.

------
polskibus
This would open lots of possibilities, however teaching all those
c#_with_no_c++_background programmers about proper use of destructors and RAII
may be hard ;)

------
smallegan
This title should include a question mark.

