Hacker News new | past | comments | ask | show | jobs | submit login
CoreRT – A .NET Runtime for AOT (mattwarren.org)
166 points by matthewwarren on June 7, 2018 | hide | past | favorite | 75 comments



I think it is really cool how much of the CoreRT is written in C#. Garbage collection and stack frame walking are implemented, but most everything else is C#, including exception dispatch:

https://github.com/dotnet/corert/blob/master/src/Runtime.Bas...

and type-casting:

https://github.com/dotnet/corert/blob/master/src/Runtime.Bas...


Yeah, that's what impressed me as well!

Turns out that even more components could be written in C#, but the ROI just isn't worth it, see https://github.com/dotnet/coreclr/issues/17576 for an interesting discussion


While it may have not fit their needs, the prior work in COSMOS suggests they could've done more if they chose:

https://en.wikipedia.org/wiki/Cosmos_(operating_system)

I also usually bring up Oberon and House given safe languages can handle low-level stuff if you turn off safety plus hide it in some module.

http://www.projectoberon.com

http://programatica.cs.pdx.edu/House/


quick unrelated show of hands - who here uses .NET for their after hour / geeking session / projects?

I know .NET quite well, I've used it a lot in enterprise, but I just never find it to be my go-to language. It just feels like work, it doesn't feel fun.

I usually end up with nodejs, nim, or even pascal.


I find development "speed" to be directly correlated to happiness in side projects, as in getting things done quickly.

So with that in mind, C# with the right IDE (VS + Resharper, or Rider) is faster to write than anything else I've ever used and makes working on projects incredibly nice. Add in the solid standard libraries and the ability to make everything from websites to desktop apps in the same language and it's the best choice around, for both work and play.


I can recommend getting a a licensed copy of LINQPad. It's a brilliant tool for trying out ideas and prototyping.


I love LINQPad. This tool alone is a huge reason why I have a problem using my Macbook for .NET development.


One of my better purchases was a license for the enhanced features of LINQPad. Saved my ass a number of times with tricky or time-constrained projects.


I find .net for side projects is much nicer because I don't have to deal with a massive codebase, subrepos, waiting ages for compilation, dealing with weird nodeterministic issues collected from years of technical debt.

Also don't have to deal with Winforms.


To add to that, I love that developing either using MS' tools or monodevelop will likely give you a software that works fine under linux and windows (and I guess OSX).

If I need a quick GUI, either Qt or C# will cut it. It mostly depends on the third party libraries.


I use .NET for everything. It doesn't feel like work to me -- the language has some pretty nice features in C# 7. Paired with the .NET Core CLI and I basically feel like I'm using TypeScript with Node.js, but .NET Core is arguably easier. But to me the bulk of the fun comes from seeing the project come together (ie. the results), vs. the actual process of coding.


I do. If you don’t mind Windows, there isn’t really an alternative in term of excellent tooling (visual studio), universal (you can do a website, a console or a desktop UI with the same language and tools), and good compromise between performance, sophistication (like using multithreading easily), type safety and speed of writing. Java possibly adds multi platform at the expense of rougher tooling and desktop UI.

I am much less of a fan of Xamarin, tried it, too clunky (for instance the default settings for the android emulator do not work out of the box) and slow.

And it’s a matter of taste. I don’t like dynamic languages as I’d rather have the compiler check my syntax for me rather than having to write a test, and static typing enables great refactorings. But other people will have other priorities.


I finally moved to Xamarin a few months ago and it's not slower than the native languages. No clunkiness either, it's just bindings to the native APIs after all.


Sorry, I was not referring to the execution speed of c# once deployed, but the experience of pressing F5 to debug the app in an emulated environment is pretty slow and hairy, and makes development hard.


I don't see much difference in the iOS simulator: deploy and launch take 3-5s. It's about the same for the Android emulator but I have no experience with Java development, so I don't know if it's fast enough.


C# just has such fucking awesome tooling that I can't leave it.

I want to take F# for a spin, but I haven't broken the bond yet.

Javascript is like the complete opposite of this, for languages I have to deal with. Just painful and slow and error-prone.


Thank you M$oft, people have been dumping unmercifully lately, but I love you, warts and all.


I use F# for most of my projects at this point. Lets me pump out 90% correct code in about half the time as C#.


For coding for fun I use F# in VS Code with Ionide. https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...

If you can't use F# at work I really like this https://github.com/louthy/language-ext for a more functional flavor of C#.


I think F# will be my next learning project. Still keeping an eye on Idris, though.


This.


Yes definitely and .Net Core mainly for this. When projects are structured well they are very portable and with VSCode you can immediately get in and start debugging. Deps auto download and everything. Xamarin has been a huge hit with other devs I know too although switching omnisharp (when using VSCode) over to it takes a little know-how to get the same tooling it should somehow be automatically inferred that would help. Nowadays just using .Net Standard for Xamarin works probably most devs will head in that direction in the future. A better REPL would also make it more popular when I use Python or NodeJS imports of 3rd party stuff is easier- if all of these various features in various 3rd party REPLs were kinda auto-magically part of C# development it would be more "fun" https://www.nuget.org/packages?q=REPL


