> 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

A few reasons.

> Not having to pay for Windows Server licences?

Chances are that those licenses are paid for already so this is a sunk cost.

> Options to use Kubernetes or deploy to container services that run on Linux

I think this would be a hard sell - "hey, let us migrate platforms so we can rewrite our entire production infrastructure "

> I think this would be a hard sell - "hey, let us migrate platforms so we can rewrite our entire production infrastructure "

Also "Oh and we need to hire two full time devops engineers to take care of the thing" :)

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.

I am in the process of moving a .Net web forms to .Net core razor pages and the performance difference is insanely noticeable.

> And ASP.Net Core is an insanely fast web framework. It beats every other major framework written in a managed language by a mile*

* In synthetic benchmarks

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.

https://www.techempower.com/benchmarks/#section=data-r21

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.

Host: https://gist.github.com/neon-sunset/767cb0693c3ff222f78b236c...

HTTP Benchmark: https://gist.github.com/neon-sunset/d936e54bfec1031d1628c338...

Ok, but how else do you compare two frameworks?

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.

Two sides to every position.

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.

> given that it's so easy to just look at the SQL it generates and be like "yeah this looks reasonable".

This makes the assumption that the viewer knows what reasonable SQL looks like in the first place.

> they exposed our entire database as a service to customers

ActiveRecord is the least of your problems, then... seems like you may have a fundamental problem of inexperienced or foolish devs.

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,...

Technically it isn't .net core anymore, but just .net.

The many different versions were quite confusing. I am happy that they are now unified.

Old .net has become ".net framework".

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.

> Old .net has become ".net framework".

From my understanding, thats not quite right. AFAIK framework was adapted to differentiate it from standard, core and mono.

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.

[1] http://regexstorm.net/tester

Thanks but regexes I know pretty well, the regex object docs just were horrible.

> Christ, the mess that are the docs.

You don't love getting 404s almost all the time?

What was the problem -- the regex pattern, or some API?

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.

.NET's terminology is as clear as mud:

https://stackoverflow.com/questions/51390971/im-lost-what-ha...

If you're on that .NET train check this out as well, keep it on the DL though

https://fsharpforfunandprofit.com/why-use-fsharp/

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.

Thank you -- I have heard of fsharp but wasn't really familiar with the answer to the question of why use it?

The benefits of tools built into the functional programming world with complete access to all C# libraries.

But it's hard to convince a C# dev to use F# when they're so comfortable and see no obvious need to switch.

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).

Especially on backgrounded browser tabs, users circuts were frequently lost. also People frequently multitask their activities. 3 minutes is nothing.

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?

> with Rails I have to introduce React

Do you know about Hotwire? It's Rail's html over the wire solution and seems comparable to Blazor.

Hotwire I believe wasn't introduced yet but was close to release when I left the Rails dev community.

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.

Absolutely -- fair enough

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.

> too few selling points

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)").

Not all, some rely on the runtime, like static interface methods.

Records can be enabled like this [1]

[1] https://github.com/louthy/language-ext/blob/main/LanguageExt...

I found that, but I didn't want to introduce more complexity into the build by requiring those same stubs be defined for just a slight advantage.

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.

.Net has run better on Linux (edit: better than on Windows) machines since at least before the pandemic.

I'm a Java dev, but I have also developed on .Net and running modern .Net on Linux is about as simple as it get.

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.

Your rubicon is about 5 years out of date. VS Code and Rider are excellent tooling for .Net on or off Windows OS.

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.

https://marketplace.visualstudio.com/items?itemName=ms-dotne...

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.

JetBrains Rider on Ubuntu/Mac is probably a better development experience than Visual Studio on Windows.

I use JetBrains Rider on Windows instead of Visual Studio and love it.

Same here. Resharper + Visual Studio is about equivalent to Rider, but the performance of Resharper + Visual Studio is *horrible* compared to Rider.

As long as it's not a desktop application that requires WPF.

WPF won’t run on linux, so that’s not in question either way.

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

VS does not run there. But you have Jetbrains’ Rider there.

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.

Code does... Visual Studio itself not so much.

Why is that a requirement to take it seriously? I've been deploying apps developed in OSX/Windows to linux boxes for 20 years...

I don't know.

I don't like Visual Studio and haven't touched it since I realized VS Code worked fine.

(I'm more of an Eclipse/NetBeans/VS Code kind of person.)

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.

That would be Visual Studio Code then. Runs just fine on Linux, yes.

Use Rider.

You're welcome.

Currently, our customers are the ones running the software on their machines.

We haven’t run into a customer that wants us to host for them yet (and probably won’t ever in our market of banking).

Azure App Service linux is much cheaper than windows.

I would not say the cost is a fraction. The cost of the machines are certainly a fraction reduced.

For most businesses with less than a hundred instances, the cost is negligible and probably is cheaper than the companies Slack bill.

Windows server licenses[1]!? Even looking at EC2 it's nearly 3x more expensive to run Windows than Linux, at a glance[2].

[1]: https://www.microsoft.com/en-us/windows-server/pricing?rtc=1 [2]: https://parquantix.com/linux-windows-aws-cost-comparison/

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.

Just one thought worth looking at.

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.

I DIY auth with .NET.

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.

What kind of applications you build primarily with.net6?

For work, a workflow/BPM platform for community banks & credit unions.

For fun, a game engine complete with a pure software rasterization pipeline.