4 ms·

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

CharlieDigital 2y ago
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.
homebrewer 2y ago
If your code does not rely on native libraries, or you're fine with shipping multiple copies for different operating systems, a single build works everywhere with dotnet installed. Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch of files which you can then then package up into a zip file.
- actionfromafar 2y ago
  How do you cross compile from linux to macos?
  - orphea 2y ago
    dotnet publish -r osx-x64 --self-contained https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained https://learn.microsoft.com/en-us/dotnet/core/deploying/#pub...
    - mlhpdx 2y ago
      Just like for windows or Linux, in other words. The dotnet tooling is amazingly friction and ceremony free these days.
  - neonsunset 2y ago
    JIT deployments do not care where they get built on. AOT deployments do because they use OS-provided linker to produce the final binary, much like C++ and Rust do (unless you use PublishAotCross nuget package which uses Zig toolchain to allow you to build Linux binaries from under Windows, I'm sure if someone's interested it could be extended further) Also, if you want to have just a single binary, you want to do 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' instead. Self-contained build means it just ships everything needed to run in a folder without merging the assembly files or without trimming unreachable code and standard library components.
artimaeis 2y ago
I'm a dabbler in Go, far from an expert. But I'm not familiar with a capability to use, say, native MacOS platform libraries from a go app that I'm compiling in Windows/Linux without using a VM of some sort to compile it. If that's possible I'd love to learn more.
- hnlmorg 2y ago
  If you’re calling against shared libraries using cgo then things are a little more tricky, but still doable. But if it’s native Go code, then cross platform compiling is just an a few environmental variables GOOS=darwin GOARCH=arm64
dismalaf 2y ago
Mono's been on Linux for like 20 years, maybe longer... C# is like Java, can run basically anywhere.
- LtWorf 2y ago
  I think being on linux and being decent on linux are not the same, and there's .net problem.
  - neonsunset 2y ago
    Can you link to anything recent which could support your argument?
    - LtWorf 2y ago
      https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.start?view=net-9.0#system-diagnostics-process-start(system-string-system-string-system-string-system-security-securestring-system-string) https://learn.microsoft.com/en-us/dotnet/api/system.diagnost... Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example. Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
      - neonsunset 2y ago
        I'm not sure why you are reading the docs sideways but just in case - C# has method overloading. Process API, while dated, simply offers multiple overloads suitable for different scenarios. Launching a new process can be as easy as `Process.Start(path, args)`. Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman. > you find out that .net is not included by any linux distribution Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way). Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
andygocke 2y ago
Hi, I own the Native AOT compiler and self-contained compiler for .NET. Self-contained will work fine because we precompile the runtime and libraries for all supported platforms. Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default. Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc). Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.

CharlieDigital 2y ago

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.

homebrewer 2y ago

If your code does not rely on native libraries, or you're fine with shipping multiple copies for different operating systems, a single build works everywhere with dotnet installed. Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch of files which you can then then package up into a zip file.

actionfromafar 2y ago
How do you cross compile from linux to macos?
- orphea 2y ago
  dotnet publish -r osx-x64 --self-contained https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained https://learn.microsoft.com/en-us/dotnet/core/deploying/#pub...
  - mlhpdx 2y ago
    Just like for windows or Linux, in other words. The dotnet tooling is amazingly friction and ceremony free these days.
- neonsunset 2y ago
  JIT deployments do not care where they get built on. AOT deployments do because they use OS-provided linker to produce the final binary, much like C++ and Rust do (unless you use PublishAotCross nuget package which uses Zig toolchain to allow you to build Linux binaries from under Windows, I'm sure if someone's interested it could be extended further) Also, if you want to have just a single binary, you want to do 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' instead. Self-contained build means it just ships everything needed to run in a folder without merging the assembly files or without trimming unreachable code and standard library components.

artimaeis 2y ago

I'm a dabbler in Go, far from an expert. But I'm not familiar with a capability to use, say, native MacOS platform libraries from a go app that I'm compiling in Windows/Linux without using a VM of some sort to compile it. If that's possible I'd love to learn more.

hnlmorg 2y ago
If you’re calling against shared libraries using cgo then things are a little more tricky, but still doable. But if it’s native Go code, then cross platform compiling is just an a few environmental variables GOOS=darwin GOARCH=arm64

dismalaf 2y ago

Mono's been on Linux for like 20 years, maybe longer... C# is like Java, can run basically anywhere.

LtWorf 2y ago
I think being on linux and being decent on linux are not the same, and there's .net problem.
- neonsunset 2y ago
  Can you link to anything recent which could support your argument?
  - LtWorf 2y ago
    https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.start?view=net-9.0#system-diagnostics-process-start(system-string-system-string-system-string-system-security-securestring-system-string) https://learn.microsoft.com/en-us/dotnet/api/system.diagnost... Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example. Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
    - neonsunset 2y ago
      I'm not sure why you are reading the docs sideways but just in case - C# has method overloading. Process API, while dated, simply offers multiple overloads suitable for different scenarios. Launching a new process can be as easy as `Process.Start(path, args)`. Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman. > you find out that .net is not included by any linux distribution Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way). Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)

andygocke 2y ago

Hi, I own the Native AOT compiler and self-contained compiler for .NET. Self-contained will work fine because we precompile the runtime and libraries for all supported platforms. Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default. Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc). Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.