7 ms·

I've been using C# with recent features like Function Pointers, [UnmanagedCallersOnly], Dotnet Native Exports, etc Have been writing C# to interact with C/C++

I've been using C# with recent features like Function Pointers, [UnmanagedCallersOnly], Dotnet Native Exports, etc Have been writing C# to interact with C/C++ and publishing C ABIs as static/shared libs that are natively compiled My mind has been absolutely blown with what modern .NET and C# are capable of doing in terms of low level/systems program and interop with C/C++/Rust etc. The performance and object sizes are killer too. I think most people don't know or think C#/.NET are capable of this Can envision a not so distant future where C# is a common choice for places when you'd typically reach for C++ Also, the folks on the .NET Interop team are all super friendly and willing to have a conversation with you or answer questions. My experiences with the whole .NET organization at MS as a random person has been nothing short of shockingly pleasant.

attractivechaos 5y ago
I really like C# as a language, but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission. With that barrier, I can't recommend C# over Java, D or Go which are much easier to install.
- cebert 5y ago
  You don’t need to install the SDK to run a dotnet core app. They can ship what’s required to run and there’s even single executable options now as well.
  - spaetzleesser 5y ago
    One caveat: If you ship a self contained app you often end up with 200MB of assemblies to ship. and the single file executables tend to load very slowly. It's basically an archive that first gets extracted and then executed. I had to give that up with a recent app because it was just too slow.
    - kqr 5y ago
      Yes, this deployment option makes tradeoffs that are clearly more in line with the use case of pushing out long-running server applications to machines with minimal configuration, rather than for desktop user applications.
      - spaetzleesser 5y ago
        That’s my impression too. Seems these days in general desktop applications are more of an afterthought in the .NET world and most new features are built mainly for server stuff.
    - GordonS 5y ago
      This hasn't actually been the case since dotnet Core 2. Since dotnet Core 3, you can use assembly trimming to remove unused assemblies. That results in a package of around 10MB for a Hello World app, or more like 40-70MB for large, real-world apps. From dotnet 5 there is also member trimming, which will trim unused parts of assemblies, which will further reduce the size. I haven't used this yet, but Microsoft claim it can result in packages 5x smaller than with assembly trimming, e.g. only 2MB for a Hello World app. There is also AOT compilation, but I wouldn't hold my breath on seeing that become production-ready any time soon (Microsoft have been hyping it and saying it's "coming soon" for 10 years or so).
      - Measter 5y ago
        I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x64, ready to run. I built in release mode with publish trimmed, and trim mode set to link. The final size of the binary is 24.6 MB (not counting CLR DLLs), with a build time of 23.2[1] seconds. I also have a Rust version of the project. 710 lines of Rust[0], 128 total dependencies in the tree, building in release mode with the MSVC Windows compiler. Final size of the binary is 2.29 MB, build time of 22.2[1] seconds. Things are not great when your build times rival Rust's, and the output is slower and an order of magnitude bigger. [0] Note that the C# version does have more robust handling when writing its output file than the Rust version, which adds couple dozen lines. Also the style conventions for brackets puts opening brackets on a new line for C#, the same line for Rust. [1] Measured with hyperfine configured to run "dotnet clean -c Release" and "cargo clean" before each run.
- josteink 5y ago
  > but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission It’s a tarball. Unpack it wherever you like. What exact problems did you have? Edit: I’ve even “installed” the .NET SDK on ARM/Aarch64 devices this way. Zero issues.
  - attractivechaos 5y ago
    The lack of the ICU library. As you mention it, I searched around and found setting "export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true" could solve the problem. I stand corrected. Nonetheless, adding an env variable is still an extra step especially when the dotnet cli doesn't tell you what to do. An enduser has to google around to find the answer.
    - BuckRogers 5y ago
      >An enduser has to google around to find the answer. Welcome to Linux?? Not to be sarcastic but if you want your hand held install Windows for your .Net development. It's pretty nice over there.
      - jsight 5y ago
        > Welcome to Linux?? Maybe more like, "Welcome to MS tools on Linux?" There are no similar issues with installing a JDK, for example.
        josteink 5y ago
        The OP is complaining about needing root to satisfy som third-party library dependency (libicu) when installing the .NET SDK outside the system package-manager, with the tarball only. I think that’s a pretty far fetched complaint. There are tons of software out there on Linux which will break if you don’t satisfy their dependencies. I’m sure the OpenJDK-tarball has some system-wide dependencies too (libssl?), but you can’t tell that because you probably installed it as root, using a package-manager instead. If you do the same with the .NET SDK (use root, install via package-manager) you will find everything working equally smooth.
