4 ms·

You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizega

You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizegame Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.

pjmlp 2y ago
Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.
- neonsunset 2y ago
  What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET. I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming. When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works. For example https://github.com/codr7/sharpl https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable. [0]: https://github.com/U8String/U8String/blob/main/Examples/Interop/CSharp/CSharp.csproj#L31 https://github.com/U8String/U8String/blob/main/Examples/Inte...
  - pjmlp 2y ago
    As you are well aware, I know .NET since it was "partners only beta software", so dealing with "dotnet publish" plus csproj configuration, is still way easier than something like NGEN. However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". Which is the experience I think the team should strive on as goal, especially for newcomers. More so when comparing IDE experience of something like Delphi or Swift to keep it in context (press build), versus Visual Studio (besides csproj, create publish properties file, followed by a solution publish, which is hardly documented still).
    - neonsunset 2y ago
      > However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". But...it works in this exact way? dotnet publish -o folder -p:PublishAot=true Does not need -p argument either, as noted in the previous comment, if `PublishAot` is specified in .csproj, like with any AOT template (e.g. dotnet new console --aot or dotnet new webapiaot). On Visual Studio, I have started to recommend to newcomers to avoid its publishing UI which is convoluted and is easy to get side-tracked with. CLI offers much cleaner UX. Not that it matters outside of Windows. But you don't need to create publish file either, just tick the boxes you care about in the modal window. Edit: you can't be serious, no one in their sane mind would consider a single extra keyword to get the final product once you're done writing code a learning curve too steep, unless you're in a bad mood and want to make a bad faith argument. Consider what you make the comparison against - C and C++ with their CMake, Ninja, or even raw MSBuild, Swift is barely better too. Rust with Cargo is about the same amount of effort as .NET CLI. Cmon, Pjmlp.
      - pjmlp 2y ago
        Publish versus build, yet another step, another concept to learn. CLI only isn't the answer, if you want better adoption.
  - Measter 2y ago
    How are build times for AOT these days? Last time I tried it (~2019) it was slower than Rust at building the same project.

pjmlp 2y ago

Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.

neonsunset 2y ago
What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET. I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming. When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works. For example https://github.com/codr7/sharpl https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable. [0]: https://github.com/U8String/U8String/blob/main/Examples/Interop/CSharp/CSharp.csproj#L31 https://github.com/U8String/U8String/blob/main/Examples/Inte...
- pjmlp 2y ago
  As you are well aware, I know .NET since it was "partners only beta software", so dealing with "dotnet publish" plus csproj configuration, is still way easier than something like NGEN. However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". Which is the experience I think the team should strive on as goal, especially for newcomers. More so when comparing IDE experience of something like Delphi or Swift to keep it in context (press build), versus Visual Studio (besides csproj, create publish properties file, followed by a solution publish, which is hardly documented still).
  - neonsunset 2y ago
    > However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". But...it works in this exact way? dotnet publish -o folder -p:PublishAot=true Does not need -p argument either, as noted in the previous comment, if `PublishAot` is specified in .csproj, like with any AOT template (e.g. dotnet new console --aot or dotnet new webapiaot). On Visual Studio, I have started to recommend to newcomers to avoid its publishing UI which is convoluted and is easy to get side-tracked with. CLI offers much cleaner UX. Not that it matters outside of Windows. But you don't need to create publish file either, just tick the boxes you care about in the modal window. Edit: you can't be serious, no one in their sane mind would consider a single extra keyword to get the final product once you're done writing code a learning curve too steep, unless you're in a bad mood and want to make a bad faith argument. Consider what you make the comparison against - C and C++ with their CMake, Ninja, or even raw MSBuild, Swift is barely better too. Rust with Cargo is about the same amount of effort as .NET CLI. Cmon, Pjmlp.
    - pjmlp 2y ago
      Publish versus build, yet another step, another concept to learn. CLI only isn't the answer, if you want better adoption.
- Measter 2y ago
  How are build times for AOT these days? Last time I tried it (~2019) it was slower than Rust at building the same project.