The .NET ecosystem is giving me a lot of confidence these days. I've been on this rollercoaster since .NET Core 2.x and don't think I will be getting off any time soon.
We recently upgraded from 3.1 to 6, which was a total non-event. The code base that was around for Core 2.x is still the same one we have today. Some substantial changes made to the web interfaces and hosting, but nothing in the business logic or data models was impacted.
We currently use Self-Contained Deployments to Windows machines, but there are only 2 minor methods stopping us from using a Linux image as well. Looking for a really good reason to make the jump, but I can't justify it to the business yet.
> Looking for a really good reason to make the jump
Not having to pay for Windows Server licences?
Better start-up performance, likely better overall performance, less resource usage.
Assuming these are specific Windows calls, moving to something more cross-platform you could open development to colleagues with Mac or Linux machines (via VS Mac, JetBrains Rider or VS Code) if there are any.
Options to use Kubernetes or deploy to container services that run on Linux
I just jumped on the .NET Core gravy train after 6+ years of Ruby on Rails development. I feel so productive and confident working with .NET. Ill be riding this rollercoaster with you for a while!
C# is such a cozy language, anyone familiar with C++ or Java can instantly bang out half-decent code, and there's a ton of great features to gradually learn and use. And the performance is about as good as it gets for a language with garbage collection. Big fan.
And ASP.Net Core is an insanely fast web framework. It beats every other major framework written in a managed language by a mile. There's no way your backend will outgrow it if your workload isn't RAM-limited.
Would you call TechEmpower benchmarks synthetic? I think they're a pretty useful data source and indeed support the claim that the performance of .NET is rather good.
Personally I think that some of their tests are pretty close to what web applications might actually do a lot of the time (fetching the data, processing it, saving it), for example, see here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
Sure, sometimes the code you see in benchmarks can be a bit more clever than the code you'd see normally, but for the most part TechEmpower seems close enough to be a vague indicator towards what frameworks/languages/stacks have decent performance.
It also helps you get a feel for how big the differences are between any two given platforms, like using something like Java + Spring and Python + Django, which may or may not be relevant in actual business conditions, since you might also want to iterate quickly.
It produces best performance OOB with minimal API way of registering your endpoints. Which is expected to be the default way for many newcomers to the framework. On 5800X, hello world with some logic and cached JSON output (not raw bytes but actual response object so no cheating) produces over 4GB/sec when benchmarked over localhost on .NET 7.
The only other real way is to write two programs that do the same thing in both. You need to put in the same degree of runtime/environment-specific optimizations (which, notably, will result in different code), but except for in trivially simple applications (eg: "TODO app") which are arguably also "synthetic", the optimizations are always going to leave room for debate.
I'm glad for you, but ActiveRecord is still the best ORM of all time. OF ALL TIME. I rewrote one of my main Rails applications in .NET, and trying to use Entity Framework was like pulling teeth for me, in comparison.
I'm glad it works for you. It gave my team years of headache while we ported it all to jOOQ.
Also our Ruby engineers liked the flexibility so much that they exposed our entire database as a service to customers, which we had to emulate and support.
Amen to that. We had a high-level engineer who sincerely believed that Rails and Postgres were the right tools for Everything. Consequently he shipped a mission-critical query engine whose API is - you guessed it - just ActiveRecord!
It's great if your users are disciplined and experienced Rails engineers who understand how the system works, but we don't live in fantasy land and a year later, we are so very constrained by the unlimited DB access that we're rewriting it all and leaving ActiveRecord out of the equation.
I'll always maintain that Rails is the first tool I'd reach for in a new web startup, and the first one I'd discard after growing past ~20 engineers.
> It's great if your users are disciplined and experienced Rails engineers who understand how the system works.
I'm continuously shocked at how much bad ActiveRecord code there is lying around given that it's so easy to just look at the SQL it generates and be like "yeah this looks reasonable".
WHY SPONGEBOB WHY!?! Why do you pass around your relations making all of ActiveRecord part of your external API? It's so hard to do stupid things with AR if you pretend that AR objects can't leave the scope they were fetched in.
You shouldn't blame Ruby (or ActiveRecord) for infrastructure decisions that are inherently bad, irrespective of platform or technology. I mean, this is HN, and you WILL, but you shouldn't. ;-)
Unfortunately we were a tiny Lisbon startup with our own in-house clone of AOL Server and Tcl was never a hyped language, otherwise I don't really see what it does better.
Our Tcl ORM was doing Sybase, SQL Server, DB2, Informix, Oracle and even Access, across Windows 2000/NT, AIX, HP-UX, Solaris, Linux, in 1999 - 2002.
But we never went big into US, so Rails gets the credits.
And we were not alone in this regard, there was Vignette, Cold Fusion, Zope,...
I'm just glad the number-space has been sorted out. It was annoying to learn that ".NET 2", ".NET Standard 2" and ".NET Core 2" are very different things.
It's really too bad the naming/versioning has gotten so confused. I used to be a heavy .Net user, then stepped away for a while when I changed jobs. Every time I try and come back, I get so confused. Am I looking at the right docs? Is this API available for the platform I'm on? It's bad enough with .Net, itself, but what about GUI libs? What's even supported anymore? What's actually stable and not in pre-release? It's a shame, because .Net is damn good, but the messaging around it has been awful in my experience.
Christ, the mess that are the docs. And the complexity. Just lost well over an hour trying to get a non-trivial regex working (that would have taken me 30 secs in emacs). Gave up and just used split() and it just worked. Never again, I swear.
Might want to check out RegexStorm [1]. It's a .NET regex tester in your browser. Yeah the docs are great but there's nothing like instant feedback to test your regex.
Capture pattern [edit: I meant capture brackets] extraction. Could get one of them (?!) or nothing at all, but... never again. MS doc examples = no success, not SO, not various blogs.
Yes, big poop show on naming convention changes done terribly. Eventually the dirt will settle and become easier to navigate if it hasn’t started already.
Old .NET was always ".NET Framework". Microsoft had many years of branding advice early in .NET history that it was never to be called just .NET because their branding teams were using that as a wider initiative that included other things. Most of those other things died or were rebranded and .NET Framework was the last one standing. .NET 5 was the first ever "just .NET", technically from a historical perspective.
My friend works at an F# consultancy - from what I’ve heard it’s definitely growing in popularity! I used it for some windows profiling in 2020 which was pretty cool too, albeit only really a single script.
I have been a long time "enterprise languages" developer. First Java/J2EE then .NET in the last 10+ years. I already felt that moving to .NET was a jump forward with respect to J2EE but have always been curios about startup languages/stacks like Ruby and Clojure. Lately I was much tempted to do some side project on Rails because I find the Hotwire/Nojavascript trend very reasonable for a lot of real use cases . How do you compare modern Rails with modern .NET?
I haven't worked with Rails since Rails 5 so I dont know if I could do a fair comparison of how they are as it stands today. Check one of the comment replies above where I outlined some of my thoughts in a similar question.
Any interest in doing a short comparison? As in, why are you in no rush to switch back to rails? Any features you miss from rails? (edit: register beat me to it. I'll leave my post as a +1)
For the most part, I think there is a lot of feature parity between the .NET and Ruby on Rails frameworks when it comes to developer tooling.
As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose [might be a good blog post?]
They both have a good database migration system and various generators for scaffolding views, controllers, etc. To be fair I believe Entity Framework does most of the work for the .NET side on the database developer tooling but I just consider it part of the .NET ecosystem since it seems to be the go-to ORM/database tooling library. I want to be fair to Rails -- I really think they set the bar very high for other frameworks. Productivity w/ Rails was unprecedented when it first came out. I started during the Rails 3 to 4 upgrade.
Both ecosystems have easy access to outside libraries using Nuget/Gemfile. So pulling in a background processor like Sidekiq [Ruby] or Hangfire [C#] is fairly easy.
Cross platform support is acceptable across both frameworks as well. I can setup an EC2 instance and run both Rails and .NET applications side-by-side. So deployments are going to be similar but I would argue that .NET has the upper-hand because it can deploy do a self-contained deploy so you don't have to worry about installing dotnet in the deployment environment.
I am using Blazor Server and I am not going to say something drastic like it will kill React but it is pretty awesome. I can build my entire web experience with C# but with Rails I have to introduce React when I sometimes dont want to. Blazor prevents me from having to write HTTP code from my front to backend systems and as an indie developer that is a godsend.
Both have gorgeous documentation -- I thought Rails was good and thorough but .NET ate their lunch.
> As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose
I'm not even sure it's an "older" thing -- it's nice just to have less mental overhead.
The things that used to turn me off from static languages (eg: most of the benefits dynamic languages have) have disappeared. Generics allows creation of some powerful re-usable code (eg, List<T> or RunningAverage<T>). Tools to easily convert any random JSON or XML to concrete classes make it a simple extra step to consume any API.
The benefits are massive. Code-completion just frees your brain from having to remember or deeply think about what's available. Type-safety giving compile-time (or even coding-time) errors prevents so many stupid problems that, in a dynamic language, take a runtime check to find.
I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state. I found that connection is easily/fequently disrupted resulting in an app reset, lost state, and poor user experience, to say nothing of the scalability implications.
Though, for a purely back-office app with minimal state, that might be OK
> Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state
Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.
It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.
Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).
It sounds like you have been using Blazor a lot more than I have so I’ll take your word for it. I haven’t any massive traffic yet. Is this something I can reproduce with a benchmarking tool?
But your comment comparing Blazor to Rails seems to be about the current state of Blazor and Rails. So currently Hotwire for Rails is production ready. So with Rails, you don't necessarily have to introduce React as you comment claims.
I think the .NET Core model is probably fine for web apps, but I literally laugh at the idea anyone would deploy desktop software with it: The .NET team's idea of an "LTS" version is 3 years, which is an absolute joke.
If you continue to use .NET Framework 4.8, your software will receive security updates until the heat death of the universe, too much, including Windows itself, depends on it. (Same, hilariously, with Visual Basic 6.) Microsoft's lifecycle for new runtimes is so short you're better off using a dead one.
.NET Core has too many caveats and too few selling points to get any reasonably competent desktop developers to move over, IMHO, especially considering the fact that every executable you ship to customers has a Microsoft imposed support death date.
There are significant performance improvements, and the new language features of C# depend on the later versions - that might not be such a big deal, but it will become more acute as the language improves.
You can get most of the new language features to work with .Net Framework by overriding the LanguageVersion in the build. I did this to get nullable type annotations and pattern matching to work when I inherited a .Net Disaster.
There are a few that require compiler interop which don't work, like using new syntax on records for specifying the fields (e.g., "record A(int a, int b)").
Also, proper High DPI support in both WinForms and WPF in .NET 5+. There is starting to be a very notable difference there between applications compiled on .NET Framework (or VB6) versus those recompiled for .NET 5+ WinForms/WPF with older apps not just looking dated, but sometimes aggravatingly unusable/inaccessible on modern monitors.
I don't think I've ever seen a WPF app broken on hi-DPI, and I use a 4K display with 225% scaling. It was designed from grounds up as resolution-independent.
WPF does in general have many fewer issues than WinForms and the ones I've seen that were basically just broken were all WinForms. There's still some changes to WPF that are noticeable if you are looking for them (mostly in the default controls).
Cost... linux images should be a fraction of the cost of a Windows image. Unless, of course, you're using Azure, where they subsidize the cost of SQL Server by charging more for linux boxes/containers.
Does visual studio run on linux yet? That's my rubicon for taking .net seriously. It's not just about the runtime, the tooling has to be present as well.
This is not quite true on an M1 Mac. The VS Code C# extension only supports .NET Core, and the latest and deprecated release 3.1 has no ARM build. .NET 6 does, but is somehow unsupported.
To me, it's clear Microsoft wants to force people to use VisualStudio over VSCode. Likely not an issue for a .NET shop, but it's yet more shenanigans by Microsoft
Er, what? The VS Code extension gets updated all the time, it was updated in tandem with .NET through to .NET 6 and is currently being developed for .NET 7.
Works with
Linux x64, Alpine Linux 64 bit, macOS Intel, Linux ARM64, macOS Apple Silicon, Alpine Linux ARM64, Windows ARM, Windows ia32, Windows x64
.NET 6 is the first where they fully supported M1 Macs, maybe you last looked before .NET 6 released? Either way, VS Code is definitely a supported way to work with .NET.
try Rider from JetBrains, it's as good or better as Visual Studio.
I'm developing .NET projects (web) on macbooks with Rider for last 2 years, and do not miss Visual Studio at all
Extremely unlikely vs will ever run on linux, pretty sure it's built using wpf which is window only. The tooling on linux is just fine, and VSCode and Jetbrains rider are your main options.
No, but they make a high quality plug in for VS Code which gives you a similar overall experience, as well you can use JetBrains C# IDE which is very good and often preferred even on Windows.
Yes, still irrelevant. The only people that seem to complain about the cost are people not actually responsible signing off on invoices. Compared to the many other costs a company is spending money on, it's unlikely the MS expenses will even show up in a budget review unless you're really screwed the pooch.
lower hosting costs is the reason that I used in a previous company. Linux deployed cost 2-5x less, at least for the workloads we had. Provisioning windows machines in the cloud was prohibitively expensive comparatively.
Do you use ASP.NET Core Identity or roll your own auth? The thing that bugged me about ASP.NET Core Identity when I looked in late 2020 was that it stores too much info in the cookie itself. So if a user logs in, and then their authorization details change, the cookie could become stale. I've come around to the conclusion that the cookie should just be an opaque identifier pointing to a database record on the server. Most of us aren't trying to optimize authorization for Google (or Microsoft) scale.
Every client gets 256 bits of entropy cookies which uniquely identify their “device”. The server will then deal with this as required to guide auth flows.
>We recently upgraded from 3.1 to 6, which was a total non-event.
Good to hear as we need to take this step soon. The bigger hurdle for us is a number of production apps in DNF 4.x that also leverage DevExpress (god knows why). Incredibly costly to stand up in EC2 instances and the ROI just isn't there.
> but there are only 2 minor methods stopping us from using a Linux image as well
As developer and systems engineer you should have been aware of that before starting your work. Now you are chained to the Windoes world and real computing environments are out of reach for your project.
Microsoft seems like "a house divided" when it comes to opening .NET. They open source the core language, but have different proprietary dev tools (debugging for one) you need to pay for.
https://isdotnetopen.com/ goes over these in more detail, but I'd rather use an ecosystem where I don't have to worry things will be progressively locked down in the future.
I guess I'm not that worried about it. There are other debuggers available. JetBrains has a proprietary one. Samsung's is MIT licensed and linked in your link.
It seems like they spooked the community with this VSCode plugin thing but it also feels like not that big a deal. MS wants VSCode to interface with things they can sell along with the open source. Is that so bad? I get the worry that the MS support of OSS could dry up but that could be said for all kinds of OSS projects with corpo backers, no?
Yeah, but the general standard is for open languages to either have an open debugger (e.g.: V8 JS) or else otherwise have support for an open debugger interface (e.g.: Rust via GDB).
It's not strictly unreasonable for MS to offer a proprietary debugger, but it is bass-ackwards for the core .NET team to not offer an open source debugger or open standards compliant debugger interface to go with their open source language.
The debugger interface is open (it's part of the CLR itself), and so is the debug symbol file format.
However the debugger interface is low-level, making writing a debugger engine from scratch fairly complex. The complaint is that Microsoft uses a restrictive license for their higher-level wrapper around the low-level API.
But it should be possible to write independent .NET debuggers -- I believe Jetbrains has done so, Rider can debug C# code without the problematic Microsoft component.
Roslyn (the open-source compiler) can create open-PDB debugging files that are also an open-source format. You are 6 years too late to make that comment.
Even if Microsoft did release an OSS debugger with less features/performance than the proprietary debugger, you know the narrative would instantly change to complaining about keeping features/perf back for paid users.
Visual Studio Code also uses the debugger and that's a free tool marketed as open source. The open source version (VSCodium) doesn't ship a C# debugger for this reason.
There's nothing inherent about the debugger that forces it to be in visual studio. There was a moment, circa 2016 or so, when it could have been opened and then collaborated on with Jetbrains. Instead, MS leadership circled the wagons due to OSS FUD that they get sometimes, and Jetbrains was forced to build a better debugger that's also tied to its IDE.
Of course, this being open source might enable third parties to invest in their own tools; including debuggers. Part of that deal is that developers are no longer passive by-standers. If it bothers you enough you might fix it or help fund somebody else to fix it.
Providing the basics as open source and then charging a little for some extras should not be the end of the world. You see the same in the Jetbrains ecosystem where e.g. the community edition of Intellij is free and open source but they have a paid version with a lot of extras.
Paid products for developers are not as common as they used to be but we are talking about tools that improve productivity a lot for people that make a lot of money using those tools. Developers (my self included) are oddly stingy when it comes to spending on software but at the same time think nothing of blowing a few thousand dollars on hardware.
There is VS Code, which is not a version of VS, is free, and has this debugger.
There is also VS Community, which is a free version of VS, has this debugger, but has fairly strict licensing limitations (e.g. it can't be used in corporations).
I have debugging in Rider (JetBrains' .NET IDE), what nuance am I missing about the debugger argument? Other than Rider also being a paid product, I guess.
what? this is crazy. I have been using .net since 2001 and they have always had a community version or a free way of developing. There is no more concern using MS than there is using any other platform in my opinion. They are divided because they have different audiences, its ok, they are different service lines (corporate vs startup)
Meh. In the end, Microsoft will betray those who trusted it. Long term, better just to pretend it does not exist and never, ever depend on anything with Microsoft name on it.
> There is no ethical consumption under capitalism
is said to de-emphasize or criticize arguments that are centered on consumer choice which is exactly what you and GP are doing by saying
> You have no choice but to depend on big corporations for key software platforms; advising or choosing to stay away from this one or that one matters little
I've been keeping an eye on Microsoft's bullshit since the 90s. Just when you think that leopard might have changed its spots (think VS Code) they pull this shit:
I mean Microsoft does have a history of fucking the open source world. We can like their new approach without denying that, and understand people having their reserves.
I'm also saying the same thing. We should not trust Microsoft, ever. However with your wording, you leave the impression that you don't agree with your parent (which is perfectly OK in my book), hence I'm not agreeing with you, but your parent.
OK. I mean, yeah I disagree. There's ample reason to distrust Microsoft these days, but far less than there used to be.
I've signed many antitrust petitions for them over the years. And they have won a fair amount of good will since Satya came on and pushed for cultural change, as well as a larger pivot towards cloud and open source.
Sorry, I just can't see the change Satya brought to the company.
Considering their "collaboration" with Canonical, it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishing desktop Linux installs once and for all.
As a payback they're leaving server space to Canonical, but port their software to work on Ubuntu, so they have a suitable "free" platform to monetize their software. Canonical can make boatloads of money by selling support, Landscape and similar services meanwhile.
I'm thankful to them for their Copilot shenanigans though, they kickstarted the motivation inside me to be even more serious about the services and software I use. I left GitHub, slowly moving away from Google services, etc.
> Sorry, I just can't see the change Satya brought to the company.
I would say that if that is your perspective, then you probably didn't have a close up view of them and how they operated before and after. There's been a lot of spilled ink about it; I won't rehash it here.
> it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishing desktop Linux installs once and for all.
I expounded on this in another thread - Desktop Linux isn't likely to be something MSFT spends any amount of time concerning themselves with as competition. Realistically, it's not real competition and any harms done to it probably were borne out of callousness or ignorance rather than competitive spite. The competition is OSX and ChromeOS (which I would not consider 'Desktop Linux').
> you probably didn't have a close up view of them and how they operated before and after.
I have witnessed "before" enough, so I distanced myself from them pretty sharply, and I didn't bother to check "after" that close. It's my fault, I accept it, but from this distance the end result doesn't show any meaningful differences. So, it's something to ponder if you ask me.
> Desktop Linux isn't likely to be something MSFT spends any amount of time concerning themselves with as competition.
It's may not be competition, but is a big hurdle against locking down PC ecosystem and converting them to appliances. If they can run all Linux apps under Windows, they can revoke all 3rd party signing keys, make Secure Boot mandatory and tell judges "See, it all works under Windows. We're no monopoly. We already ship the environment free with new PCs, anyway."
This stance against Microsoft is one of the rare firmly held strong opinions of mine. I certainly would prefer not hold this so firmly, but they made it impossible over the years.
If they don't support something, it's bad, if they do support something, it's EEE, which is bad. And this EEE strategy is magically tied to the company name, instead of having left with the CEO that pushed it.
It's MIT licensed. If they do then it can be forked and community maintained. It could be similar to the mass forking of projects when Oracle acquired Sun. .NET now has a way bigger community than a lot of those projects did and they thrived.
There is a good reason projects like the Rust Language are dual-licensed under MIT AND Apache2 because only the later protects you from software patent claims.
So I wouldn't be so sure about MS not having any legal means to shut down forks. Even if they might not win in court, as long as they can make up something up, they still have enough legal war money to effectively shut down any unwanted fork just by threatening legal action.
Millions of businesses run on Microsoft platforms and software developed on/for Microsoft platforms for decades. I think you are painting darker picture than it really is.
Or please elaborate a little what you mean by "betraying".
I believe, sooner or later, MS will put some arbitrary restrictions on .net or some part of its toolchain, forcing users to purchase a license to make it usable. It will probably involve "cloud" to sign/notarize your binaries to distribute them and give MS complete control of the ecosystem.
Obviously, I have no idea what exactly will MS do, but after reaching some adoption target, MS will try to extract as much money as it can, because that's what they do.
The other posters in this thread mentioned the debugger is still proprietary. Anyway, I'm not touching this.
Technically the restrictions already exist, just as a part of the development experience.
- .NET Hot Reload is only implemented on Windows. It requires support in the .NET runtime, which is technically possible to implement, but the team has not gotten around to implementing it for years. This doesn't have to do with the issue around MS removing the "dotnet watch" command, it's for the "Edit and Continue" feature in IDEs.[1][2]
- MS was considering deprecating Omnisharp, the open-source language server that implements C# support for VS Code, and replacing it with a closed-source version. Since the announcement, commits to omnisharp-vscode have dropped off significantly. The lack of Omnisharp would mean there would be no real open-source C# development environment for Linux anymore, since MonoDevelop was abandoned a few years ago.[3]
I believe that issue was about "dotnet watch", which reruns the compilation when a file change is detected. EnC/Hot Reload sends new bytecode to a running process and updates classes/methods in memory. EnC has been missing from non-Windows platforms from the start. An IDE like Rider can't implement Hot Reload without support from the runtime.
As a user I honestly don't care how Microsoft license their tools. If they want to start charging for them I'll pay for them if I think they are better than the alternatives.
> MS will put some arbitrary restrictions on .net or some part of its toolchain.
I doubt this. Microsoft's monetary strategy around .NET for a number is years has been "look at how easy you can deploy/run/monitor your .NET app on Azure!", I don't see that changing to anything else unless there's a massive change of priority and executive leadership at Microsoft.
They certainly COULD do some of that stuff, but so much is open at this point, that I tend to think that a consortium of large businesses with hundreds of billions on the line would get together and form the .ORG alliance or something like that to rebrand and make it fully independent from MS. The entire runtime and compiler are MIT licensed so with enough motivation provided, Microsoft's customers could easily break away, hire their top .NET engineers, and build an entirely independent ecosystem.
I just can't imagine it makes any business sense to be that hostile in today's world.
Yes, we are all so much better off because anything text gets sent in Word docs and anything graphical gets sent as PowerPoint slides. /s
Microsoft is probably the most aggressively mediocre company in history, and the poor quality of everything has extracted an enormous lost productivity cost. Those of you old enough to remember IIS and early internet Microsoft know.
Even today, it takes five full seconds for my work Outlook webmail to load. Every person in the organization waiting for each task in Outlook n times per day adds up to a lot of lost productivity. And Outlook adds nothing to email that we haven't had since forever. Microsoft just took it over and made it slow and convinced the corporate types to use it. Rinse and repeat for everything they do.
I searched for any news regarding recent removal of MagiskOnWSA repo from github, but of course none found. Really nothing to worry about, instead look how easy to develop using powerful and free dotnet core|framework|. and deploy apps on Azure in just one click.
.NET Core is open source and any forks receive a perpetual license protecting it against any Microsoft patents, so long term it'll be just fine. The only thing Microsoft really controls with absolute authority is the trademark.
It was VB, Access and Sharepoint heavy marketed by MS evangelist drones as primary LOB tools just before Windows.NET
The next .CLOUD or .AI frameworks is probably on its way in minds of board of directors. Microsoft is great in producing APIs and frameworks thats not last. And drones will happy to explain how powerful and simple things now.
I picked up and used XNA for the global gamejam 2012. It wasn't a terrible experience, so I went to use it again for 2013 but they'd since killed it off.
FWIW, I'd approach other FAANG with the same "get ready to be betrayed" attitude I have to MS as well. Try to entrust as little as possible into their hands, but still do what's necessary to your business (i.e. don't be fanatical about it).
Not OP, but my favorite stack is Rails/Postgres/Linux. It doesn't get more open and less corporate-controlled than that these days. To enjoin OP, however, I get worried when I think about the GitHub acquisition. To me, GitHub was everything open and non-corporate, like my stack. Then Microsoft bought it, and now I fear that they will bring their MSDN "dev portal" schtick over to it.
They've already started integrating LinkedIn into Outlook. They will probably be doing the same thing with GitHub in Visual Studio, and downplaying others (like GitLab). Will it affect my use? I don't know. I doubt it, but I wish I didn't feel like I need to be watching them like a hawk now, and be ready to move my code to another provider at short notice.
The really stupid part? Out of other companies who could have bought it, and would be interested in it, Microsoft is probably the best choice. Certainly better than Oracle or Salesforce.
Not sure it matters, but my go-to is Python/Django/nginx/Ubuntu Server (VMs). I like open things with a track record (no chancing the latest shiny thing) that have proven to work for small-to-mid scale and I can count on in terms of securing talent. None of that "3 years of experience" for a framework that is 1 year old.
I also have no issues depending on corporate things that I don't like, for example GitHub, as long as they can be replaced with minimal loss. I'd git remote set-url origin <something else> and be done with it.
As a recruiter, it is clear that the most successful languages still growing in popularity in 2022 are:
C#
JavaScript/TypeScript
Python
Edit: golang is small in terms usage but is on the way up definitely
All the rest are in decline or remaining at a constant level of acceptance.
So if hiring / recruiting is important, use C# or TypeScript or Python.
If you want to cause yourself deep hiring/recruiting pain, build your systems with Ruby or use lesser known frameworks and languages such as Erlang/Elixir.
C# seems like an excellent choice for Linux based development - it's mature, there's a vast talent pool, theres vast knowledge and community resource for getting problems and questions answered.
Your list was surprising but I'm in infrastructure software. There seems endless demand for c++, java and lately rust as the languages used for database implementations.
I've recently been working with a C# app that's based on a nearly out of support .net 3.X version I think. It's fully inherited from a tech partner, but we have free reign to modify it as needed. I was excited to try and port it from a Windows only older .net app to .net core 6, but unfortunately too much of it doesn't have a simple to port to equivalent in .NET 6 and it would require us to completely rewrite it. This is all because it's a SOAP client, so I'm happy to forgive Microsoft for not spending too much time there. We don't have any control over that part either. It's the only thing in our entire infrastructure that runs on Windows and costs multiples of just about anything else we've got running, because of the Windows license. Huge bummer. We did get it streaming our data into BigQuery though, so that was cool to see work so well even on an older code base.
I think at this point my last real major gripe with .NET is Visual Studio. I've used it on and off over the years, but every time I get back into it, it's just so much mental overhead to try and understand how the hell things are organized. It's like jumping into an ice bath coming from JetBrains/VS Code land. Just really unpleasant, but I don't think I'll be able to get away from it with this older C# code base.
Somewhat unrelated. I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows. Trying to guide your IT department on how to install specific compiler versions to get TensorFlow/PyTorch and more importantly other less popular Python packages that require you to build from scratch on Windows has been a nightmare for so long. It's one of the things I mostly singularly dread dealing with. I really wish we could just enable the dev/compiler tool chain support without requiring admin credentials and have it be fully automated instead of trawling around the nightmarish Microsoft downloads site.
More likely, SOAP as in ASP.NET (old one), which has been around since .NET 1.0. Few people remember these days, but the reason why .NET is called .NET is because it was pitched as "all about web services" back when XML and SOAP was the new hotness.
There's always Rider which works very well for .NET stuff.
For older applications, I would consider Mono or WINE if you really want to run it on Linux. We are experiencing the same scenario where we have an application that was built on .NET 4 over 10 years ago and there's a couple of packages we rely on that will not work on .NET 5/6. We have a rebuild planned, but it will be a large overhaul.
Not everybody's company is going to pay for a license if they already are licensing Visual Studio for everyone.
As an individual, I only have a little bit of time to tinker with personal projects, and while I like C#/.NET so far, I'm not yet at the point where I feel comfortable paying for Rider's subscription. So I'm also mostly using VS2022 Community and VS Code (on macOS) so far. Hoping to eventually get to a point where paying for Rider becomes a no brainer.
> I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows.
Not sure if this is what you mean, but vs_installer.exe supports command line arguments like --add, so you should be able to craft a giant command line for IT to copy. Used it for work for the NodeJS equivalent of your use case.
You can avoid the giant command line by providing a configuration file exported from a “known good” install:
From the installer GUI on a machine with the correct set of components installed, click the “More ▼” button, then choose “Export Configuration” and follow the resulting prompts.
Alternatively, the installer’s “export” command-line operation does the same thing.
To use the resulting config file, either supply its path using the “--config” option to the installer’s “install” and “modify” command-line operations, or apply it from the GUI by clicking “More ▼” and choosing “Import Configuration”.
This is also handy in non-IT deployments to quickly replicate an existing VS install on a new machine.
Incidentally, even if you are going to go with the “giant command line” approach, the export mechanism is an easy way to figure out a valid set of component IDs to supply on said command line, though it doesn’t necessarily generate the smallest set of component IDs able to produce a given configuration, due to the presence of workload IDs and the fact that component dependencies are automatically installed, even if unspecified.
Had to fix a bug in a hobby app that uses .NET Core for its backend last evening. I miss working in this ecosystem daily (back to node and rails for work), it's such a pleasure. The best developer experience I've ever had. If anyone is hiring and you use .NET... :)
Middle of nowhere, Canada, far away from any metro area. I've been working remotely for years as a result. Seems tough to find any .NET work in digital space (plenty of javascript and rails from my experience). I ascribe this to the perception of .NET being more corporate.
I'm hiring .NET developers in the near future for an RPA platform focused on real estate. Send me your LinkedIn, CV, or personal website at {my username}hn@gmail.com.
We are fully remote with flexible hours and offer 4 day work weeks.
For reasons currently unclear to me, installing this seems to cause apt to remove Discord.
The following packages have unmet dependencies.
libc++1-14 : Depends: libunwind-14 (>= 1:14.0.0) but it is not installable
libc++abi1-14 : Depends: libunwind-14 (>= 1:14.0.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
On an opposing note, updating my Arch system (pikaur -Syu) recently wanted to install Electron 20 and remove Electron 19, which the element-desktop package was still depending on. I wasn't using it so that's an easy uninstall. But there's nothing inherent about Arch that prevents these issues from popping up every now and then.
> On an opposing note, updating my Arch system (pikaur -Syu) recently wanted to install Electron 20 and remove Electron 19,
hm that's weird, with yay it only ever adds new electron versions, never removes the old ones. e.g. there's electron12 to 20 in the repos and they can be installed side by side
This is not generally the case: "apt only allows one version of something to installed at once" - apt and dpkg always supported having different major versions of a shared library installed concurrently.
> The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes. This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version.
In this libunwind case the situation is more complicated, the its different versions have conflicting subdependencies.
I wonder if this opens the door for .NET applications to be included in Ubuntu? Neither this blog post nor Ubuntu’s [1] mention that as a possibility.
Just thinking from a Ubuntu package level, where libraries live in packages separate from executables, it might be possible to create library packages using the result of ‘dotnet store’. Then executable packages could reference them when running ‘dotnet publish’. [2] That way multiple executable packages could share common libraries.
Replicating the packages of a language package manager (Nugget in this case) into a system package manager (apt in this case) is probably not fun. You will end up with dependency nightmares or one system package per version of Nugget package. So maybe it’s not worth doing.
Ubuntu briefly included Mono-based apps in the core distribution. Sadly the backlash controversy after that around the size of the Mono runtime (which wasn't much bigger than Python at the time, but got a bit of a "but we've already got Python, we don't need 2 Pythons" in response, and ahead of the whole python2/python3 split, hah) and the worse controversy about Microsoft-adjacent conspiracy theories did a lot of damage to the then-nascent world of Gtk+ based .NET apps in Linux and left some scars.
The first part seems to add confidence that if the right apps/developers came along, Canonical themselves likely wouldn't have a problem putting them in the distribution. The second part would explain why there aren't just apps waiting in the wings for it and why "the community" (or at least certain vocal parts) may still not be as welcoming of .NET-based apps in the distribution this time around like it played out that previous time.
I don’t think it would be wise for apt to repackage or recreate Nuget functionality. The initial install of dotnet should be done by apt, the packages should be handled by Nuget.
If you want to package an application which depends on a library, you have to package the library, too. This is the (pretty much sole) reason that distros package libraries.
From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.
IME (and I worked at Microsoft previously), Nuget and MSBuild have decided that application developers should have full control of their dependencies and that system administrators can override these things but not easily. I understand that distro-level package manager want to make it possible to upgrade a system library for all applications, but the .NET world isn’t going in that direction (yes yes I know about the GAC et al. but that’s more trouble than it’s worth)
The implicitly assumption in the .NET choice is that dependencies may not be backwards compatible, so compile against a specific version and go ahead and ship that assembly in your self-contained deployment. Yes your packages are bigger, but disk space and bandwidth are cheaper than developer time and support costs.
Application developers can still pin their in-ecosystem library dependencies to exact versions and have downstream, distro-level package managers respect that while building everything from source and making the system package manager aware of all of those library versions in more or less the usual way. (That's how building Rust and Go applications already works on NixOS, for example.)
That's why I say it's largely a solved problem for language ecosystems that tick a few basic boxes.
Can't Nuget and MSBuild support this? Can they not dump lockfiles like common build tools for Rust, Go, Javascript, Haskell, Python, Nim, PHP, etc., do? Is there a general problem (like there is with Java) where actually building from source is so difficult that it is rarely done?
Anyway there's already a suite of Linux packaging options built around the kind of app distribution model Microsoft expects, and Canonical even has one of their own! I don't see why they wouldn't support distributing .NET applications as Snaps, or maybe even automating the creation of Snap packages for .NET applications.
There is no immediate problem with building from source, there simply isn't much of a benefit to doing so. An assembly compiled with different optimizing C# compilers will be virtually identical assuming the source files are identical. I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.
I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.
> I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.
I think if .NET were integrated into Linux package management systems in the 'organic' way, 'building from source' here would still be 'building from source with the assistance of the distro package management tooling', which would mean that you would get intermediate build artifacts for all the deps, recursively.
If you have to do that manually, it would suck. But when automated tools can generate those packages, it works relatively nicely.
> I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.
Yeah, and I can see how distros burning their own compute bandwidth building the same binaries into their own artifact repository systems instead of using Nuget might seem like more of a religious rite than a purposeful task.
But I think the ability to uniformly inspect and update the software on the system is a big deal when it comes to Linux distros, as is the ability to add source patches, especially for backwards compatibility or security fixes, to most people involved in putting distros together.
I don't know if Canonical is up for it with Ubuntu, but it does sound like building dotnet applications in a way that is conventional for Linux distros is certainly possible. Alternatively, something like AppImage, Flatpak, or Snap seems like a natural fit for distributing apps with libraries shipped directly by the publisher that Ubuntu or other distros could use to include .NET applications.
Yes I think it is possible to ship dotnet applications and packages as apt or other image formats. What I would do is to put the Nuget package inside the deb package, extract it into the local Nuget cache, and then let Nuget discover it as if it had downloaded it.
Unfortunately, packaging applications built on .NET is still a challenge for any OS that wants to build everything from source and doesn't allow network access. Like you say, duplicating nuget into os-app-package-manager is challenging. Even side from the duplication, we need to bootstrap the ecosystem, in particular dealing with cyclic dependencies and version explosion as a result of all the different versions of all the dependencies that an average dotnet application needs.
Ironically, .NET is positioned to use a shared runtime but Linux has all the package manager tooling and Microsoft's never took off. The buggy nature of shared runtimes on Windows meant that the culture is to ship a full runtime with your .NET app.
I'm not sure going back to shared runtime libs is worth the headache but I guess if you were really resource constrained but running .NET it would work for you.
It has been rumored for years that Microsoft might acquire Ubuntu. This is an interesting move though not proof of any such future merger. All of that said, it would be nice if Microsoft had the same level of cooperation with Fedora and another distro or two as well.
(And where the hell is support for .NET Core on FreeBSD???)
Fedora and Red Hat have offered .NET packages for years. We've worked very closely with those folks and they've taught us a lot about how to work collaboratively with distro maintainers. We meet with them weekly. Notice that Fedora is mentioned in the blog post and here: https://docs.microsoft.com/dotnet/core/install/linux#officia....
This just puts Ubuntu at the same level as Fedora/RH/Arch were before, am I right? In the sense that this just means .Net is in the official repos (as was the case for Fedora/Arch before)
For FreeBSD support, see the following issue for the porting effort. The community has been working like hell to make it happen since 2015 and at this point we have regular unofficial builds:
https://github.com/dotnet/runtime/issues/14537
About 2 months ago they crushed hopes that official FreeBSD support will happen anytime soon by clearly stating that at this point, updating their Quality Assurance process to support FreeBSD would not make business sense for them as they have to put together an extensive test suit and manual testing procedures for every OS. Microsoft folks remain friendly and helpful in the thread though.
The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. This is one of the things that complicates its inclusion in the ports tree. Building .NET for FreeBSD is close to rocket science, the community has worked to make the process way simpler. It is frustrating that the .NET team refuses to take things from there. Providing FreeBSD support is what I would expect from them to strengthen their cross-platform posture. This is the last major platform they need to support, and one being heavily used for servers.
> The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process.
As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavior™ that is likely to get in the way of any distribution (Linux or FreeBSD or macOS or anything else) that follows basic best practices with respect to build sandboxing on their CI/CD systems, build clusters, etc., even if it can eventually be hacked around.
Building software outside of a sandbox with restricted network access is how you get lovely exports like credential scrapers in your setup.py or your NPM install hooks, perhaps running as root. Downloading your dependencies at build time from within the build system without first emitting a manifest with hashsums of what you intend to download is a huge problem for reproducibility, too.
That would make a lot of sense, despite the backlash it would generate.
Remember when they acquired GitHub, developers were vouching to move over to GitLab. Yet very few did.
The same would probably happen if they acquire Ubuntu. Developers would vouch to move to another distribution, yet few will, because Ubuntu is so much nicer to use than the competition.
I'll be one of the few. Maybe I'll give a try to Debian but probably I'll end up using one of the Ubuntu replacement distroes that will popup. Or Pop!_OS outright.
I'll never trust Microsoft again after all they did in the 2000s. Transitively, I'll never trust any comparably sized company.
Can I ask a Ship of Theseus kind of question? Is there any amount of shot-caller employee turnover possible in the last 15-20 years that would cause you to reset your projections of their ethicality? Relatedly, is there an amount or form of recompense possible on MS's side that could reinstate your doubt? Or is there a general lack of trust in unchecked / unethical capitalism that is insurmountable?
> Remember when they acquired GitHub, developers were vouching to move over to GitLab. Yet very few did.
GitHub benefits from a powerful network effect: if you want contributions from the greatest number of developers, you need to be on the platform they use and understand.
Ubuntu doesn't have a comparable form of social lock-in. As long as they are popular and until portable and/or containerized package formats for Linux mature, they do exert some network pressure on publishers, but not really end users.
> Ubuntu is so much nicer to use than the competition.
I don't think this has been true for some time. Canonical's server offerings are pretty much coasting on the mindshare that they gained with current-gen Linux sysadmins and developers who grew up experimenting with desktop Linux in the aughts, when the usability delta between Ubuntu and other mainstream distros really was vast.
They still benefit quite a bit from their willingness to bundle proprietary software with the OS, and from sheer inertia on the desktop, where they are still most likely to receive native packages by proprietary software vendors.
But the collection of desktop operating systems that actually attract new users to the ecosystem who will become the next generations of Linux sysadmins is increasingly comprised of distros that are not based on Ubuntu. User-friendly Arch downstreams now have more and more of theml mindshare that Ubuntu did when I was 'growing up.
The most popular Ubuntu-based distribution, which has actually surpassed Ubuntu both in interest from new users and in its reputation for OOTB usability, deviates strongly from Ubuntu in some core technical aspects that make some Ubuntu knowledge non-transferable.
APT is aging poorly, even compared to its RPM-based counterparts. It has recently been at the center of some high profile blowups where package installation triggers a catastrophic cascade of uninstallations that newbies would likely perceive as 'bricking' their installations. This has damaged the reputation of the most popular Ubuntu-based distros, including Ubuntu itself as well at driving home the case for portable/containerized package formats.
The success and growth of these portable package formats, including Snap itself, additionally threaten to undermine Ubuntu's strategic advantage because they work pretty much as well on any distro as they do on Ubuntu.
Moreover, Canonical's own offering in that space is already driving users away from Ubuntu. Snap is slow, clunky, space hungry, and bandwidth hungry, and the way that Ubuntu has chosen to force Snap packages for key software, e.g., Firefox, has had a negative impact even (and perhaps especially) among non-technical users precisely because it has a shitty UX.
Meanwhile Snap has failed to gain much developer interest outside of Canonical, and looks likely to suffer many of the same adoption problems as previous Canonical offerings in the space of core system software like Upstart and Mir. It seems that Canonical has not figured out a way, in the past decade or so, to displace Red Hat as the most influential corporation on projects that require widespread, cross-distro adoption to succeed.
Similarly to the situation witb portable packaging formats, there's a pretty clear trend in the wider Linux world away from relying on old-school package management 'raw' in favor of immutable operating system images. There are Ubuntu derivatives in this space, but the clear leaders are NixOS on the radical side and Fedora Silverblue for the more conservative approach that reinforces/enhances traditional package management tools with OSTree to gain some of the same benefits.
It may be that Canonical's advantage in the server space and among developers is 'sticky', now that Ubuntu is established in those markets, and that it's less ripe for the same kind of play that Ubuntu made by building mindshare first on the desktop. They may also catch up in some of these areas.
But for all of the reasons I outlined above, I don't think Canonical is in nearly as strong a position to retain its relevance as GitHub was, especially in the long term, in the face of one more thing that makes it less attractive to new desktop users for whom much of the appeal of running Linux in the first place is escape from Microsoft.
I would have expected .NET's core demographic to be mostly CentOS and RHEL users. But I imagine Microsoft really wants you to run your workloads in Azure instead of on-premise, and Ubuntu fits that model better.
We started with Red Hat. They were our .NET Core 1.0 launch partner (and remain a very close partner). You can run Red Hat on-prem or in the cloud (obviously).
I've always thought that a Microsoft Linux distribution would be incredibly interesting. They could give the user experience a new round of polish without being weighed down by the years of legacy support, compatibility, and cruft on Windows.
Does it come with telemetry enabled by default[1] as the Microsoft binaries do? Or does the Ubuntu version either remove that code or make sure to set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable everywhere?
If "Canonical and Microsoft are committed to working together", probably the former.
It depends a bit on what tools you use, but if you've jumped the ship from VS to VSC and mainly use the dotnet cli for things then there isn't much of a difference between platforms. If you're using VS, as in really use it and all it's feature, there is going to be a massive difference.
That being said, I've used .Net and C# for over a decade and it's frankly just a clunky language and toolset. It's gotten better with Core (now just.Net), but it's still just not there. It's not a secret that we've been doing more and more TypeScript where I work, but I recently did a little bit of Go and Gorm made EntityFramework feel like something from the stoneage.
So I'm not sure I'd really recommend it unless you already do a lot of .Net. It's not that it's bad, it's just that it's a dated way to build things in a world where the Java way of doing things makes less and less sense.
Interesting. Does Gorm have anything like Linq? autocompletion of queries? Compile-time validation between code and schema?
Once I disable Entity Framework object cache globaly (AsNoTracking), it becomes close to the ideal db toolkit for me.
I see a lot of strings in Gorm docs. Those are probably not checked during compilation. This alone differentiates Gorm and EF quite a bit. https://gorm.io/docs/create.html
Everything in the feature-list for Gorm is bog-standard for C# and Java ORMs. Do they support any special query languages comparable to OData, LINQ, or JPA?
Not wanting to get in a debate on whether you should use an ORM, but I just don't see anything really special about Gorm that makes the other frameworks "ancient".
I feel like the "Java" way of doing things in C# is simply a byproduct of inertia and outdated habits. You can model domain with records in C# in a very concise manner (F# style), you can pass around raw memory slices with Span<T>. Writing simple CLI tools is incredibly easy with top-level statements and implicit usings, or even using bFlat [0] or ProcessX/Chell [1, 2].
Yeah, I was specifically curious about VS (not VSC).
I am not a vs/c#/.net dev but I tried it once on a windows machine and thought it integrated well and seemed to be a really nice DX. Probably the nicest DX for an "enterprise" stack.
I went from VS Enterprise to VS Professional to VSC over a decade. We still use Azure DevOps, and, a lot of Azure things in general, so it's not like I'm anti Microsoft or anything, but I frankly don't miss VS the slightest.
I haven't used Go, and Gorm is new to me. I've just looked at it (with 15 years of AR experience, and a couple of EF), and it looks quite a bit like EF to me. In your mind, what makes it significantly better than EF?
On Linux you can use Rider or VS Code both of which are able to satisfy most of your professional needs, especially when it comes to back-end and/or web dev. I'm not sure what is the situation when it comes to visualizer for XAML used in cross-plat UI frameworks like Avalonia or Uno Platform but honestly I've never relied on those because even on Windows they can never compete with something like Xcode visualizer for Swift UI.
Other than that, it is smooth and in many advanced scenarios Linux has better support than macOS, unfortunately (still decent, just has quirks).
Also, check out Native AOT in the upcoming .NET 7 because it is really nice for building small and lightweight CLI utilities in .NET and just shipping them to users like you would if they were written in C++ or Rust.
Not exactly Linux but switched to Mac earlier this year and pretty happy with Visual Studio 2022 there. Not nearly as feature rich as the Windows version but very comfortable and performant.
Seems like great news but I wonder if these releases help the .NET ecosystem in a meaningful anyway. Almost all .NET developers I know still use Windows even on cloud.
We maintain container images for both Linux and Windows. I can tell you that they both get a LOT of use (>10M pulls/month). .NET is very much a cross-platform app stack. Also, we get plenty of bug reports on Linux (which we diligently fix). The days of .NET being Windows-only (and closed source) are long over.
How much of that 60% is running .NET apps, though?
Not everyone who uses Azure is a "Microsoft shop", in terms of programming tech stack. Plenty of people use Azure as a cross-cloud redundancy play, or because they do business with Amazon competitors that refuse to have their data on AWS.
My understanding is that a growing percentage of that is .NET. Even "big corporate" realizes .NET Linux deployments on Azure are cheaper and are trying to cost-cut/cost-save. There's still a small feature parity difference in Azure between Linux and Windows servers, primarily in my experience in "no touch" Application Insights telemetry/logging for application state (and user) monitoring as a major one. If that feature gap closed I expect that 40% to drop rapidly in Azure simply for cost cutting reasons. Anecdotally, I've been feeling internal pressure in my company to move .NET deployments to Linux servers for cost savings and we've done some initial trial balloons on the engineering effort for working around that feature gap.
I met a guy a while back who did stints for both Amazon and Azure orgs.
It's the reverse in AWS, they have a bit more Windows market share than Linux. And he also backed up your statement.
His take (which was just his speculation) was that the virtualization stacks ran those OS's more efficiently. HyperV with Linux VM's and KVM with Windows VM's. I have no idea if that's true or not.
I work in games so it's Unity C# (which uses a Mono port but .net 6 'soon') and a backend that uses .net in a linux container. Using C# on both makes it easier for devs to work full stack. It's been easy to run the backend app in k8s.
I've been developing ASP.NET Core Apps on Windows since 2017 (when .NET Core support was added to our FX) and have created & deployed >50 .NET Apps exclusively to Linux, primarily Ubuntu so this is a welcomed announcement.
.NET definitely has first-class support on both Linux and Windows.
I've shipped .NET applications in organizations where adding Windows hosts never would have been contemplated, but adding a new application framework that ran on our standardized Linux environments was no big deal. Ops folks are often much warier about adding heterogeneous compute environments than they are about adding new application architectures, so an easier onboarding process for Linux shops experimenting with .NET could plausibly drive adoption.
A fully devoted Linux developer here that never touched Windows' ecosystem(.NET, Visual C++, win32 api, all those), any reason for me to jump on .NET? where does this runtime run(x86/windows, now linux, what about MacOS, and embedded systems), and what's the selling point(web framework in c++ like language? a better c++/java?)
I think C#/.NET has more performance-oriented affordances than Java:
- It supports structs, and unboxable structs called "ref structs". They let you to avoid GC/heap-alloc for small data structures with clear ownership semantics.
- It uses type reification for generics instead of type erasure. Combined with value-types, this can produce very optimized code. The downside is larger binary sizes.
- It allows unsafe programming with pointer arithmetic where performance is truly critical. This is where C# is closer to C/C++ than Java.
- Supports native compilation to a target architecture. This lets you avoid JIT overhead and lets you ship self-contained binaries (like Go).
- .NET supports source generators which can let you keep maintainable code and generate an optimized one.
Performance aside, C# is a very pleasant language to use, and .NET is a delightful runtime. I'd say give it a try and see it for yourself.
The main target is enterprise software systems and web backends. Asp.Net is a very mature framework for Web APIs and MVC applications.
Entity Framework is a decent ORM solution supporting several popular DBs with tools for code generation and migrations, and LINQ is a complementary query language that is useful for in-memory collection operations as well as db queries.
And I think the largest value is in the NuGet software library ecosystem, things like MassTransit for service bus and queue communication and many many others.
It’s a well-supported ecosystem of first party and third party software with a lot of modern features, but definitely still in the realm of managed runtimes so not a competitor to C, Rust, etc.
True, the non-Core versions really aren’t worth considering for a new dev entering the ecosystem, and MS has made it clear that .NET Core is .NET going forward.
ASP.NET is rumored to drop the "Core" name somewhere in major version 7/8/9, just as .NET dropped "Core" in .NET 5, which is a higher version number than both sides of the fork. There was briefly an ASP.NET 6 (technically, the baroque "ASP.NET 5 MVC 6"). There's never yet been a version higher than that. I think part of the hold up there were some builds of the old Entity Framework made to version 8 or 9, and ASP.NET is not likely to drop "Core" until EF Core is able to drop "Core"?
I've spent most of my career in Java and there are certainly some things that C# (I know, somewhat tangential to .NET at this point, but still relevant) does better. E.g. if I want to use declarative style to describe something I want out of a data structure, I'd much rather use LINQ than Streams.
It's broadly in the same ballpark as Java, but with more language features (e.g. sequence comprehensions, pattern matching), and it offers some low-level features like raw pointers and spans for when you want performance or interop with C.
GTK/Gnome style UIs have supported C# for decades at this point. Including some programs that were shipped by most mainstream Distros https://en.wikipedia.org/wiki/Tomboy_(software) (not without controversy; but technically they worked well)
Well, times clearly changed but the end goal remains the same.
I don't have data, however, from what I see/read, there is a tendency of developers/companies using .NET environments to just go for Azure. It looks like it comes as a big package, while it doesn't have to be like this, but hey, that's how it works especially in enterprise companies.
How much does/did it cost to port .NET to mac/Linux? Compared to what you gain just by having a few customers in the cloud, maybe crumbs: provide a good dev environment, people will clearly opt for your cloud services.
> Today we are at the Red Hat DevNation conference showing the release and our partnership with Red Hat. Watch the live stream via Channel 9 where Scott Hanselman will demonstrate .NET Core 1.0. .NET Core is now available on Red Hat Enterprise Linux and OpenShift via certified containers.
I still feel Microsoft development experience is pretty poor and has been sometimes hostile in the past, and still don't have much confidence nowadays.
Maybe because it's not a popular language, but the F# experience for me has been bad - tried it two years ago with F# 5, and recently with F# 6. The documentation in both cases was immature/inconsistent to broken.
I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts.
The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews.
I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options.
Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.
Every time I tried F# with .NET tooling it felt like the implementations were there to tick the "supports F#" checkbox - and nobody actually used it for the thing I tried to do because it broke really early on.
Early on one of the big selling points was reading all those type provider articles. Then I've tried it a couple of months ago and it was such a broken mess - not worth the time. From what I've read this isn't just my experience.
With, record types, switch expressions, top level expressions, file scoped modules, global usings, etc. C# removed a lot of cruft. Roslyn source generators actually work unlike type providers. If they improved the REPL/scripting aspect of C# I think there would be very little arguments for F# other than catering to FP crowd who like to like |> to |> write |> like |> this instead of this(like(write(to(like))))
I'll take the opportunity to jump on this thread to fish for recommendations on courses/guides to learning C# to be used with .NET - for programmers. I mainly see those that are way too simple or way too Windows specific.
yeah I'm quite curious, but it appears to be undocumented outside of the code, it reads like a way to strip a container given a yaml config file to extract out the important bits.
I started writing mobile apps for windows phone when I was in high school (2013-2016), then it got killed years later… then when I got into college, they had this things called UWP (Universal Windows Platform) I wrote a simple kanji dictionary for it, then 2 years later, it got killed. After then I started sticking to Flutter and native iOS, got tired of being played like that lol
Last couple times I used cloud VMs with ARM64 CPUs running some Linux. A systemd service to run asp-net only takes a few lines of text in the *.service file, like following:
I have two DigitalOcean sites on the same VPS just serving from kestrel behind an nginx reverse proxy and then one site on a Hetzner VPS where I was playing around with k3s.
Hetzner & Digital Ocean are great value hosting providers, we maintain GitHub Action deployment scripts that can deploy to any generic Linux host using Docker Compose + SSH, that our latest Litestream support uses to effortlessly deploy .NET RDBMS Apps (with savings up to 40x vs Azure's recommended managed RDBMS configuration):
Anything that's win-x64, linux-x64 or even osx-arm64 (at home :D) honestly. At work we utilize a mix of k8s linux hosts (standard mcr.microsoft.com/dotnet/aspnet:6.0 image) and windows hosts where services are ran with Kestrel (default ASP.NET Core host).
I use a VPS. The strange thing is one site never drops a connection and another one does. I'm not sure if its the physical location or my config but one of the two instance works very well. Its a $5 VPS too
As a systemd service on physical ubuntu servers. Each app running on its own port, haproxy server in front routing different domain:80s to the corresponding ports. Stateless apps so sideways scalable.
I host them on my Raspberry Pi 4 at home. I combine it with noip.com to get around the dynamic IP problem. Obviously that's not for mission critical apps.
Canonical has been cuddling up to Microsoft for years. With the WSL collaboration (I know there's other distros but Ubuntu is the one in all the marketing buzz).
Tbh I'm surprised they haven't been acquired by Microsoft yet. They're clearly aiming straight for it.
And still, there is no Visual Studio for Linux, and Microsoft is committed ( https://isdotnetopen.com/ ) to ensuring that VSCode provides a second-class .NET experience to Visual Studio proper.
Seems best avoided by any company which is not already a Microsoft shop.
Yes, JetBrains has done a nice job reverse engineering key, proprietary pieces of Microsoft's .NET ecosystem to create proprietary components of their own IDE.
Yep, very similar to the JVM. Also .net7 is releasing platform native aot exe compilation (for simple scenarios) so you don't have to run the full CLR & JIT saving lots of memory.
Not what that means. "embrace" as in EEE means embracing some pre-existing open source standard, prior to "extend"ing it with features and quirks that people start relying on. Thus making the standard irrelevant if the implementation that everyone actually uses is different.
.NET is their own thing to begin with and nobody suggests rewriting core pieces of Linux with it. It would be more accurate to say, based on the reports of .NET working better on Linux than on Windows, that they're promoting the embracing and extending of their own Windows ecosystem by the Linux ecosystem, because they feel that they'd benefit more on balance from keeping those customers on .NET and using Azure than they would by keeping them in the Windows ecosystem which is probably a lost cause anyway.
It doesn't make sense to apply EEE here, but it doesn't stop every popular thread about .NET having someone claim EEE. But every time, it's a different stage. Sometimes it's the "embrace" stage, others say it's the "extend" stage, and others say it's "extinguish" stage.
> .NET is their own thing to begin with and nobody suggests rewriting core pieces of Linux with it.
Yet. But on a few distros it was heavily encroaching on default installed GUI applications. I don't know if that's increased recently because I've been straight Debian for 5 years now, but there's not a huge jump from that to the rest of userland.
edit: I think Miguel de Icaza was responsible for a lot of that incursion, and he seems to be drifting into the EEE interpretation of MS handling of .NET, too: https://news.ycombinator.com/item?id=31761130
It runs better than on windows. For example, all ASP performance testing, from techempowered, is done on Linux and not on windows. There are tons of info, videos about testing different workloads on both OS and seeing that Linux always wins
We recently upgraded from 3.1 to 6, which was a total non-event. The code base that was around for Core 2.x is still the same one we have today. Some substantial changes made to the web interfaces and hosting, but nothing in the business logic or data models was impacted.
We currently use Self-Contained Deployments to Windows machines, but there are only 2 minor methods stopping us from using a Linux image as well. Looking for a really good reason to make the jump, but I can't justify it to the business yet.