- boudin 5y ago
  You can use dotnet-install for that https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...
- e12e 5y ago
  Of all the possible ways to handle toolchains on Linux, I'm quite happy with asdf[1]. I've successfully built stand-alone fsharp/csharp "Hello worlds" off of dotnet via asdf - but I've not used dot.net in anger. I chiefly like asdf because I typically need at least two toolchains (with various versions for various projects) - eg ruby and nodejs, or python and nodejs. https://asdf-vm.com/ https://asdf-vm.com/ https://github.com/emersonsoares/asdf-dotnet-core https://github.com/emersonsoares/asdf-dotnet-core
pjmlp 5y ago
Actually several of those features exist since version 1.0, because the CLR was designed to support languages like C++ as well, so there was always a way to access them even those that are only exposed after 7, but yeah bad M$.
- pjmlp 5y ago
  Apparently the remark I made to how people lose good tooling due to needless religious hate was lost in the crowd, oh well, better improve my English skills.
bob1029 5y ago
> The performance and object sizes are killer too. > I think most people don't know or think C#/.NET are capable of this Take all of this amazing stuff and it also works on embedded/raspi4... I have been playing around with using C#8 to directly drive & sample GPIO. Who needs timer ICs when you have a busywait while loop checking the high res timer... Also, don't forget that you can go open an issue or submit a PR to any of the major .NET repositories right now, and expect to have your work (assuming accepted) incorporated into an official .NET release within a year or so. And tooling, etc. Check out visual studio 2022. Its available in preview now.
- bb88 5y ago
  > Who needs timer ICs when you have a busywait while loop checking the high res timer... A lot of people are concerned about power usage these days, particularly if these things are running off a solar cell. And these days, most embedded controllers include some kind of timer anyway. Micropython has a timer interface that interrupts into a python subroutine. I use this for application level routines interfacing with a hardware watchdog.
  - jbluepolarbear 5y ago
    Why couldn’t you do the same thing with C#? Being worried about power is fine and all, but I’d rather build the application and then analyze the actual performance and power draw to determine the appropriate solution for power efficiency. I’m sure there’s some WFI (wait for interrupt) available that could be used to solve this.
    - bb88 5y ago
      There's nothing wrong with C# -- as long as the tooling supports the processor you're targeting and the interrupt/sleep states of the micro. If you're running off a battery say, then it's better to build your software from the start to optimize for the various sleep modes. https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ https://lastminuteengineers.com/esp32-sleep-modes-power-cons...
