
Microsoft Updates Visual Studio - kanche
http://techcrunch.com/2014/04/02/microsoft-updates-visual-studio-with-support-for-universal-projects-typescript-1-0-and-net-native-code-compilation/
======
InclinedPlane
.Net native code compilation, aka static linking for the .net age. This
feature is a LOOOOONG time coming, they should have had it available a decade
ago.

P.S. Mark my words, this is going to be a huge deal. Especially since MS is
acquiring Xamarin, which basically does the same thing, but for mobile
platforms. With the ability to develop in .net languages and still deliver a
plain-jane .exe that doesn't require jitting it'll open up a lot of new
opportunities. Especially if they start targeting non-windows platforms like
linux, iOS, and android with fully-baked tools. Imagine how much more popular
C# would be if it wasn't tied to the Windows platform? And if you could choose
whether or not you wanted to ship a small managed exe or a fat native exe that
launched quickly?

~~~
edwinyzh
The inherent slowness of .net is the ONLY reason that I'm sticking with
Delphi... It'll be a dream if we'll be able to compile .net/c# programs into
native and runs FAST!

~~~
edwinyzh
well, by "It'll be a dream " I actually meant "I dream of being able to native
compile c# app for the desktop". Sorry for the bad English.

------
gamesurgeon
There are rumors that Microsoft is considering the purchase of Xamarin [1].
And now Microsoft is now previewing their .NET AOT compiler for X64 and ARM. I
see great things in C#/.NET's future in mobile and cross platform development.

On another note, I wonder if Microsoft addressed the inherent limitations of
AOT in C# [2]. I wonder if it's a compile-time error, or if that segment of
code is interpreted. I doubt it's interpreted, as that's a giant perf loss.

[1] [http://www.wpcentral.com/microsoft-reportedly-considering-
ac...](http://www.wpcentral.com/microsoft-reportedly-considering-acquisition-
xamarin)

[2] [http://www.mono-
project.com/AOT#Limitation:_Generic_Interfac...](http://www.mono-
project.com/AOT#Limitation:_Generic_Interface_Instantiation)

~~~
nutjob123
Are they even still rumors? I thought that had been announced.

~~~
jeroen
This seems to be the sole source of those rumors:

[http://www.crn.com/news/mobility/300072056/sources-
microsoft...](http://www.crn.com/news/mobility/300072056/sources-microsoft-in-
talks-to-acquire-mobile-app-development-startup-xamarin.htm)

"Microsoft is in the final stages of negotiations that could lead to either an
acquisition or major investment in Xamarin, sources with knowledge of the
discussions told CRN recently."

The article is from march 17th and there doesn't seem to be anything newer.

------
pjmlp
Native compilation! This are great news.

Never got the point why Java and .NET adopted a VM approach, back in the days
when we already had safe systems programming languages like Modula-2,
Modula-3, Oberon, Ada, Delphi with AOT compilers on their canonical
toolchains.

~~~
andymcsherry
The purpose of using a VM is that the developer ships one version of their
compiled software that can be run by anyone who has the VM on their system.
Otherwise, the developer needs to anticipate every single architecture a user
might want to run it on. They might not be able to anticipate all these cases
which might not even exist yet.

~~~
voidlogic
There is also the Go approach, which is your code is platform independent, but
you need to compile it for each platform. You get native code that is
portable, best of both worlds. (Some might argue "Good C" can do this, but
that is often quite hard and C doesn't have the kind of stdlib that Go has..)

~~~
beefsack
I'd call that the static compiling approach, not just the Go approach. It's
possible to statically compile in a wide range of languages.

~~~
voidlogic
I was using Go as an example of this. The majority of statically compiled
languages don't support compiling the same source code to a multitude of
platforms.

The _same_ Go code and be compiled for x86, amd64, ARM and runs on
Linux,OSX,Windows,FreeBSD,OpenBSD,NetBSD,Dragonfly,NaCL,Solaris and Plan 9.
Not many statically compiled languages pull that off.

~~~
pjmlp
You can only pull that off in Go as long as you only use the runtime library,
which is no different than other language.

As soon as you bring a third party dependency, game over.

~~~
voidlogic
>>As soon as you bring a third party dependency, game over.

There are tons of 3 party libraries written in pure platform portable Go that
will cause you no issues. In fact the vast majority of 3rd party Go libraries
are just as portable as the stdlib.

~~~
pjmlp
So they provide implementations on all targets supported by Go compilers for
the features required outside stdlib?

~~~
voidlogic
The point is they don't have to- while Go compiled binaries are platform
specific, pure Go code is platform independent. That means any platform that
runs "go build" can run your Go program.

~~~
pjmlp
You are avoiding to answer the question.

There isn't pure Go code if it requires to touch the file system, talk to OS
using APIs not available in the stdlib.

The moment you depend on libraries outside stdlib, you are opening yourself to
dependencies to cgo and/or OS syscalls outside your control.

Even some stdlib packages are UNIX specific, e.g. os.user and log.syslog.

~~~
voidlogic
>You are avoiding to answer the question.

I'm really not, I am missing your point.

The majority of 3rd party Go code simply uses the Go stdlib just like our
hypothetical program.

Go is no less platform independent then Java, for example, yes there are some
3rd party Java libraries that use JNI, just like some Go libraries use cgo.

The fact that these native bindings to (often) platform dependent code exist
does not make pure Go/Java programs non-platform independent.

Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm
thinking of the Go repos people put on github or the Gorilla project
([http://www.gorillatoolkit.org/](http://www.gorillatoolkit.org/)), I am not
talking about using cgo to call glibc or something similar.

~~~
pjmlp
> Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm
> thinking of the Go repos people put on github or the Gorilla project
> ([http://www.gorillatoolkit.org/](http://www.gorillatoolkit.org/)), I am not
> talking about using cgo to call glibc or something similar.

The thing is, there aren't first and second class 3rd party libraries, all are
3rd party.

------
sergiotapia
Looks like I'm going start reading up on C# again! It's been a good 4 years
without touching .NET but these developments make my want to try a hand in
mobile Windows 8 development.

------
simonswords82
This confirms to me that as a software agency we were right to stick with C#
even when it was "uncool" and there were plenty of new kids on the block (I'm
looking at you RoR).

There were a number of times when I wondered if we had backed the wrong horse
in Microsoft but being able to gain traction on mobile development (assuming
the Xamarin purchase goes ahead) and other changes such as native compilation
makes me happy with stuck with them.

------
lawnchair_larry
But does it support inline x64 assembly yet?

~~~
pjmlp
It never will, it is a design decision. Even Intel pushes for intrinsics.

~~~
lawnchair_larry
Those don't do the same thing.

~~~
teacup50
They don't, but they're a lot saner to deal with. I don't even use inline
assembly where it's supported; all the magic of a compiler, all the foot
shooting of assembly, none of the transparency of either.

I'm happy either using intrinsics, or implementing assembly in separate .S
files; I can't recall the last time my avoidance of inline assembly prevented
me from implementing something I needed.

------
Taurenking
if only Visual Studio runned in other os's...as a matter of fact i know many
developers stick with windows JUST because of vs...

------
frozenport
I'm sticking with 2012, until 2013 stops crashing!

~~~
frozenport
Why am I being downvoted? I can't use VS 2013 because it is unstable... I
wonder if there are MS saboteurs among us.

------
mtVessel
And yet, we still can't get menu labels that don't make me wonder if it's 1986
again.

~~~
mtVessel
What, too soon?

------
malkia
Plugin developers are delighted - yet one more runtime version to support!
Nice move Microsoft!

