Hacker News Reader

Comment by frik | Hacker News Reader

Aren't the plans for AOT to work only with WinStore apps?

No.

Currently .NET Native (AOT) is used with WinStore apps - in fact every Win10 .NET application in the store and on your computer HAS to be .NET Native - but the plan is to make compiling a native DLL possible for all .NET Core applications.

no - they first mentioned plans for cross platform go-style single binary compilation at connect (one of the videos here I believe: https://channel9.msdn.com/Events/Visual-Studio/Connect-event...) and I'm pretty sure they've subsequently talked about it in more detail in one of the community standups.

What's the difference between a "go-style" binary and any other statically-linked binary?

None, but apparently many seem to only ever seen static linked binaries in Go.

So many write "go-style" as if it was something that was just invented by the Go team.

So is the knowledge in our industry.

Now now, there are plenty of people in our industry who would cringe at even the term "go-style" as a description for statically linking libs in, though most of them have long since left HN by now. Finally got around to reading that PARC/Cedar doc you linked out a while back, last weekend. Interesting stuff. Thanks again.

Glad you liked it.

I imagine even grognards would describe many things as C/UNIX-style that actually have their roots in earlier systems.

Just ask pjlmp about it. He seems to still be bitter that the lispm and wirth's stuff lost to C and unix.

EDIT: pjmlp. I don't make a habit of getting people's usernames wrong, but that one's hard to read.

No problem. :)

I wrote go-like because I think of C#/.NET and go as somewhat comparable and I'm not aware of any other language in a similar class that produces statically-linked binaries. However I'm pretty ignorant, so would not be surprised if there are many ... examples?

C and C++ will produce statically linked binaries if you ask nicely (gcc -static).

There are some traps though; one I ran into for example is that you require dynamic linking in order to use libnss. I ended up producing a mostly-static binary that just depended on the platform's libc but brought its own libstdc++.

Similarly on Windows, statically linking third-party COM components is not a good idea.

Any programming language that has AOT compilation to native code among its implementation choices.

There are plenty to choose from, but if you want a list:

PL/I, Algol, PL/M, Quick Basic, Turbo Basic, Quick Pascal, Turbo Pascal, C, C++, Ada, Eiffel, Haskell, Objective-C, OCaml, Delphi, Oberon, Oberon-2, Component Pascal, Mesa, Modula-2, Modula-2+, Modula-3,...

Do all of those support static linking with the default tooling? (That is to say, not just hypothetical support, but actual support)

Jeez.

Of course, once upon a time static linking was the only way.

It is dynamic linking that is hard to implement, not the other way around.

I KNOW that. I just wanted to know if the native compilers for the languages you mentioned supported static compilation either through a switch or by default, or if it's something that somebody else would have to write.

Initially by default, many of them are older than OSes with dynamic linking support.

The ones with compilers that also support dynamic linking, either via a switch or via explicit dynamic modules.

I recently rediscovered (lying around on my disk) a bunch of Free Pascal[0] programs that I wrote and compiled in 1999. The executables are all statically linked and still run just fine on my current Linux system. The simple "hello world"-eque ones take up just tens of kilobytes of space.

[0] http://freepascal.org/

A lot of today's developer have never done it with another language before and so knows it as "the thing that go does".

They demoed it for Linux command line and touted that, so I doubt it.

I'm hoping that Winforms/WPF apps are supported at some time soon.

You probably won't. This is .NET Core only. .NET Core is a cross platform slimmed down version of .NET and doesn't run Winforms or desktop WPF. Windows Store WPF is supported.

If they really wanted to they could open source Silverlight GUI framework. That was basically WPF lite. They can take out the video/DRM stuff and just put the GUI layer out there - it was ported to OSX so it's at least somewhat portable.

It would be nice to have something like JavaFX for .NET - resurrected Silverlight could be it.

What I've been doing is in my solutions is adopting the Adobe approach and keeping a separate project for QT with all of the UI 100% abstracted out into that. Cross-platform builds are pretty easy, I get all of the safety of C# along with all of the tooling on NuGet crossplatform, and native UI interfaces on all 3 platforms with QT. The only time I come close to touching Winforms/Silverlight or WPF is if a client is dead-set on using Telerik or whatever.

and drivers.

Reply on news.ycombinator.com