- 5y ago
pjc50 5y ago
C# native interop is very, very nice. However, the build/package system for this is still a complete mess if you want to target more than one architecture; I've spent much of the week looking at the question of how to make cross-platform assembly A depend on platform-specific assembly B, where B is one of B-win or B-mac, and it seems to require carefully hand building B into a nuget package. I'm coming to appreciate msbuild, though. Or maybe that's Stockholm syndrome.
- guhidalg 5y ago
  I second MSBuild as one of the best build systems I’ve had to work with. It absolutely has a learning curve but once you “get” how projects are evaluated and executed then you can start writing your own targets to do whatever you want.
  - R0b0t1 5y ago
    MSBuild is very poorly documented. MSBuild is really not that good compared to what you get in FOSS land. I favor CMake over it, and personally I very much dislike CMake. The main thing in favor of CMake is you get cross platform.
    - pjc50 5y ago
      The "core" of msbuild - targers, items, properties - is well documented. The actual work in normal cases is done by the vast hinterland of pre defined targets, and it's those that are badly documented. I've wasted several days reverse engineering 'ProjectReference' and only just found its detailed documentation. Fortunately you can read the source; unfortunately when you have to. I think making it open source has come with a cultural change that's still propagating. It means not just defining the "Microsoft way" to do things but coping with myriad use cases turning up in the issue tracker.
      - eyegor 5y ago
        If you think the "core" is well documented, link me the documentation which lays out all the built in targets involved in a standard c# project. Or even just a doc which describes the differences between PreBuildEvent, BeforeBuild, BeforeCompile, etc. As far as I can tell, this only exists as occasional comments in the .targets file. Msbuild documentation is horrible, without exception. When they occasionally document something it tends to miss half the optional flags and they never link the source code so it's up to you to find and correct it.
nonbirithm 5y ago
I like C# as a language. It's boring and gets the job done. But I will say I was disappointed after trying to set up a C# development environment on Linux after having such a positive experience with the language on Windows. It sounded like it was a reasonable thing to expect to work since apparently Microsoft supports Linux these days, but I couldn't see it through. When the official editor (MonoDevelop) is abandoned for a proprietary version with no notice on the homepage or docs, and all that people recommend you instead is to "just install Ryder", which costs a large sum, it's hard to not just want to go back to a language that has a more open ecosystem.
- wilsonfiifi 5y ago
  Working with C# on Linux isn't too bad if you use VSCode. You have to do a bit more manual work and it's not as smooth sailing as with Visual studio or visual studio for Mac but it gets the job done. I used it to work on an Aspose Words api for a reporting tool. Scott Hanselman has a couple of guides on his blog on how to get it up and running.
  - jh86 5y ago
    VS code is not really that “open” either. The on-by-default telemetry and license restrictions come to mind
    - alykhalid 5y ago
      This might be helpful. https://github.com/VSCodium/vscodium https://github.com/VSCodium/vscodium It is a repository of scripts to automatically build Microsoft's 'vscode' repository into freely-licensed binaries with a community-driven default configuration.
      - jh86 5y ago
        I believe the license for the VScode C# plug-in prohibits using it with VScodium. I didn’t know this until recently when someone pointed it out. https://github.com/dotnet/core/issues/505 https://github.com/dotnet/core/issues/505 Thought it was relevant since OP is talking about a Linux IDE for C#

attractivechaos 5y ago

I really like C# as a language, but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission. With that barrier, I can't recommend C# over Java, D or Go which are much easier to install.

cebert 5y ago
You don’t need to install the SDK to run a dotnet core app. They can ship what’s required to run and there’s even single executable options now as well.
- spaetzleesser 5y ago
  One caveat: If you ship a self contained app you often end up with 200MB of assemblies to ship. and the single file executables tend to load very slowly. It's basically an archive that first gets extracted and then executed. I had to give that up with a recent app because it was just too slow.
  - kqr 5y ago
    Yes, this deployment option makes tradeoffs that are clearly more in line with the use case of pushing out long-running server applications to machines with minimal configuration, rather than for desktop user applications.
    - spaetzleesser 5y ago
      That’s my impression too. Seems these days in general desktop applications are more of an afterthought in the .NET world and most new features are built mainly for server stuff.
  - GordonS 5y ago
    This hasn't actually been the case since dotnet Core 2. Since dotnet Core 3, you can use assembly trimming to remove unused assemblies. That results in a package of around 10MB for a Hello World app, or more like 40-70MB for large, real-world apps. From dotnet 5 there is also member trimming, which will trim unused parts of assemblies, which will further reduce the size. I haven't used this yet, but Microsoft claim it can result in packages 5x smaller than with assembly trimming, e.g. only 2MB for a Hello World app. There is also AOT compilation, but I wouldn't hold my breath on seeing that become production-ready any time soon (Microsoft have been hyping it and saying it's "coming soon" for 10 years or so).
    - Measter 5y ago
      I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x64, ready to run. I built in release mode with publish trimmed, and trim mode set to link. The final size of the binary is 24.6 MB (not counting CLR DLLs), with a build time of 23.2[1] seconds. I also have a Rust version of the project. 710 lines of Rust[0], 128 total dependencies in the tree, building in release mode with the MSVC Windows compiler. Final size of the binary is 2.29 MB, build time of 22.2[1] seconds. Things are not great when your build times rival Rust's, and the output is slower and an order of magnitude bigger. [0] Note that the C# version does have more robust handling when writing its output file than the Rust version, which adds couple dozen lines. Also the style conventions for brackets puts opening brackets on a new line for C#, the same line for Rust. [1] Measured with hyperfine configured to run "dotnet clean -c Release" and "cargo clean" before each run.
