8 ms·

> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Window

• victor106 2y ago
  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.
• parineum 2y ago
  They also severely underrate it's actual usage. For a non "major" language, there sure are a lot of jobs out there. .NET ain't hip.
  • deleted 2y ago
    [deleted]
  • briandear 2y ago
    .NET ain’t hip because many of the shops that use it are dinosaurs in processes and culture.
    • mlhpdx 2y ago
      And many are not. How many Python shops are living in the past? It’s the same problem everywhere.
      • realusername 2y ago
        I'd like this to be a lie but it's true, different languages have different cultures associated to them.
• shermantanktop 2y ago
  .NET suffers from the long lasting reputational taint of Microsoft. It was seen as the sworn enemy of open source and Linux, and for good reason. Today’s MS is not what it was back then. But long memories are not a bad thing, really. If .NET suffers a bit from some unfair perception, perhaps that can remind MS and others what happens when you take an aggressively adversarial approach.
  • mixmastamyk 2y ago
    They may be much less Linux-hostile today, but are still plenty user-hostile. Not to mention their lackadaisical security record.
    • cebert 2y ago
      Can you please highlight some examples of .NET’s lackadaisical security record? I’m curious for my own awareness.
      • mixmastamyk 2y ago
        Microsoft's. Consult your favorite search engine.
        • CharlieDigital 2y ago
          You might be interested in GitHub's State of the Octoverse report from 2020 that had a section dedicated to security of popular languages, active open source projects on GH with those languages, and the package managers for those platforms. https://octoverse.github.com/2020/ https://octoverse.github.com/2020/
          • mixmastamyk 2y ago
            Microsoft's security record. Not one package manager. https://arstechnica.com/security/2024/01/microsoft-network-breached-through-password-spraying-by-russian-state-hackers/ https://arstechnica.com/security/2024/01/microsoft-network-b...
• arccy 2y ago
  It wasn't good enough for the typescript rewrite...
  • bjoli 2y ago
    Mostly because they didnt consider the AOT compilation mature enough.
    • int_19h 2y ago
      Actually, the reason why they went with Go rather than C# is because they wanted to port the existing code as much as possible rather than rewriting from scratch. And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.
      • CharlieDigital 2y ago
        > And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically. Are there examples of this? I ask because I've been working on a Nest.js backend in TS and it's remarkably similar to C# .NET Web APIs (controllers, classes, DI). Really curious to see the translation from TS to Go.
        • neonsunset 2y ago
          TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole. There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
          • CharlieDigital 2y ago
            Got it; thanks for the tip!
• shepherdjerred 2y ago
  Why would I use C# over any other language though?
  • CharlieDigital 2y ago
    It's very productive and kinda nice. Especially for big backend APIs: https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/
  • jayd16 2y ago
    C# has a strong high level feature set and lower level tools to keep performance up. The language itself is well designed and consistent. Its able to mix functional and OO features without being dogmatic, leading to better dev-x over all. ASP is actually very good these days and feels cleaner than Spring Boot. There's less choice but the available choices are good. It has arguably the best gRPC implementation. It's just a nice experience over all.
    • deleted 2y ago
      [deleted]
  • hu3 2y ago
    LINQ alone is unmatched.
    • CharlieDigital 2y ago
      Addendum: having `Expression`[0] type representing the expression tree is a really killer feature. I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs. [0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/expression-trees/ https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
      • fireant 2y ago
• OkGoDoIt 2y ago
  I’ve been a .Net developer since it launched, but recently I find myself using it less and less. I’m so much more productive with LLM assistance and they aren’t very good at C#. (Seriously, I thought AI coding was all exaggeration until I switched to Python and realized what the hype was all about, these language models are just so much more optimized for python) Plus now Microsoft is being a bully when it comes to Cursor and the other VS Code forks, and won’t let the .net extensions work. I jumped through a lot of hoops but they keep finding ways to break it. I don’t want an adversarial relationship with my development stack. I miss C# and I really don’t like Python as a language, but I don’t see myself doing a lot more C# in the future if these trends continue.
  • epolanski 2y ago
    Have you given C# a new try with Cursor and newer models? There's a huge difference from Copilot in 2023, if that was your example. Also, interesting you feel more productive on a language you don't even like than your "main" one.
  • seunosewa 2y ago
    You can use VS Code and cursor at the same time. One to code and the other to compile the code. That's how I build for Android. I generate code in Cursor/Windsurf then I compile and deploy using Android Studio.
• lmm 2y ago
  It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating the languages.
  • CharlieDigital 2y ago
    Definitely not Windows-first. Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets. This mis-perception is so irrational and not based on any facts.
    • LtWorf 2y ago
      Just because .NET is what you know best, doesn't necessarily mean it's the best in all use cases. You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.
      • CharlieDigital 2y ago
        I don't think I've ever said it was good for all use cases and probably said to the contrary. I write it very explicitly here[0]: > Should you use C# for web front-ends? > > We're only considering backends here; I do not think that .NET-based front-ends (e.g. Blazor) are competitive in all use cases. We are in a thread about...backend application servers. Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job. [0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html#a-bit-of-background https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a... [1] https://github.com/CharlieDigital/coderev https://github.com/CharlieDigital/coderev
        • LtWorf 2y ago