5 ms·

NativeAOT is one of the most important feature C# needed, very nice that it is finally coming, i still can't believe it took them this long Congrats to everyon

NativeAOT is one of the most important feature C# needed, very nice that it is finally coming, i still can't believe it took them this long Congrats to everyone who fought vigorously to make it happen, screw the managers, execs and their surrounding noise, long live to the real engineers at Microsoft

sylens 4y ago
Agreed, I feel like it was the missing piece from their .NET Anywhere story and am curious to see if it creates an uptick in adoption
- CharlieDigital 4y ago
  This was the first thing I tried out this morning and apparently it is not meant to work with ASP.NET (Web API in this case) and only for console applications. Explains why my container got stuck packaging Kestrel this morning.
  - sylens 4y ago
    Oh that’s disappointing. Looking through the blog post now it specifies console apps now - wonder if Web API support is coming later.
    - metaltyphoon 4y ago
      Yes, the next workload will include ASP.
  - Kukumber 4y ago
    It'll be ready at some point, people at AWS experimented with it, they have a sample ready: https://github.com/awslabs/dotnet-nativeaot-labs https://github.com/awslabs/dotnet-nativeaot-labs
VancouverMan 4y ago
The article mentions things like: - "All required code is compiled and/or linked into the executable, ..." - "No JIT means no dynamic loading of arbitrary assemblies ..." - "... with everything compiled and linked into the app ..." This sounds very much like static linking, possibly with no option of dynamic linking/loading of code. Presumably this would have implications for those using LGPL-licensed .NET libraries, especially those who'd like to distributed closed-source applications AOT-compiled using this approach? Are there any commonly-used .NET libraries these days that are only LGPL-licensed? I haven't done .NET development in a decade, so I don't really know the current state of affairs.
- yread 4y ago
  Is there a difference between static or dynamic linking for LGPL?
  - TingPing 4y ago
    Yes. The point of LGPL in concept is there is a clear boundary where you can modify and replace code. You can't replace a statically linked library.
    - jcelerier 4y ago
      And yet https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
      - TingPing 4y ago
        I don't think that conflicts with what I said. You have to be able to replace the library and them shipping linkable objects does that. Most static releases do not do this.
        jcelerier 4y ago
        The proprietary ones which use LGPL libraries do - it's uncommon as it's a bit more work for the proprietary dev but it happens
pjmlp 4y ago
While NativeAOT is to be praised, we should not forget all the avenues that came before it. NGEN, Singularity and Midori research (whose tech landed on Windows 8 MDIL and UWP .NET Native respectively), Mono AOT. I always were the opinion that given Anders Hejlsberg background, .NET 1.0 should have had a better AOT story than NGEN.

sylens 4y ago

Agreed, I feel like it was the missing piece from their .NET Anywhere story and am curious to see if it creates an uptick in adoption

CharlieDigital 4y ago
This was the first thing I tried out this morning and apparently it is not meant to work with ASP.NET (Web API in this case) and only for console applications. Explains why my container got stuck packaging Kestrel this morning.
- sylens 4y ago
  Oh that’s disappointing. Looking through the blog post now it specifies console apps now - wonder if Web API support is coming later.
  - metaltyphoon 4y ago
    Yes, the next workload will include ASP.
- Kukumber 4y ago
  It'll be ready at some point, people at AWS experimented with it, they have a sample ready: https://github.com/awslabs/dotnet-nativeaot-labs https://github.com/awslabs/dotnet-nativeaot-labs

VancouverMan 4y ago

The article mentions things like: - "All required code is compiled and/or linked into the executable, ..." - "No JIT means no dynamic loading of arbitrary assemblies ..." - "... with everything compiled and linked into the app ..." This sounds very much like static linking, possibly with no option of dynamic linking/loading of code. Presumably this would have implications for those using LGPL-licensed .NET libraries, especially those who'd like to distributed closed-source applications AOT-compiled using this approach? Are there any commonly-used .NET libraries these days that are only LGPL-licensed? I haven't done .NET development in a decade, so I don't really know the current state of affairs.

yread 4y ago
Is there a difference between static or dynamic linking for LGPL?
- TingPing 4y ago
  Yes. The point of LGPL in concept is there is a clear boundary where you can modify and replace code. You can't replace a statically linked library.
  - jcelerier 4y ago
    And yet https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
    - TingPing 4y ago
      I don't think that conflicts with what I said. You have to be able to replace the library and them shipping linkable objects does that. Most static releases do not do this.
      - jcelerier 4y ago
        The proprietary ones which use LGPL libraries do - it's uncommon as it's a bit more work for the proprietary dev but it happens

pjmlp 4y ago

While NativeAOT is to be praised, we should not forget all the avenues that came before it. NGEN, Singularity and Midori research (whose tech landed on Windows 8 MDIL and UWP .NET Native respectively), Mono AOT. I always were the opinion that given Anders Hejlsberg background, .NET 1.0 should have had a better AOT story than NGEN.