I generally prefer to work in different environments at work and at home (usually .NET at work and iOS at home).

That being said, I use C# at work, and recently started using F# for side projects (which does actually feel fun to write (for now anyway)).


I do, specifically dotnet core. I've switched recently from C# to F#, but its still dotnet core and aspnet core.


I REALLY like the .NET ecosystem and have written a ton of C# code in my free time. However, I mostly use TypeScript these days because it's most fresh in my mind(from work), good enough for a lot of stuff, and the obvious choice when doing Electron stuff.

That said, I would love to start using F# for everything even though I have never used it for anything aside from brief experimenting :)


I tried learning PHP so I could make use of the large marketplace of cheap commodity web hosting, but I stopped after realizing that my life was too short for this. So now I use C#/.NET for my personal websites.


I had a similar experience with Node and rich web apps (well, less learning and more focusing my time in existing skills), but it took me three years and two failed startups to come to that same conclusion.


I use .NET from pretty much anything I build, whether it is my main project or a pet one. It's blazing fast, Visual Studio is stellar, C# is a joy to work with and probably the most evolving language, SQL Server is very matured and the list goes on. The only thing I find lacking in the whole ecosystem is Windows, but you can't have everything. And thanks to .NET Core moving to Linux is a dream come true.


The reason why I don't do .NET after work is to see how other languages and platforms work, so I can bring fresh ideas to my workplace.

Been doing that for years. I run Linux at home and use Windows at work.


I use .NET for everything; it is fast to write and nice to read. F# is a good one if C# bores you.


I do. I build all my geeky/experimental back end services in .Net Core these days because it's quick and easy and dare I say, fun.


When I happen to have time on a rainy weekend, .NET is certainly part of the possible options, given that I care a lot about graphics programming.

Languages without good GUI frameworks or nice IDEs usually don't cut it for me, when I am supposed to be having fun.


I prefer C# for the back-end and using a dynamic language (inc. TypeScript) for building UI's, which I find is a highly productive combo which has gotten a lot nicer with .NET Core where it's now a nice dev experience using any IDE/text-editor on any platform to build apps that runs flawlessly on Linux/Docker/etc.


I have considered many languages my "home". After the dust has settles, I always realize that I'm much more efficient in C#.

This is subjective thought. C# isn't empirically the most efficient language, but for me, I can really focus on the features/requirements and not the tooling.

Go has been awesome as well. My second home.

I'm going to visit Rust next.


C# for everything side-projects here. It's the one language that I feel good for server-side backend, interactive desktop apps, and console apps with ease. It simply has awesome tooling and a sane standard library + language design that is incredibly expressive. I can get low-level if I'd like, which is awesome.


If you're talking about C#, I have similar issues. I like to play with F# from time to time though. I've started using it in a small project to make window switching in Windows more bearable, for which .NET made actual sense. Apart from some platform-inherited weirdnesses, it's actually a really great language and useful to explore more FP oriented ideas.


I do. My favorite part about coding is always dealing with the domain, algorithms, and design parts. And C# lets me code quickly so I can focus on the fun bits.


I'm learning C# and .NET at my summer internship and I feel like I'm falling in love. Visual Studio and Resharper just make it an awesome experience. We do WinForms at work but I want to make a side project for multiple platforms so I'm hoping Xamarin can do the job (I'll need arbitrary 2D graphics drawing so I might use CocosSharp).


I do for GUI applications. Building simple winforms applications is an incredible pleasure. It just doesn't get more accessible and quick than this. The one and only problem with winforms I encountered is its bad performance.

I made a freely movable and resizeable frame-less image viewer in C#/winforms for times when I want to view lots of pictures at once. (;


> The one and only problem with winforms I encountered is its bad performance.

Can you elaborate on that? If you keep the work off your main thread, and don't create an enormous amount of controls, noticeable performance should not occur.


> main thread

I tend to give every custom "singleton" window its own thread -you don't have to limit yourself to one main thread and I dislike modal interactions. Performance in that sense was great and taking care to correctly use Invoke/BeginInvoke made hassle free multithreading a breeze.

> and don't create an enormous amount of controls

That's exactly what I did. I created so many controls, the application rendered white boxes with a red strikethrough or outright crashed. WPF does not have that problem and additionally offers virtualization to speed up visual containers containing lots of complex controls/children. Yet WPF is a complex, overengineered mess with a steep learning curve.

It was my first big project to write a desktop application -I used winforms for it and everyone loved it. It was a tiny .exe file. I tried rewriting it in WPF three times but gave up every time...


Not OP but I too encountered performance issues with WinForms.

When you have long lists, or any large content inside scrolling panels, you’re technically creating an enormous amount of controls, and the performance degrades.

Possible to workaround, e.g. lists have ListView.VirtualMode property + associated events, for long web page-like content you can use an embedded browser, etc., but these workaround tend to be quite tricky to implement and debug. WPF too has a couple of issues with UI virtualization, but by comparison, it’s much simpler in WPF than in WinForms.


Try F#