josteink 5y ago
> but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission It’s a tarball. Unpack it wherever you like. What exact problems did you have? Edit: I’ve even “installed” the .NET SDK on ARM/Aarch64 devices this way. Zero issues.
- attractivechaos 5y ago
  The lack of the ICU library. As you mention it, I searched around and found setting "export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true" could solve the problem. I stand corrected. Nonetheless, adding an env variable is still an extra step especially when the dotnet cli doesn't tell you what to do. An enduser has to google around to find the answer.
  - BuckRogers 5y ago
    >An enduser has to google around to find the answer. Welcome to Linux?? Not to be sarcastic but if you want your hand held install Windows for your .Net development. It's pretty nice over there.
    - jsight 5y ago
      > Welcome to Linux?? Maybe more like, "Welcome to MS tools on Linux?" There are no similar issues with installing a JDK, for example.
      - josteink 5y ago
        The OP is complaining about needing root to satisfy som third-party library dependency (libicu) when installing the .NET SDK outside the system package-manager, with the tarball only. I think that’s a pretty far fetched complaint. There are tons of software out there on Linux which will break if you don’t satisfy their dependencies. I’m sure the OpenJDK-tarball has some system-wide dependencies too (libssl?), but you can’t tell that because you probably installed it as root, using a package-manager instead. If you do the same with the .NET SDK (use root, install via package-manager) you will find everything working equally smooth.
boudin 5y ago
You can use dotnet-install for that https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...
e12e 5y ago
Of all the possible ways to handle toolchains on Linux, I'm quite happy with asdf[1]. I've successfully built stand-alone fsharp/csharp "Hello worlds" off of dotnet via asdf - but I've not used dot.net in anger. I chiefly like asdf because I typically need at least two toolchains (with various versions for various projects) - eg ruby and nodejs, or python and nodejs. https://asdf-vm.com/ https://asdf-vm.com/ https://github.com/emersonsoares/asdf-dotnet-core https://github.com/emersonsoares/asdf-dotnet-core

pjmlp 5y ago

Actually several of those features exist since version 1.0, because the CLR was designed to support languages like C++ as well, so there was always a way to access them even those that are only exposed after 7, but yeah bad M$.

pjmlp 5y ago
Apparently the remark I made to how people lose good tooling due to needless religious hate was lost in the crowd, oh well, better improve my English skills.

bob1029 5y ago

> The performance and object sizes are killer too. > I think most people don't know or think C#/.NET are capable of this Take all of this amazing stuff and it also works on embedded/raspi4... I have been playing around with using C#8 to directly drive & sample GPIO. Who needs timer ICs when you have a busywait while loop checking the high res timer... Also, don't forget that you can go open an issue or submit a PR to any of the major .NET repositories right now, and expect to have your work (assuming accepted) incorporated into an official .NET release within a year or so. And tooling, etc. Check out visual studio 2022. Its available in preview now.

