4 ms·

Not all software has a GUI. I've recently started working on a cross platform command line application using .NET 7 and am honestly impressed with the experienc

Not all software has a GUI. I've recently started working on a cross platform command line application using .NET 7 and am honestly impressed with the experience.

dgellow 3y ago
How are .Net startup times for your tool, and how do you package your tool? I like modern C# a lot, but would not pick .Net for a CLI tool due to the slow startup times I experienced compared to rust or go. And packaging the runtime has always felt a bit too annoying compared to a native compilation. I would be interested to learn if you had a good experience, I haven’t dealt with .Net CLI apps since a while, I’m sure things improved.
- kcartlidge 3y ago
  There's no startup time overhead now for my stuff as all my web servers, apis, and command line tooling (.Net CLI apps) are built (by the standard dotnet tooling) into cross-platform stand-alone binaries. They are native code and generally between around 11MB and 20MB depending upon what they do.
- qingcharles 3y ago
  Aren't there plenty of tools to compile down to native? I'm always seeing stuff on the Microsoft blogs about options for doing this which I've not looked at.
  - dgellow 3y ago
    I didn’t follow the last year, from what I remember the AOT was still fairly experimental? Edit: I read the docs, seems to be available with .net 8 if I understand correctly https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
- tailspin2019 3y ago
  If your memory of start up times is based on .NET Framework or Mono, then things have come a very long way since .NET Core onwards. I’ve never experienced any startup time delays at all with recent .NET development, even when running on underpowered cloud VMs. Nothing that would have any tangible real world effect anyway. There are also lots of optimisations available now and much more work is being done to reduce binary sizes, AOT etc

Not all software has a GUI. I've recently started working on a cross platform command line application using .NET 7 and am honestly impressed with the experience.

dgellow 3y ago

How are .Net startup times for your tool, and how do you package your tool? I like modern C# a lot, but would not pick .Net for a CLI tool due to the slow startup times I experienced compared to rust or go. And packaging the runtime has always felt a bit too annoying compared to a native compilation. I would be interested to learn if you had a good experience, I haven’t dealt with .Net CLI apps since a while, I’m sure things improved.

kcartlidge 3y ago
There's no startup time overhead now for my stuff as all my web servers, apis, and command line tooling (.Net CLI apps) are built (by the standard dotnet tooling) into cross-platform stand-alone binaries. They are native code and generally between around 11MB and 20MB depending upon what they do.
qingcharles 3y ago
Aren't there plenty of tools to compile down to native? I'm always seeing stuff on the Microsoft blogs about options for doing this which I've not looked at.
- dgellow 3y ago
  I didn’t follow the last year, from what I remember the AOT was still fairly experimental? Edit: I read the docs, seems to be available with .net 8 if I understand correctly https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
tailspin2019 3y ago
If your memory of start up times is based on .NET Framework or Mono, then things have come a very long way since .NET Core onwards. I’ve never experienced any startup time delays at all with recent .NET development, even when running on underpowered cloud VMs. Nothing that would have any tangible real world effect anyway. There are also lots of optimisations available now and much more work is being done to reduce binary sizes, AOT etc