5 ms·

Yes, it can. I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better). Last startup, we shipped AWS t4g Arm64 and GCP x6

Yes, it can. I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better). Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code. Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C#/.NET has been capable of cross platform binaries for close to a decade? I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html#common-myths https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...

pjc50 2y ago
Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... "Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL." Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported. (this comment is correct: https://news.ycombinator.com/item?id=43388962 https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)
- CharlieDigital 2y ago
  > Native AOT does not support cross-OS compilation > ...runtime-dependent and self-contained are fine This certainly reads like you moved the goal posts and recognized it.
  - bheadmaster 2y ago
    Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.
    - TeMPOraL 2y ago
      An image or a container could be, yes. It isn't, because Docker stuff is mostly distributed as Dockerfiles and docker-compose files, and those cause your system to download and install stuff, and that part is not like self-contained package.
  - chronogram 2y ago
    The original question did ask about creating executables like Go, which means a single file you can run as is, so it was fair to mention AOT. For servers etc you usually don't want the AOT version, so then it doesn't matter which platform you develop on, but it's not always just like Go when you want to ship little applications.
    - CharlieDigital 2y ago
      The context of the thread is HTTP/3 servers; would it not make sense to take the comment in that context? Original article mentions that browsers (the client side) already supports HTTP/3 with the application server ecosystem being the missing piece.
  - pjc50 2y ago
    More that there are at least three different ways to deploy things in dotnet, and only AOT is directly equivalent to Go executables. I like dotnet and use it at work but this is a nuisance limitation for us.
neonsunset 2y ago
I don't know why we're trying anymore. You're not going to convince someone who is looking for a way to make something not work however minor it is and not the other way around.

pjc50 2y ago

Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... "Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL." Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported. (this comment is correct: https://news.ycombinator.com/item?id=43388962 https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)

CharlieDigital 2y ago
> Native AOT does not support cross-OS compilation > ...runtime-dependent and self-contained are fine This certainly reads like you moved the goal posts and recognized it.
- bheadmaster 2y ago
  Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.
  - TeMPOraL 2y ago
    An image or a container could be, yes. It isn't, because Docker stuff is mostly distributed as Dockerfiles and docker-compose files, and those cause your system to download and install stuff, and that part is not like self-contained package.
- chronogram 2y ago
  The original question did ask about creating executables like Go, which means a single file you can run as is, so it was fair to mention AOT. For servers etc you usually don't want the AOT version, so then it doesn't matter which platform you develop on, but it's not always just like Go when you want to ship little applications.
  - CharlieDigital 2y ago
    The context of the thread is HTTP/3 servers; would it not make sense to take the comment in that context? Original article mentions that browsers (the client side) already supports HTTP/3 with the application server ecosystem being the missing piece.
- pjc50 2y ago
  More that there are at least three different ways to deploy things in dotnet, and only AOT is directly equivalent to Go executables. I like dotnet and use it at work but this is a nuisance limitation for us.

neonsunset 2y ago

I don't know why we're trying anymore. You're not going to convince someone who is looking for a way to make something not work however minor it is and not the other way around.