bb88 5y ago
> Who needs timer ICs when you have a busywait while loop checking the high res timer... A lot of people are concerned about power usage these days, particularly if these things are running off a solar cell. And these days, most embedded controllers include some kind of timer anyway. Micropython has a timer interface that interrupts into a python subroutine. I use this for application level routines interfacing with a hardware watchdog.
- jbluepolarbear 5y ago
  Why couldn’t you do the same thing with C#? Being worried about power is fine and all, but I’d rather build the application and then analyze the actual performance and power draw to determine the appropriate solution for power efficiency. I’m sure there’s some WFI (wait for interrupt) available that could be used to solve this.
  - bb88 5y ago
    There's nothing wrong with C# -- as long as the tooling supports the processor you're targeting and the interrupt/sleep states of the micro. If you're running off a battery say, then it's better to build your software from the start to optimize for the various sleep modes. https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ https://lastminuteengineers.com/esp32-sleep-modes-power-cons...
5y ago

pjc50 5y ago

C# native interop is very, very nice. However, the build/package system for this is still a complete mess if you want to target more than one architecture; I've spent much of the week looking at the question of how to make cross-platform assembly A depend on platform-specific assembly B, where B is one of B-win or B-mac, and it seems to require carefully hand building B into a nuget package. I'm coming to appreciate msbuild, though. Or maybe that's Stockholm syndrome.

guhidalg 5y ago
I second MSBuild as one of the best build systems I’ve had to work with. It absolutely has a learning curve but once you “get” how projects are evaluated and executed then you can start writing your own targets to do whatever you want.
- R0b0t1 5y ago
  MSBuild is very poorly documented. MSBuild is really not that good compared to what you get in FOSS land. I favor CMake over it, and personally I very much dislike CMake. The main thing in favor of CMake is you get cross platform.
  - pjc50 5y ago
    The "core" of msbuild - targers, items, properties - is well documented. The actual work in normal cases is done by the vast hinterland of pre defined targets, and it's those that are badly documented. I've wasted several days reverse engineering 'ProjectReference' and only just found its detailed documentation. Fortunately you can read the source; unfortunately when you have to. I think making it open source has come with a cultural change that's still propagating. It means not just defining the "Microsoft way" to do things but coping with myriad use cases turning up in the issue tracker.
    - eyegor 5y ago
      If you think the "core" is well documented, link me the documentation which lays out all the built in targets involved in a standard c# project. Or even just a doc which describes the differences between PreBuildEvent, BeforeBuild, BeforeCompile, etc. As far as I can tell, this only exists as occasional comments in the .targets file. Msbuild documentation is horrible, without exception. When they occasionally document something it tends to miss half the optional flags and they never link the source code so it's up to you to find and correct it.

nonbirithm 5y ago

I like C# as a language. It's boring and gets the job done. But I will say I was disappointed after trying to set up a C# development environment on Linux after having such a positive experience with the language on Windows. It sounded like it was a reasonable thing to expect to work since apparently Microsoft supports Linux these days, but I couldn't see it through. When the official editor (MonoDevelop) is abandoned for a proprietary version with no notice on the homepage or docs, and all that people recommend you instead is to "just install Ryder", which costs a large sum, it's hard to not just want to go back to a language that has a more open ecosystem.

wilsonfiifi 5y ago
Working with C# on Linux isn't too bad if you use VSCode. You have to do a bit more manual work and it's not as smooth sailing as with Visual studio or visual studio for Mac but it gets the job done. I used it to work on an Aspose Words api for a reporting tool. Scott Hanselman has a couple of guides on his blog on how to get it up and running.
- jh86 5y ago
  VS code is not really that “open” either. The on-by-default telemetry and license restrictions come to mind
  - alykhalid 5y ago
    This might be helpful. https://github.com/VSCodium/vscodium https://github.com/VSCodium/vscodium It is a repository of scripts to automatically build Microsoft's 'vscode' repository into freely-licensed binaries with a community-driven default configuration.
    - jh86 5y ago
      I believe the license for the VScode C# plug-in prohibits using it with VScodium. I didn’t know this until recently when someone pointed it out. https://github.com/dotnet/core/issues/505 https://github.com/dotnet/core/issues/505 Thought it was relevant since OP is talking about a Linux IDE for C#