What the .NET team does on the technical side is almost universally wonderful. They've (ironically?) been a bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime.
But it's still a Microsoft project and their sword keeps looming over its head. There have been some heavy-handed anti-developer choices in the past and one can safely assume that that has been their EEE-genes kicking in and it will probably not get better, but worse, the more they build up a community they feel they have (or should have) control over.
Wouldn't want to dive into that pool.
.NET is only as good as the parts Microsoft doesn't have too much control over and that doesn't even include the VSCode extension (or VSCode itself - Use VSCodium and you'll see).
> bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime
But there was plenty of serious alternative languages running on the JVM? Scala, Kotlin, Clojure. All of which have more adoption than F#.
> They've (ironically?) been a bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime.
Can you explain more? I'm less familiar with the .net side of things.
not OP, but I'd guess they are referring to F# and C# interoperability. It's trivial to call into each other from within the same project. I'm not as familiar with this on the JVM side myself. How easy/common is it to have multi-language projects? Because in .NET it's very common to have C# interface to F# projects and vice versa with minimal work.
makes me remember about that meme where it depicts microsoft as an org with many divisions pointing guns at each other. devdiv is the good guys while sales dept. is the hated one.
This is what I use, but damn, does it make coding a bit annoying having to have an instance of the filesystem rather than using static classes like Path.
2MB for a standalone “Hello World” binary in C# is a similar size to one in Go. Do both languages produce similar-sized binaries for larger projects as well?
If so, would C# be a good choice for writing cross-platform command-line applications?
It seems that C# can produce easily-distributable binaries, while also hitting a sweet-spot in language design - not super complex like C++ or Rust, and also not overly simplistic like C or Go.
When Go first came out, it was better than C# in terms of support for concurrency, stand-alone binaries, and cross-platform. It seems that C# has done a lot of catching up since then, though.
I have not begun really using Go in earnest yet, but at least in the cloud engineering world it seems to be the language of choice (along with Python) due to the ease of using its concurrency capabilities
Because it was made to run on Linux from the start. I remember being excited to work with .net core on Linux, then discovering that most of the system libraries for network programming and related were either not implemented or badly working, but you would only find out if dug deep into low level stuff. After that, I swore of using it seeing how much the hype for cross platform didn't match reality. Hopefully they fixed it, but seeing as there are other choices of languages, it wasn't so bad.
I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled, wasted an hour and insecured the target machine, and gave up finally).
I used SQLite, and the System.Data.SQLite, because reasons (legacy). It is a bug ridden piece of work (on linux), with no sane way to contribute. Also it is useless on M1 Mac, as the author doesn't give a shit about compiling it for arm (or setting up a CI pipeline on github or gitlab for example, where it is supported).
Had plenty of problems with single file app bundle deployment, as much as it eased deployment initially, lots of libraries broke on it.
It has been working okay for us (in other former projects) generally well, but personally I am missing some things from the JVM, where VM tuning and monitoring and remote debugging are all a smoother ride in my experience.
Oh, and async broke the C# language (or rather the standard library) and killed the CLR interop with other languages, it was a big mistake to release it with these defaults. I really like F#, but async everything made it uselessly difficult in my opinion. But it has nothing to with .Net on Linux. It works, and is way better than the nodejs world, but I think more ideas should be copied from the JVM world to ease the Ops side, or they should be more clearly communicated.
i just recently switched from VS 2022 remote to VS Code, (windows->linux, C++) and it works very well. i'm not sure i have many reasons to keep VS 2022 around right now
I once was CTO of a now defunct startup and we ran a C# backend against a postgres db inside Docker containers on Linux.
This was before MS was on board with Linux and all, but Mono was already super good tech. It wasn’t as fast as real .NET but it was still way faster than eg Python or Ruby, the popular backend languages of the day. There was even a half decent cross platform IDE (MonoDevelop), most of the dev team wasn’t on Windows.
I guess this is not very actionable knowledge anymore but I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today.
Somehow linux/mac people seem to avoid .NET out of sheer cultural avoidance, and Windows people seem to avoid most of the OSS ecosystem like the plague for awkward “i was at a .net conf and all the talks were about MS tech” reasons but actually the two combine really well. C# is a great language with unparalleled tooling. It’s easy to learn for people with nearly any background. It’s fast, it’s easy to refactor, it’s easy to debug and it runs everywhere. For over a decade now.
My current company runs Elixir because we’re a chat API and the BEAM’s parallelism/robustness story is uniquely suited to our product. If we’d be in a different domain I’d choose C# (on linux, with postgres) again in a heartbeat.
You're right, Mono was pretty good even in the very early days. I had a small C# Mono app deployed on macOS in a similar time period (possibly close to 10 years ago now) and I was amazed at how well it worked at the time.
It also felt like magic somehow, after having my .NET development tied to Windows for so long before that...
There were a lot of caveats then and quite some disparity in how it would run on Mono vs normal .NET Framework.
> I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today.
I am. I've been developing with .NET since the start and my current workflow is really the smoothest and most productive (and most enjoyable!) I've ever had:
I develop solely on Mac (JetBrains Rider), compiling/debugging Mac binaries locally - no containers - unless I need any external dependencies like eg. Postgres.
On M1 MacBook Pro the experience is blazing fast - and Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines).
Everything is built and tested on Linux (and sometimes Mac) runners in GitHub.
Then I deploy direct to cloud-based "disposable" Debian VMs. If it's a small/hobby project, I can get really great performance out of even the smallest VMs.
For those interested in the details; I most often run production .NET ASP.NET apps as a systemd service on Debian using the native/in-built .NET Kestrel web server, and almost always (currently) use Cloudflare Tunnel as a reverse proxy for ingress traffic. No inbound ports open in Linux. I've got multiple production systems running like this including some load-balanced using Cloudflare Tunnel load balancing features, and it works really nicely.
The .NET team have been laser focused on performance since the early days of .NET Core and they haven't let up on this. The whole experience is night and day compared to "legacy" .NET Framework development.
My entire workflow is now Windows free - and for me there are no longer any compromises compared to developing/deploying on a Windows stack (in the early Mono days, there used to be a lot of compromises compared to a then first-class Windows experience, but no more...)
I have some strong (negative) opinions about what Microsoft is doing to the Windows ecosystem - which is partly why it's been a delight to no longer have to use it in any part of my day-to-day - but I will extoll the benefits of .NET all day long. The .NET team really do an amazing job. *
* For the purposes of generosity, I will briefly overlook MAUI and the slight mess that is the .NET GUI based app story...
My first experience developing for .NET on a non-Windows OS had me running Visual Studio & SQL Server Management Studio in a Parallels virtual machine (VM) running on a Macbook Air with only 8GB RAM, targeting .NET Framework. My most recent non-Windows experience had me running JetBrains Rider & DataGrip natively in macOS on a (Intel, non-Apple silicon) Macbook Pro with 32GB RAM, targeting .NET 6.
The experiences were night and day: while my first experience was serviceable, my most recent experience was great & comparable to the work I'm currently doing in Visual Studio 2022 & SQL Server Management Studio 2019 in Windows 10 on a Lenovo Thinkpad w/ 32GB RAM, targeting .NET 7. And the macOS laptop + multi-monitor experience on a Macbook Pro is so nice that I absolutely prefer coding on Macs now instead of Windows.
> Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines).
Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think.
But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds.
Unlike Microsoft apparently, they know not to do their heavy computation on the UI thread.
I absolutely agree, .NET is so well designed on many levels: portability, core framework, documentation, support since the beginning. MS has proven that they can provide stable development platforms (well, except UI). If someone rejects .NET just because it's from MS, they are missing out.
Same workflow here on Mac. Working with a few windows devs and don’t have any issues. We deploy into Microsoft .NET containers currently.
Side note, great website! It’s so rare to see such an aesthetically pleasing site on here! Do you happen to have any open source repos where you implement a lot of what you talk about? I’m interested to look under the hood at your code and your versioning system (I’m sure more, too, but I only spent 15 mins on your site so far)
We do, in the few things we haven’t yet migrated away from C#. I’m curious as to why you wouldn’t, it’s much cheaper than deploying on windows since you’ll likely need a license for that.
We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a rapid pace while keeping maintainable systems. Not so much the languages fault as how Microsoft manages a lot of the libraries. Like how the model builder for EF and OData (both official Microsoft libraries) don’t work together and how you need to extend basically any standard library to do any real work with them. So while it’s actually a decent language, if a bit verbose, and .NET is sort of solid these days, we honestly have very few success stories with it.
Some of our AD (now Entra ID I guess) integration operates on it while we slowly migrate it to Powershell (which is .Net but runs in Azure Automation). Some of our APIs run with it. We have a few azure function apps (in containers and isolated) which are being migrated to other techs, and non-function apps. So it’s not like it’s not “working” for us, it’s just that it works a lot less great than its alternatives, even despite a it’s huge leap forward in recent years. Honestly it feels like Microsoft mostly keeps C# around because it sells licenses to medium sized stagnating companies, considering how “half-finished” a lot of the libraries are and how poorly so many of them function together.
I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects.
I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed ripoff, proudly proclaim it “official” on conferences and all the C# devs jump off the cliff like lemmings, and the original OSS project dies/stagnates. MS might have officially embraced Open Source but they’re absolutely awful at fostering an OSS community.
But .NET itself is amazing! There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. Just use Postgres! Use a lean ORM like Dapper, use Redis, use whatever you want from the wider OSS ecosystem. There’s nothing about C# that forces you onto Entity Framework. Get out of that red polo shirt and look around, there’s a lot of cool stuff out there.
We do, very successfully (large online retailer). Moving off of Windows as a deployment target simplified our processes significantly. Developers use a mix of Windows and Mac to develop, running the services "natively", before we ship them as Docker images to k8s.
There are some "Windows-isms" buried deep in the older layers of the standard library, but these tend to be not relevant for backend services (anything that talks via the network).
I experience .NET as a very productive tech stack. If I were to found a startup tomorrow, I'd pick .NET for boring web service stuff.
I serve videos from my home Linux server using Jellyfin[0][1] and previously ran Emby[2] (from which Jellyfin was forked). Jellyfin is written in C# and runs on .NET 7.
I have a single-file executable with the framework embedded, that I run on all of my computers, from desktops and laptops to cloud VMs to SBC's.
-it's designed to be run once after which it auto-registers itself to always stay running (linux:systemd, windows: task scheduler), while keeping itself up to date
-It contains my CI system (runs software from git, either one run per commit or "keep running forever" mode, UI thru local web server with even browser blazor support hacked in). I use this to run my other programs like servers, crawlers, telegram bots which I write in dotnet and almost always in a way that they run identical on Linux and Windows, x64 or aarch64 (arm). The CI system installs its own dotnet env and env variables to ease with dependencies for the programs ran with it
-It constantly updates its state to a relatively simple azure C# app which functions as a status webpage for all my machines and provides some basic controls like "restart machine" while sending notifications of unexpected machine on/off states
-The executable is capable of automatically updating itself through the central web app server. It does a dance of downloading new version starting the new version as "MRestartor_new", which is then started and renames the current "MRestartor_old", which then starts that "_old" which will rename the newly downloaded one to "MRestartor", then starts that.
-I've half-added a few extra features like remote console, remote VNC-like desktop too
My friend keeps telling me I've re-invented a shitty kubernetes but I actually want to, and need to run this on desktop windows machines (previous reason was Unity build server, now also need it for non-headless puppeteered chrome), and am planning to run some "infoscreen"-like software on it for some computers which would not be possible inside docker to start with.
Outside of this system, I've found the "single file executable" option to be a very pragmatic way to just have a "companion app" bundled with an Unity game for example, that the game starts, and if the game crashes, it sends a crash log. Functions with zero dependencies so even caught an Unity slip-up where Unity actually needed some almost-ubiquitous dll a virgin Windows that our publisher's PC had doesn't actually come with
I maintain three different projects for three business in .NET Core using Linux Docker containers and it's been very smooth.
The ability to have both C# and F# along with a ton of perfectly serviceable libraries is great.
I'm using ASP.NET Core for the web stack, swashbuckle to auto generate swagger docs, EF for auto generated database models. It's pretty great actually. Adding a new field is as easy as making a migration file, changing the API message, and adding one line to map the database model field to the message field. Everything just moves smoothly.
The resulting web servers just work. I've had effectively no issues with them at all. The only issues I've had were the result of Portainer not correctly shutting down a container, which really isn't related to .NET at all.
We were looking at that, but we found Azure Functions to be an even better overall experience.
Today, we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to function deployments from there. Then, we monitor for any exceptions using app insights search from visual studio. The developer experience is flawless. I don't even have to touch the azure web UI to do the happy path. Finding exceptions using the native VS tooling is much easier.
All the pieces fit together really well now - managed identity alone saving us probably a FTE role in our org chart.
> we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to Azure functions
There's actually likely some linux in that stack under the GHA and Azure functions. But this is very much like what I find - "is this .NET running on linux?" is question where the answer is frequently "yes" but also is not an important or interesting question.
Our company's app is written in .NET 7 (soon to upgrade to .NET 8) and deployed via Linux containers into Kubernetes.
It is a delightful ecosystem to work with. Productivity is huge, great tooling and IDE support even in non-MS ways. I joined this company 3 months ago and what I've been able to get done on this platform is honestly exciting. And I haven't had to sacrifice modern development principles.
At my company, every api server and azure function is executed in k8s as linux container. The license costs and performance footprint are a huge factor to not run on windows. And docker-images for the CI production.
Linux is just so much better IMHO. I would switch to linux if visual studio (not vscode) would run there natively.
You could try out Rider on linux. I use it since a few months (on Windows though) and it is pretty great. I used Visual Studio before and Rider is definitely competitive.
We do and it’s brilliant. Technically, we are using Microsoft official dotnet Docker images, not bare metal. Building is really simple and we can cross-compile from developer MacBooks. I expect similar success is possible with JVM but F# is too good to pass up!
I use .NET on Linux and the experience with Rider has been great. The workflow transfers really well between Mac, Windows, and Linux, and everything works the way you expect. The only problems I run into are that there are still things that are Windows focused. For example MAUI does not run on Linux which is a shame because we could use another cross platform GUI.
There are still bugs, for example I ran into one with Polyglot Notebooks not working on Manjaro or Pop!_OS https://github.com/dotnet/interactive/issues/3159
but hopefully that will just get better with time.
I think the biggest with .NET is that it spent so long being Windows only. A lot of people just developed workflows in other languages. It also took time before .NET core, now just .NET really became first class on Linux. With .NET 8 this will get a lot better, and to my understanding will allow the popular Game Engine Godot to be able to target the web with C# builds. This will allow them to go back to having one Godot binary instead of two.
The thing that has me scratching my head though is I can't believe they still don't have System.CommandLine in the standard lib. We want our cli programs please!
Not me personally (I'm not a dev), but where I work, we have two teams working on two separate projects written in .net that run in Linux containers on ECS. The devs themselves use Visual Studio on Windows for local dev.
These things work very well and seem to use very few resources. Those systems manage retail kiosks and similar stuff, and one of the two systems is actually on the critical path for operation, so it's not like they only do housekeeping once in a while.
We deploy in Linux containers to cloud run, and we're about to start shipping a cross platform language binary, so people can run Darklang on any system. Dotnet does cross platform builds from any OS.
I'm using the Mono CLR which is a great as a runtime system for statically typed languages; it's lean, efficient and easy to use and deploy (e.g. compared to LLVM), with an integrated, cross-platform debugger. It runs even on old embedded Linux images. Dependency on the .NET framework is possible, but not necessary.
I've used it exclusively on my servers for the last 5 years and am now using it on my laptop.
Server side, it's better than running it in Windows. I don't pay a license fee for the OS, so spinning up new VMs is super easy. And set-up, deployment, and long-term operation have all just gone off without any hitches. I've got Let's Encrypt certificates, Postgres databases, and so little overhead that I can't get by with small server SKUs.
On desktop, I still use Windows at work, so I've built a WPF/WebView2 and a GTKSharp/WebKit web app shell that lets me run identical code to my server apps, just as a desktop app. It was pretty fiddly to setup (mostly because GTK is hot garbage), but now that I have it, it just works.
My department is only .NET due to dependencies to specific third-party manufacturing software that is .NET and we use their SDK for a lot of stuff. 95% of our apps run on Windows, 5% on Linux. The Linux part exists only because management heard about it and mandated to try it, not because it makes any sense - the third party software runs only on Windows, so even creating 2 dedicated servers with Linux (out of several dozens with Windows) in every plant is just a major pain in the back and a complication that does not pay out.
But if you don't have dependencies and limitations to Windows and you can go full swing with Linux, it's a matter of overall cost and productivity, use what is best for you.
I do contract work for NASA and the main project I work on is transitioning from PostGraphile to an ASP.NET Core WebAPI (currently targeting .NET 7, but will likely look at bumping that to 8 once it's released if it's not too disruptive). I work completely in Linux, coding using Neovim, with Omnisharp for language features and code completion, and our applications are fully built and deployed using Linux containers. .NET on Linux has come a long way since the early days of Xamarin and Mono, it's quite enjoyable to use.
I am, for a range of applications including web APIs and background workers.
I've always favoured Linux for server apps (I used to deploy dotnet apps to Linux with Mono), but I also think Azure (and cloud in general) has, in a roundabout way, introduced a lot of .NET developers to Linux.
There's little reason not to deploy to Linux instead of Windows - it's cheaper and just a much better experience to work with for deployment and operations.
Most .NET backend services and web apps are now deployed on Linux (containers). The default .NET PaaS experience on Azure (App Service) also defaults to Linux.
I suppose it depends what you mean by linux, but if aws lambda on linux counts, then i work at a top 250 UK company who uses dotnet heavily for lambda workloads, especially async workloads. Its been great for us, no complaints. We likely would use it for our sync apis too if dotnet supported apollo federation v2, but sadly it does not.
We don't usually even think about it, but for web apis, function apps and other microservices that process data over http or message queues, it's more or less the default now that the production environment is a linux of some kind. But it isn't a thing that we spend time worrying about.
We are - we are in the process of transitioning our ASP.NET based backend from Windows to Linux. Linux machines are cheaper and easier to administer than Windows based ones.
Most of our backend APIs are written in C#. We deploy them on AWS lambda, so on Linux. Pipelines are Linux and Devs will use a mixture of Linux, MacOS or Windows.
This is for native AOT binaries, not for the typical case. Though this release and the previous ones did contain improvements for trimming binaries, which is what you need to use to make non-AOT binaries smaller.
Curious - why isn't it the typical case? .NET runtimes on Linux itself are rare enough, I figured AOT on Linux would be about the only use case, especially in containerized environments.
You can also publish .NET apps/services directly as container images [1].
Or you can distribute them as a single file, standalone, "ready to run" application, which precompiles your methods and includes the JIT. This results in a larger executable, but keeps all the functionality, including reflection and runtime code generation, intact.
And, of course, you can install .NET core directly on your Linux system, just as you would for Python or Ruby (where you also don't usually rely on the default installation).
Actually many people seem unaware that .NET has supported AOT since the beginning.
The reason that they are unaware, mostly is that using NGEN requires really wanting to use it, as it requires dealing with strong named Assemblies, aka signed .NET libraries/executables.
It only supports dynamic linking, and still pings back on the JIT for more complex code sequences, its original goal being fast startup time for desktop applications.
Thus before .NET Native (UWP only), Mono (iOS/Android), and now Native AOT, doing AOT compilation on .NET was largely ignored, despite NGEN being available.
Having the .NET runtime on the target machine isn't one of the pain points in a production deploy.
As others have pointed out, having AOT compilation, with its faster start-up time, along with smaller binaries is aimed at a different perceived pain point: the cold-start performance of lightweight function apps / AWS lambda.
.NET uses a lot of reflection, and you need to replace that with other mechanisms for AOT.
And for modern .NET (previously named .NET Core, the version that also runs on Linux) you can package the runtime with the binary. You can even create single-file executables there, though those are still not AOT.
The main advantage of AOT is startup time, and that didn't use to matter much for the kind of applications .NET was used for. It matters more now with serverless stuff like AWS Lambda.
Everything dotnet is doing for cross-platform is great and better than alternatives --- except one HUGE issue: There is no official GUI on Linux.
Linux's exclusion from MAUI (while 25% of world's developers' primary dev machine is a Linux system according to Stack overflow survery) creates a huge hurdle for those developing on Linux to build any cross platform GUI app with dotnet.
If I , as a developer developing a windows/mac/mobile app with official dotnet, am using Linux for development , I cannot create a GUI app.
Hey dotnet folks! -- let me put a god damn button on the screen!
Sincerely
A Linux dev
[Don't get at me with Avalonia/Uno etc. I am talking about "official" GUI. A graphical user interface is not a specialized domain, or some niche to be left for others to fill. It is a core element of a user facing app. ]
There's no "official GUI" (w/e that means) on Linux for anything though, so it makes sense.
Avalonia exists, and from the looks of it is better than all the crap MS has put out over the years (even on Windows, don't get me started on WPF shutters) so not using it because its not "official" is silly.
I never said I don't use or don't want to use Avalonia. The issue is not the quality of Avalonia/Uno. They are wonderful. The issue is not availability of third-party toolkits -- they are there. The core issue is being psychologically assured that the first party is interested in supporting my platform with its programming languages and libraries. If MS can support Mac, ios, and Android -- what exactly prevented it from supporting Linux ?? This conspicuous lack of support in the presence of support for other non-MS platforms is the most bothersome bit.
And supporting Linux can't be too expensive either. If Avalonia and Uno being open source with no backing of a huge corporation can do it in their stride -- then Microsoft sure as hell can do it. Again , this time economically --- why exactly is MS supporting Mac, ios, and Android -- not Linux ???.
I hope you see my point. The absence of MS support is not bothersome technologically. It is problematic attitude wise. If they are fine with not doing GUI on linux (while doing it on all the other platforms) --- what other features/enhancements they will be willing to hold back from Linux ??
One way to look at it is MAUI isn't more official than Avalonia or Uno, it just happens to be primarily driven by dedicated team from Microsoft. However, it does not mean that Avalonia or Uno are inferior due to just this fact.
EF Core in that regard is very similar - you can easily use Dapper instead because it builds on the same primitives from System.Data. Neither MAUI nor other UI frameworks have access to internals of CoreLib or adjacent packages living in dotnet/runtime.
In fact, having multiple libraries solving a particular task is a sign of healthy ecosystem, too much centralization more often than not tends to be harmful.
The issue is not the quality of Avalonia/Uno. They are wonderful. The issue is not availability of third-party toolkits -- they are there. The core issue is being psychologically assured that the first party is interested in supporting my platform with its programming languages and libraries. If MS can support Mac, ios, and Android -- what exactly prevented it from supporting Linux ?? This conspicuous lack of support in the presence of support for other non-MS platforms is the most bothersome bit. And supporting Linux can't be too expensive either. If Avalonia and Uno being open source with no backing of a huge corporation can do it in their stride -- then Microsoft sure as hell can do it. Again , this time economically --- why exactly is MS supporting Mac, ios, and Android -- not Linux ???. I hope you see my point. The absence of MS support is not bothersome technologically. It is problematic attitude wise. If they are fine with not doing GUI on linux (while doing it on all the other platforms) --- what other features/enhancements they will be willing to hold back from Linux ??
reply
> The Azure Functions service is made up of two key components: a runtime and a scale controller. ... The Azure Functions runtime can run anywhere. ... The scale controller monitors the rate of events that are targeting your function, and proactively scales the number of instances running your app.
> Kubernetes-based Functions provides the Functions runtime in a Docker container with event-driven scaling through KEDA. ... Using Functions containers with KEDA makes it possible to replicate serverless function capabilities in any Kubernetes cluster.
Readit News
But it's still a Microsoft project and their sword keeps looming over its head. There have been some heavy-handed anti-developer choices in the past and one can safely assume that that has been their EEE-genes kicking in and it will probably not get better, but worse, the more they build up a community they feel they have (or should have) control over.
Wouldn't want to dive into that pool.
.NET is only as good as the parts Microsoft doesn't have too much control over and that doesn't even include the VSCode extension (or VSCode itself - Use VSCodium and you'll see).
But there was plenty of serious alternative languages running on the JVM? Scala, Kotlin, Clojure. All of which have more adoption than F#.
Can you explain more? I'm less familiar with the .net side of things.
TimeProviderFake: https://learn.microsoft.com/en-us/dotnet/api/microsoft.exten...
ReleaseNotes: https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...
Until then you can use System.IO.Abstraction[1] if you aren't already :)
[1] https://github.com/TestableIO/System.IO.Abstractions
> If you lack time to finish something, use the TimeProvider. It provides time.
If so, would C# be a good choice for writing cross-platform command-line applications?
It seems that C# can produce easily-distributable binaries, while also hitting a sweet-spot in language design - not super complex like C++ or Rust, and also not overly simplistic like C or Go.
I haven’t done a recent comparison so if someone had tested this lately and has different results I’d love to see it.
I'm interested to hear success stories.
Sounds like a a great way to build and deploy applications.
I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled, wasted an hour and insecured the target machine, and gave up finally).
I used SQLite, and the System.Data.SQLite, because reasons (legacy). It is a bug ridden piece of work (on linux), with no sane way to contribute. Also it is useless on M1 Mac, as the author doesn't give a shit about compiling it for arm (or setting up a CI pipeline on github or gitlab for example, where it is supported).
Had plenty of problems with single file app bundle deployment, as much as it eased deployment initially, lots of libraries broke on it.
It has been working okay for us (in other former projects) generally well, but personally I am missing some things from the JVM, where VM tuning and monitoring and remote debugging are all a smoother ride in my experience.
Oh, and async broke the C# language (or rather the standard library) and killed the CLR interop with other languages, it was a big mistake to release it with these defaults. I really like F#, but async everything made it uselessly difficult in my opinion. But it has nothing to with .Net on Linux. It works, and is way better than the nodejs world, but I think more ideas should be copied from the JVM world to ease the Ops side, or they should be more clearly communicated.
Is vs doing something else internally?
This was before MS was on board with Linux and all, but Mono was already super good tech. It wasn’t as fast as real .NET but it was still way faster than eg Python or Ruby, the popular backend languages of the day. There was even a half decent cross platform IDE (MonoDevelop), most of the dev team wasn’t on Windows.
I guess this is not very actionable knowledge anymore but I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today.
Somehow linux/mac people seem to avoid .NET out of sheer cultural avoidance, and Windows people seem to avoid most of the OSS ecosystem like the plague for awkward “i was at a .net conf and all the talks were about MS tech” reasons but actually the two combine really well. C# is a great language with unparalleled tooling. It’s easy to learn for people with nearly any background. It’s fast, it’s easy to refactor, it’s easy to debug and it runs everywhere. For over a decade now.
My current company runs Elixir because we’re a chat API and the BEAM’s parallelism/robustness story is uniquely suited to our product. If we’d be in a different domain I’d choose C# (on linux, with postgres) again in a heartbeat.
It also felt like magic somehow, after having my .NET development tied to Windows for so long before that...
There were a lot of caveats then and quite some disparity in how it would run on Mono vs normal .NET Framework.
> I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today.
Safe assumption!
Nowadays Windows only provides a nice SDK for C#. If you want to create apps in any other language you will need to use the Win32 ABI or some wrapper.
I develop solely on Mac (JetBrains Rider), compiling/debugging Mac binaries locally - no containers - unless I need any external dependencies like eg. Postgres.
On M1 MacBook Pro the experience is blazing fast - and Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines).
Everything is built and tested on Linux (and sometimes Mac) runners in GitHub.
Then I deploy direct to cloud-based "disposable" Debian VMs. If it's a small/hobby project, I can get really great performance out of even the smallest VMs.
For those interested in the details; I most often run production .NET ASP.NET apps as a systemd service on Debian using the native/in-built .NET Kestrel web server, and almost always (currently) use Cloudflare Tunnel as a reverse proxy for ingress traffic. No inbound ports open in Linux. I've got multiple production systems running like this including some load-balanced using Cloudflare Tunnel load balancing features, and it works really nicely.
The .NET team have been laser focused on performance since the early days of .NET Core and they haven't let up on this. The whole experience is night and day compared to "legacy" .NET Framework development.
My entire workflow is now Windows free - and for me there are no longer any compromises compared to developing/deploying on a Windows stack (in the early Mono days, there used to be a lot of compromises compared to a then first-class Windows experience, but no more...)
I have some strong (negative) opinions about what Microsoft is doing to the Windows ecosystem - which is partly why it's been a delight to no longer have to use it in any part of my day-to-day - but I will extoll the benefits of .NET all day long. The .NET team really do an amazing job. *
* For the purposes of generosity, I will briefly overlook MAUI and the slight mess that is the .NET GUI based app story...
The experiences were night and day: while my first experience was serviceable, my most recent experience was great & comparable to the work I'm currently doing in Visual Studio 2022 & SQL Server Management Studio 2019 in Windows 10 on a Lenovo Thinkpad w/ 32GB RAM, targeting .NET 7. And the macOS laptop + multi-monitor experience on a Macbook Pro is so nice that I absolutely prefer coding on Macs now instead of Windows.
Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think.
But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds.
Unlike Microsoft apparently, they know not to do their heavy computation on the UI thread.
Side note, great website! It’s so rare to see such an aesthetically pleasing site on here! Do you happen to have any open source repos where you implement a lot of what you talk about? I’m interested to look under the hood at your code and your versioning system (I’m sure more, too, but I only spent 15 mins on your site so far)
We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a rapid pace while keeping maintainable systems. Not so much the languages fault as how Microsoft manages a lot of the libraries. Like how the model builder for EF and OData (both official Microsoft libraries) don’t work together and how you need to extend basically any standard library to do any real work with them. So while it’s actually a decent language, if a bit verbose, and .NET is sort of solid these days, we honestly have very few success stories with it.
Some of our AD (now Entra ID I guess) integration operates on it while we slowly migrate it to Powershell (which is .Net but runs in Azure Automation). Some of our APIs run with it. We have a few azure function apps (in containers and isolated) which are being migrated to other techs, and non-function apps. So it’s not like it’s not “working” for us, it’s just that it works a lot less great than its alternatives, even despite a it’s huge leap forward in recent years. Honestly it feels like Microsoft mostly keeps C# around because it sells licenses to medium sized stagnating companies, considering how “half-finished” a lot of the libraries are and how poorly so many of them function together.
I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed ripoff, proudly proclaim it “official” on conferences and all the C# devs jump off the cliff like lemmings, and the original OSS project dies/stagnates. MS might have officially embraced Open Source but they’re absolutely awful at fostering an OSS community.
But .NET itself is amazing! There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. Just use Postgres! Use a lean ORM like Dapper, use Redis, use whatever you want from the wider OSS ecosystem. There’s nothing about C# that forces you onto Entity Framework. Get out of that red polo shirt and look around, there’s a lot of cool stuff out there.
There are some "Windows-isms" buried deep in the older layers of the standard library, but these tend to be not relevant for backend services (anything that talks via the network).
I experience .NET as a very productive tech stack. If I were to found a startup tomorrow, I'd pick .NET for boring web service stuff.
[0] https://jellyfin.org/
[1] https://github.com/jellyfin/jellyfin
[2] https://emby.media/
Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience.
[0]: https://github.com/navidrome/navidrome [1]: https://github.com/Sonarr/Sonarr
-it's designed to be run once after which it auto-registers itself to always stay running (linux:systemd, windows: task scheduler), while keeping itself up to date
-It contains my CI system (runs software from git, either one run per commit or "keep running forever" mode, UI thru local web server with even browser blazor support hacked in). I use this to run my other programs like servers, crawlers, telegram bots which I write in dotnet and almost always in a way that they run identical on Linux and Windows, x64 or aarch64 (arm). The CI system installs its own dotnet env and env variables to ease with dependencies for the programs ran with it
-It constantly updates its state to a relatively simple azure C# app which functions as a status webpage for all my machines and provides some basic controls like "restart machine" while sending notifications of unexpected machine on/off states
-The executable is capable of automatically updating itself through the central web app server. It does a dance of downloading new version starting the new version as "MRestartor_new", which is then started and renames the current "MRestartor_old", which then starts that "_old" which will rename the newly downloaded one to "MRestartor", then starts that.
-I've half-added a few extra features like remote console, remote VNC-like desktop too
My friend keeps telling me I've re-invented a shitty kubernetes but I actually want to, and need to run this on desktop windows machines (previous reason was Unity build server, now also need it for non-headless puppeteered chrome), and am planning to run some "infoscreen"-like software on it for some computers which would not be possible inside docker to start with.
Outside of this system, I've found the "single file executable" option to be a very pragmatic way to just have a "companion app" bundled with an Unity game for example, that the game starts, and if the game crashes, it sends a crash log. Functions with zero dependencies so even caught an Unity slip-up where Unity actually needed some almost-ubiquitous dll a virgin Windows that our publisher's PC had doesn't actually come with
The ability to have both C# and F# along with a ton of perfectly serviceable libraries is great.
I'm using ASP.NET Core for the web stack, swashbuckle to auto generate swagger docs, EF for auto generated database models. It's pretty great actually. Adding a new field is as easy as making a migration file, changing the API message, and adding one line to map the database model field to the message field. Everything just moves smoothly.
The resulting web servers just work. I've had effectively no issues with them at all. The only issues I've had were the result of Portainer not correctly shutting down a container, which really isn't related to .NET at all.
Today, we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to function deployments from there. Then, we monitor for any exceptions using app insights search from visual studio. The developer experience is flawless. I don't even have to touch the azure web UI to do the happy path. Finding exceptions using the native VS tooling is much easier.
All the pieces fit together really well now - managed identity alone saving us probably a FTE role in our org chart.
There's actually likely some linux in that stack under the GHA and Azure functions. But this is very much like what I find - "is this .NET running on linux?" is question where the answer is frequently "yes" but also is not an important or interesting question.
It is a delightful ecosystem to work with. Productivity is huge, great tooling and IDE support even in non-MS ways. I joined this company 3 months ago and what I've been able to get done on this platform is honestly exciting. And I haven't had to sacrifice modern development principles.
For those cases we do the same approach we have been doing with Java for decades, developing on Windows, deploying on Linux based instances.
Other than that, still too many projects depend on .NET Framework.
I still have too much of .NET version of Python 2/3 transition.
There are still bugs, for example I ran into one with Polyglot Notebooks not working on Manjaro or Pop!_OS https://github.com/dotnet/interactive/issues/3159 but hopefully that will just get better with time.
I think the biggest with .NET is that it spent so long being Windows only. A lot of people just developed workflows in other languages. It also took time before .NET core, now just .NET really became first class on Linux. With .NET 8 this will get a lot better, and to my understanding will allow the popular Game Engine Godot to be able to target the web with C# builds. This will allow them to go back to having one Godot binary instead of two.
The thing that has me scratching my head though is I can't believe they still don't have System.CommandLine in the standard lib. We want our cli programs please!
These things work very well and seem to use very few resources. Those systems manage retail kiosks and similar stuff, and one of the two systems is actually on the critical path for operation, so it's not like they only do housekeeping once in a while.
Ethereum has a Market Cap of $249Bn and $34bn of other assets in smart contracts.
So you could say .NET on Linux has under management $116Bn and handles $800m of asset transfers per day, napkin math
We deploy in Linux containers to cloud run, and we're about to start shipping a cross platform language binary, so people can run Darklang on any system. Dotnet does cross platform builds from any OS.
Fixed.
Server side, it's better than running it in Windows. I don't pay a license fee for the OS, so spinning up new VMs is super easy. And set-up, deployment, and long-term operation have all just gone off without any hitches. I've got Let's Encrypt certificates, Postgres databases, and so little overhead that I can't get by with small server SKUs.
On desktop, I still use Windows at work, so I've built a WPF/WebView2 and a GTKSharp/WebKit web app shell that lets me run identical code to my server apps, just as a desktop app. It was pretty fiddly to setup (mostly because GTK is hot garbage), but now that I have it, it just works.
But if you don't have dependencies and limitations to Windows and you can go full swing with Linux, it's a matter of overall cost and productivity, use what is best for you.
I've always favoured Linux for server apps (I used to deploy dotnet apps to Linux with Mono), but I also think Azure (and cloud in general) has, in a roundabout way, introduced a lot of .NET developers to Linux.
There's little reason not to deploy to Linux instead of Windows - it's cheaper and just a much better experience to work with for deployment and operations.
We don't usually even think about it, but for web apis, function apps and other microservices that process data over http or message queues, it's more or less the default now that the production environment is a linux of some kind. But it isn't a thing that we spend time worrying about.
.net on Linux was a zero cost transition, giving us a whole new platform, a whole new user base. It was that easy.
Additionally, some of clients are linux and we have to ensure that our programs work flawlessly on it.
The only problem I faced 5 years ago was that I didnt have some fonts installed for pdf generation.
Or you can distribute them as a single file, standalone, "ready to run" application, which precompiles your methods and includes the JIT. This results in a larger executable, but keeps all the functionality, including reflection and runtime code generation, intact.
And, of course, you can install .NET core directly on your Linux system, just as you would for Python or Ruby (where you also don't usually rely on the default installation).
[1] https://learn.microsoft.com/en-us/dotnet/core/docker/publish...
The reason that they are unaware, mostly is that using NGEN requires really wanting to use it, as it requires dealing with strong named Assemblies, aka signed .NET libraries/executables.
It only supports dynamic linking, and still pings back on the JIT for more complex code sequences, its original goal being fast startup time for desktop applications.
Thus before .NET Native (UWP only), Mono (iOS/Android), and now Native AOT, doing AOT compilation on .NET was largely ignored, despite NGEN being available.
They exist, they're easy to install (1), but more importantly for containerized environments, you can start with a standard image e.g. https://hub.docker.com/_/microsoft-dotnet-aspnet
Having the .NET runtime on the target machine isn't one of the pain points in a production deploy.
As others have pointed out, having AOT compilation, with its faster start-up time, along with smaller binaries is aimed at a different perceived pain point: the cold-start performance of lightweight function apps / AWS lambda.
1) https://learn.microsoft.com/en-us/dotnet/core/install/linux#...
And for modern .NET (previously named .NET Core, the version that also runs on Linux) you can package the runtime with the binary. You can even create single-file executables there, though those are still not AOT.
The main advantage of AOT is startup time, and that didn't use to matter much for the kind of applications .NET was used for. It matters more now with serverless stuff like AWS Lambda.
Deleted Comment
Avalonia exists, and from the looks of it is better than all the crap MS has put out over the years (even on Windows, don't get me started on WPF shutters) so not using it because its not "official" is silly.
EF Core in that regard is very similar - you can easily use Dapper instead because it builds on the same primitives from System.Data. Neither MAUI nor other UI frameworks have access to internals of CoreLib or adjacent packages living in dotnet/runtime.
In fact, having multiple libraries solving a particular task is a sign of healthy ecosystem, too much centralization more often than not tends to be harmful.
> The Azure Functions service is made up of two key components: a runtime and a scale controller. ... The Azure Functions runtime can run anywhere. ... The scale controller monitors the rate of events that are targeting your function, and proactively scales the number of instances running your app.
> Kubernetes-based Functions provides the Functions runtime in a Docker container with event-driven scaling through KEDA. ... Using Functions containers with KEDA makes it possible to replicate serverless function capabilities in any Kubernetes cluster.
[0] https://learn.microsoft.com/en-us/azure/azure-functions/func...
A bit overkill to use k8s for my use-case, but didn't knew it was possible for AF.