Edit: can anyone give me the one-paragraph rational for why Net Core should take the world by storm? C# is a nice language and I'm a mostly happy VS user (except when I have to fiddle with MSBuild), but why should I go in and change the dropdown from ".Net Framework 4.5.2" to ".Net Core"? Let alone why any user of, say, Python or Node should drop everything and come over to C#.
Honestly, .NET core makes a lot of sense for new projects that need to be highly scalable. If you have an API service that's hosted in a cloud provider, or a tool that generates PDFs of items, or a tool that scrapes API data and chucks it in a database, then this is great. These are simple applications that do not need an awful lot of authentication, crazy UI frameworks, or other windows-only features.
The code itself runs faster [1]. It might not matter for business / CRUD applications, but that's a nice to have thing.
The biggest selling point is cross platform support. Now, I don't care if the company switches from Windows 2016 VM's to some variation of RHEL. My code will work on that too. This gives your organization improved flexibility and reduced technical debt.
If you have a big legacy application using .NET Framework, it's probably not worth rewriting it for .NET Core. You will run into package conflicts. I have had to rewrite ".NET Framework only" pacakges to support .NET Core. That will throw your estimates off and probably delay the project. And that becomes really difficult to justify to project stakeholders.
[1]: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...
I tried 2-3 times up to and including .NET Standard 2.0 to switch and got burned by busted tooling and package conflicts every time. I’m starting a new project now and am still wary.
One of the major pains of my life as a .NET dev who does .NET core right now is Nuget and binding redirects!
This is why it is very interesting that the next "Core" release is to be called ".NET 5". No more "Framework", no more "Core". Simple version math applies: .NET 5 > .NET Framework v4.6.8 && .NET 5 > .NET Core 3.0. Maybe it will be less confusion all around, hopefully, soon.
Besides this future perspective, the real benefit from it you have today is that your project will (unless it uses Windows APIs, which is unfortunately way too common) instantly run on Linux.
1. The cost of moving a standard .NET application to .NET Core. If the benefit is there, it'll happen, but for established code bases I don't see why they'd bother when standard .NET works fine.
2. On the web side of things, many of the big content management systems aren't on .NET Core yet. Umbraco is the king of CMS's on .NET, and once they pull their finger out and focus on .NET Core I think we'll see a wave of developers moving to Core.
3. For general web stuff, there isn't a solid reason for people to move from the likes of Ruby, PHP, and Python to C#/.NET Core.
4. There's still a perception that .NET Core is a WIP. That's understandable, considering .NET has been battle-tested for decades, and .NET Core is still (relatively) new to the party. There was also the csproj issues from a while back, and that set off a few people from fully switching.
5. The naming has confused everyone, so the safe option is to wait for everything to sort itself out. .NET isn't going anywhere just yet, and the switch to .NET Core won't be a huge one for those that have had to adapt to new C# and .NET libraries over the years anyway.
The big difference for me is that many .NET shops rely heavily on certain libraries and tools, and many of them are very slow to adapt. Umbraco, as a prime example, recently upgraded to Angular 2 for its admin section, and is probably a year or two away from an initial move to .NET Core.
Especially .Net Core's dotnet command is a wonderful tool that allows you to do basically everything with it - it can run, compile, even run tests - completely on the command line.
.Net documentation is however VERY crusty in my experience - all the fragmentation and outdatedness can very well lead to you accidentally reading and trying documentation that is 3 major changes behind, for a library version that has long been replaced. Nowhere will you find any warnings. That is hugely frustrating.
Visual Studio itself also makes a very broken impression to me, although admittedly it appears to improve.
Not sure whether that's going to be enough to keep Windows or .Net alive in the long term, since even Microsoft is moving to embedded Web apps now, abandoning their own 3 different UI solutions they have been pushing in the last 20 years (completely ignoring the 3rd party efforts like platform.uno, which they could probably acquire quite easily - seriously: Xamarin, but not this?!).
> Because most 'real .net devs' still work on .NET 4.x legacy
I almost wish Microsoft would stop putting much effort into dead ends, however. It's going to be possible to use WPF and even Windows Forms after .net 5 transition (they'll be windows-only libraries). VB .NET is still kicking (just let it die already). I wish they would have folded all those person-hours into .net core stuff instead.
It is their escape route when they outgrow Excel/VBA.
https://devblogs.microsoft.com/dotnet/net-core-3-and-support...
For cross platform there isn't an official solution, the closest would be deploying as an Electron app.
There are other entirely community-supported/third-party efforts like Avalonia and Uno around as well.
It may change with the shift to open source but I'm not holding my breath.
The last GUI framework they entirely "left to rot" was Silverlight, and that was a) almost a decade ago now, and b) a fellow traveler in the XAML space where migrations were quite possible, if maybe not always easy/convenient, back to WPF or forward to UWP.
With the weeding of some of WinForms and WPF in recent .NET Core work, and the addition of XAML Islands, even what were the dead ends don't necessarily look so dead today, or at least not so rotten.
Microsoft may be encouraging Win32 apps in the store, but is clearly saying that Win32 is undead and they'll continue to support the zombie and stop trying to kill it. They hope people will move on and they are providing more tools than ever to help migrate from Win32 to UWP. It's now a much more nuanced migration rather than a forced all-or-nothing conversion.
Wikipedia pages refer to everything in the past tense. That's the encyclopedia tone they require.
The closest thing to a "new UI kit" announced at the last BUILD was the ground up rewrite of the Windows version of React Native to make it "extra-Native". That change is from UWP/C#/XAML to UWP/C++/XAML. It's still JS controlling UWP controls, it's just using C++ to glue together the controls rather than C#/.NET.
The next closest announcement to a "new UI kit" was that way more of the UWP UI stack (almost all of it) is being "lifted and shifted" out of being directly inside the Windows codebase and deeply coupled to Windows releases and being moved in the WinUI library. WinUI has always been the parts of the UWP UI shipped outside of Windows Releases. UWP is moving to a model where they want to have as much as possible inside WinUI rather than inside Windows to make it easier to ship UI controls updates to application developers without so much of the rigmarole of "this control will only be in Windows 10 19H2 and later" making it easier for developers to use the controls "now" rather than waiting for a future Windows feature update and less headaches between what is in a current LTS feature update versus most current feature update.
(The next closest announcement after that, was that the Fluent Design team was merging the design efforts of what they've been doing for UWP/WinUI and what the Office team has been doing for the Web in the Fabric libraries, moving Fabric to being much more "Fluent Web". It should not be a surprise that the web is important to Microsoft's UIs.)
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
IMO, that means that. Net was never targeting the early adopter market. Ergo, their new platform, which is just different enough, isn't probably having many adopters. Secondly, having to wait for libraries to catch up is probably a real reason initially (till.net standard 2.0?) But that just meant when slower adoption.
Add to this, to maintain cross platform tooling, they're now have cli first tooling and flux around fileformats. That imo, made a lot of the traditional .net shops uncomfortable.
I've jumped b/w .net and Java and very comfy with Linux. Last few years have been. Net and .net core in prod. after 2.0+, it's been absolutely wonderful. Great language ergonomics and I can finally ditch vs for vs code. 3.0 is only going to make it better
But then, I'm probably far from the representative .net dev here.
I've been using standard 2.0 for new projects since it became available and building for dual deployment, either with Heroku or as a Windows service.
There's definitely a crowd of .net devs that doesn't care. They're probably not the ones on HN though. I've been holding my breathe waiting for all the libraries to catch up. We're so close!
I actually moved to .NET by choice for the Nemerle language a long time ago (C# mostly caught up, so I switched over). I might not be representative of everyone, but there's at least a subset of developers eagerly waiting on some small thing which will let them make the jump.
EF (not-Core) 6.3 has also been finally ported to .NET Core (though I think it is still considered "Preview" quality) which should be directly plug and play for some types of legacy applications (Microsoft seems hopeful it will mean more WinForms and WPF apps will just run on .NET Core now).
https://support.microsoft.com/en-gb/help/17455/lifecycle-faq...
Yep I know of a few places doing it.
Why isn't .NET taking over from python/node-with-typescript projects?
I haven't given net core 3 a trial yet but will use serial ports as my initial tests. In the 1.x and 2.x versions the serial port support was not up to the same level as the net framework.
Some of the .NET core stuff is pretty neat for basic demos to show off the tech. But for actual enterprise stuff I've so far found it really frustrating to work with.
Every large enterprise I've worked at in the last say 10 years, has software deployed across multiple dev stacks, with .Net being just one.
This very moment consulting at a large insurance firm I'm firmly entrenched in .Net as well as React and Python.
What you described may have been true in the distant past but you might need to update your views.
So if I am the only one who mentions a problem then it is well grounded and valid criticism, but if I am one of many developers who raises attention to the same problem then the issue loses credibility?
Your experience from already 10 years ago is truly remarkable. Given that before .NET Core you were tied to IIS, and therefore tied to Windows Server and also tied to Visual Studio and for that reason also tied to Windows as a development machine, and therefore automatically limited to what other software you could smoothly run in order to connect to databases and other technology it really surprises me that 10 years ago you were developing .NET in a complete non MS tech stack.
Re-read his comment. And be less angry. He wasn't saying that he worked on cross-platform .NET projects 10 years ago, just that big companies generally had/still have .NET projects, besides other tech stacks.
Anyways, my initial point was that .NET folks are less likely to look outside the MS bubble when making technology choices.
The other commentator said that he/she worked at large enterprises which had .NET teams and other development teams employed. That is great, but I don't see how that is relevant to my initial comment, because the question still stands if those .NET teams within those large organisations worked mostly within the MS stack or not.
My second comment was aimed at suggesting that I think it must have been the latter, given that before .NET Core many tech choices were forced upon those developers due to .NET being very tightly coupled to MS technologies.
So I take your point that large organisations might have many different dev teams, but that doesn't really say much about my point, which I still think can be true at the same time.
Didn't say anything was tied to .NET. I said Microsoft educated a whole industry of .NET developers to never look outside the MS stack. That's two different things.
Which MS technologies I consider inferior to non MS alternatives, but .NET developers insist on using despite them being inferior?
Let's start with the elephant in the room: Azure...
Azure Web Apps. They are slower than ElasticBeanstalk or AppEngine and only run on IIS, so .NET Core devs can't even run their .NET Core apps to their full potential by running it on Kestrel or Kestrel behind something like nginx. This itself is embarrassing and the fact that still so many people don't look beyong Azure Web Apps just because it's Microsoft is just mind blogging.
We love azure at our company. For one project One dev running Windows, a few running MacOS, one running Linux all coding our .net Core web application. Simple check-in to github kicks off a QA branch build of our app hosted on Azure web apps.
AWS is the default cloud stack. It's more mature, more companies run on AWS than on any other cloud platform, it has full .NET and .NET Core support, it even supported things like .NET Core or F# much earlier than Azure did. There is more resources online, more courses, more talent and more books on AWS than on any other cloud platform.
So how is Azure the default stack? You call it default, because Microsoft has spend so much marketing - aka educating you - to believe that Azure IS THE DEFAULT thing to use.
It's sad honestly, because it makes .NET development a lot less fun and I really like .NET otherwise.
EDIT:
Comment below me:
> I think rather because it is integrated into Visual Studio and SQL Management Studio out of the box.
This is another example that precisely proves my point, that .NET devs have been educated to stop looking beyond what Microsoft puts on their plate.
AWS also has fantastic Visual Studio support. It's only one plugin away. It's like installing a NuGet package, hardly any effort. But the default .NET developer rather uses an inferior cloud stack, because the effort to install an AWS plugin into Visual Studio is seen as more effort than having to deal with all the inabilities of Azure in the long run. That doesn't make sense. It's irrational and only because Microsoft has done such a great marketing it doesn't even occur to the majority of .NET devs.
CosmosDB is inferior to postgres or cassandra depending on use case.
Azure functions is inferior to lambda/cloud functions.
Azure in general is vastly inferior to aws/gcp. That's a point which is reiterated on a monthly basis on HN.
None of these three points are opinion. They're well covered facts.
We use RabbitMQ hosted on Azure via CloudAMQP. We had almost half a day of downtime because Azure performed maintenance on our instance, involving a restart.
CloudAMQP told us that Azure do this without notifying them, or us! We got told by them if we moved to AWS rather than Azure this wouldn't happen. AWS notifies you two weeks in advance and can allow live migrations without any downtime.
They said they don't actually recommend hosting on Azure!
I don't know for the other ones but the tooling for lambda is definitely better on aws, I had to patch around 500 lines of serverless-azure-functions to allow for missing features & fixing bugs. I should probably do a cleanup & do some pull requests one day.
How are those distributed cluster queries going on Postgres?
How do you plug a graphical debugger into lambda/cloud functions like I can do in VS?
GCP is so good that it is lagging behind Azure.
https://hackernoon.com/help-my-azure-site-performance-sucks-...
https://news.ycombinator.com/item?id=16099729
https://dvt.name/2018/02/27/microsoft-azure-sucks/
https://news.ycombinator.com/item?id=19056911
https://news.ycombinator.com/item?id=19658553
Azure's woes are well documented. I've experienced them first hand. In fact you'll find me with ~hundred upvotes describing my experience with Cosmos in one of these threads. Most engineers will take take aws/gcp without GUI tooling any day over Azure and its sea of undocumented bugs, performance issues, unlogged failures, and blown SLAs.
The only reason to use Azure today is either because it's the only thing you know or because there are external forces making you do it.
Or some other ones about the automated replies and lack of human support on GCP.
> The only reason to use Azure today is either because it's the only thing you know or because there are external forces making you do it.
Sure, that is why GCP is playing catchup with Azure and Microsoft had such a huge loss in Azure profits during the last years. /s
Anecdotes stop being anecdotes when you're looking at well over a hundred consistently negative experiences from different users across a number of unrelated discussions. At that point those anecdotes become the consensus. Try to find 1/10th of this many HN users shitting on aws or gcp, you won't be able to.
I didn't pick up azure looking for excuses to shit on it, like you appear to be doing and confirming in your profile bio. I came ready to deliver on the next round of projects, expecting something resembling parity with the other cloud vendors. And walked away feeling borderline defrauded by the delta between how MS markets azure and what it actually is.
"Said someone that never used either SQL Server or its GUI tooling."
You just sound like an angry teenager lashing out because their one and only skillset was shown to be poorly chosen. I'm pretty sure I've been using SQL server longer than you've been in the industry. It's middle of the pack at best today, sorry.
My profile bio is what I do in 2019, not what I have done since mid-80's.
In fact I have my share of delivering projects in AWS, across multiple kinds of stacks, all the way back when EC2 was started.
As an rdms? In what way? I mean, I do personally prefer Free software - and while it's possible, I think it'd be a bit premature to run ms sql in production on Linux - but "inferior" seems a bit harsh?
At what scale? For what kind of workloads? Use cases?
When engineers see a new project/problem, they start picking best tools for the job. When .net developers see one, they start picking items off the azure architecture templates.
I love C# and F#, C# was the first language that I truly enjoyed using. But I don't lock myself into tools or languages. Meanwhile .net shops actively train .net developers to only learn the MS stack and ignore all else.
I think if one takes a second to look at the amount of downvoting on both sides of this discussion, it's pretty clear that there's a distinction and polarisation between .net developers and modern full stack software engineers.
The first language I learned was Python and then I got a job in a .NET shop and I've been .NET since, to declare my bias. But I'm not dyed-in-the-wool Microsoft stack, I think Postgres is better than SQL Server for almost every use case (though SQL Server is superior to Oracle or MySQL for most others), that something like Rust is better for embedded or systems programming, that if you need cross-platform UI you're better off using something outside the Microsoft stack and that it makes a lot more sense to host a .NET web app on a Linux server and I have no interest in Azure, or indeed any cloud vendor's properitary tools.
I think there exists a trend, as in Oracle shops or IBM shops, for some large/corporate companies to tie in to a tech stack and consider, for example, Sharepoint or CRM or SAP, to be the solution to everything. I think this has less to do with individual developers and more to do with sales pressure. A lot of developers just code for a job, they have no interest in it outside of it being a tool to work with and since .NET is (in the studies I've seen) within the top 3 techs by number of jobs in most of the Anglosphere it tends to be overrepresented in corporate environments where development is 'just a job'. But there are also many companies using whatever tool is best for the job, within the constraints of what their team knows, or cost, or whatever those might be and to tar every primarily .NET developer with the same brush is going to annoy people.
I still regard .NET and particularly .NET Core to be one of the best environments I've used to build Web Apps in. You get great performance [0], type safety, memory safety, in my view the best IDE available, an excellent quality standard library, access to F# as you mention, etc.
I think stereotyping a ".NET crowd" is unhelpful, as is a stereotype about front-end developers all being boot-camp trained developers with little experience or C++ developers all being cranks who refuse to work with modern technology.
[0]: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...
I think it's pretty clear there's a polarisation between people who say "M$ trains sheep, .Net developers are dumb and blinded by marketing" and people who downvote that as a low quality comment.
Even you throwing "modern" in here, as a quick insult.
There's no need to rewrite working .NET Framework apps, but .NET Core has seen massive uptake with cross-platform development and runtime, incredible performance, and interoperability with just about every other common open source languages and projects.