My "home stack" is .net core, and ts+Vue if I need a gui. While I genuinely love and enjoy all the aforementioned pieces, I do not enjoy messing with webpack and friends, and every once in a while even Vue and ts reveal themselves to be leaky abstractions. I have high hopes for blazor finally providing a solid GUI alternative.


LibMan will rescue us from webpack and friends.

https://blogs.msdn.microsoft.com/webdev/2018/04/17/library-m...


LibMan is nothing more than a friendly file downloader, it's very different from what webpack does. If you that's all you needed then webpack was already unnecessary.


I do. I usually use F# for geeking out.


I typically use scripting languages at work and C# for my side projects. I’m of the “reasonable boundaries are a good thing” mindset and find that the structure C# enforces helps me write more readable and extensible code in other languages.


Add me to the C# guy list. I've been using it since around 2003 or so. I run Windows in a VM on a Mac Pro. It's my go-to language. Before that it was mainly Delphi, after Borland Pascal and C++ in DOS.


How's Nim?

I'm not sure what to think of the way it compiles to C and has its own garbage-collector.


It's good fun, like an swiss knife type language. Doco is pretty average, a lot of aha moments.

But once you get going you're really fast at pumping native tools.


Sounds a lot like the D programming language.


I actually do more .net coding in side-projects than i do elsewhere! i like working with it


F# is perfect for geeking around.


If the compiler does tree-shaking, I wonder why it takes ~4 MB just to print a message on the console using the standard library. Is there any way to do a more fine-grained breakdown of where all that code is coming from?


They are big leaves/fruit and there are only about 30(?) or so of them.

There is no easy way that I'm aware of. IIRC, early versions of this included the entire framework, so it's gotten a lot better.


> They are big leaves/fruit and there are only about 30(?) or so of them.

Ah, yeah that makes sense, I'd not thought about it like that.

> IIRC, early versions of this included the entire framework, so it's gotten a lot better

Yeah, they're definitely improving things over time


I wondered the same thing, it seems like 'System.Private.CoreLib.dll' is all or nothing, unless of course you write your own version such like 'Test.CoreLib' (https://github.com/dotnet/corert/tree/master/src/Test.CoreLi...)

I don't know if it's technically impossible or just hard to have 'tree-shaking' being done on it, so that you only get the functions/dependencies that are actually called?


> Is there any way to do a more fine-grained breakdown of where all that code is coming from?

See https://gitter.im/dotnet/corert?at=5b1af059178709146f21076f for some techniques to do this


AOT Java images are also around 4 MB. Maybe the GC in both takes up around 4 MB?


The GC code isn't _that_ big. It's because AOT compilers tend to turn each assembly/package into a single code object for linking, instead of a library of objects that can be filtered to just the code needed.


I just double checked and you're right, the GC code is pretty small. The 0.49 MB run-time `Test.CoreLib` (http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT...) includes the GC as well.


I thought most AOT tools did tree shaking, or whole-world analysis?


As I understand it, this paves the way for .NET based wasm implementations. Exciting stuff!


.NET already runs on WASM, see: https://github.com/aspnet/Blazor

Although I personally don't think it's a good idea to build HTML UI's with C#, which adds overhead + friction.


Blazor currently runs on Mono. CoreRT might allow it to run on .net core


Yep, seems like the Mono impl was more mature, you can read a bit more about this decision here https://github.com/aspnet/Blazor/issues/286#issuecomment-373...


The important part is that it's AOT compiled into WASM so it can run in the browser which is what you can do now with Blazor.


no, blazor uses a Mono version that interprets at runtime .NET. AOT is in the pipeline though


Alright, so here is the big question since ILASM is so powerful really and .NET Native can potentially reduce the footprint here...What would be the strategy for a bespoke native CoreFX? The mscorlib/System.Private.CoreLib issue is that for new platforms it needs to be built PE agnostic temporarily. PAL needs a placeholder platform to get itself created. CoreCLR is great but a huge moving target which receives updates at such a furious pace- well imagine trying to contain dynamite in a closed fist. Actually, mad props to MS and the open source community for actually making this so solid on a consistent basis! So, CoreFX needs a seed CLI distributed platform specific. CoreRT may have the answer to this and really interested in what happens next. You see I wonder with this platform sharing if a CoreFX could be potentially created with CoreRT first and then backtrack into a full platform? We'll see- I'm glad this was shared here on HN also gives me a lot of hope for C#.


Waiting for the day to use CoreRT with ASP.NET.


You can with aspnet core. Bit tricky tracking down all the reflection types in the rd.xml file, but once done it results in a really nice, zippy little deployment


Are there any tutorials for this? I would love to learn more.


I'd start with the WebAPI sample and it's rd.xml file, see https://github.com/dotnet/corert/blob/master/samples/WebApi

Also take a look at this project https://github.com/shtik/cli/tree/dev/src/slidey, AFAIK it's the project that inspired the video I embedded in the post


There are samples on the CoreRT site, which are a good place to start. I found some of their discussions useful too when finding bits to put into rd.xml, like newtonsoft.json




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: