Here's hoping .NET can some day shake off its Windows exclusivity stigma, as I've been writing pretty interoperable C# code for the past 3-4 years or so, and it's been a joy. Night and day compared to Java, at least.
I'll admit it takes some time to get started, but it's smooth sailing once you get past the initial hurdles of setting up your project, understanding some idiosyncrasies when it comes to ASP.NET/Web API/Entity Framework if you're going that route for your backend and such. And now with Blazor, I can even work on the frontend and touch Javascript as little as possible.
It's not really about the exclusivity, more so its about being driven by MS and their internal needs and their internal timelines, and nothing will change this. This is not a criticism of MS, .NET is their platform to support their products, it's just a reality. It's the same problem with Swift trying to escape the Apple ecosystem while ultimately being driven by Apple's needs.
So if you're an MS dev whose looking for some additional reach into other platforms, the increased interoperability is great. However for those of us not working on MS platforms, .NET has a huge uphill battle competing with every other platform available to us.
I think this is perceived much worse than it is. I work in a polyglot company. .NET had never limited us compared to the Java, Python, C++ or JavaScript languages we have also in use.
.NET is not tailored to something specific Microsofty. However, the .NET community is still challenged when taking 3rd party dependencies (which is the actual limitation) and then complaints when Microsoft is not delivering the perfect kitchen sink.
2nd that, couldn't quite put my finger on it, but this says it nicely.
I want to like what I'm seeing in .net, but there just doesnt seem anything compelling when compared to say Graalvm or even nodejs.
The VM market is very very crowded with fantastic offerings these days, many of which share many commonalities easing dev while each is tailored for a slightly different market.
I've been playing with the AoT compiler and it is decent, especially if you strip the binaries to get 10-20MB files.
Biggest hurdle for me (as a UNIX greybeard, Java survivor and occasional LISPer) is ramping up on idiosyncratic C# syntax and various generations of .NET libraries
But what little I've done in the past couple of months (with .NET 5) works OK in Linux, and the tooling (VS Code + Remote to have .NET on a remote VM at a safe distance from my Mac) suitably lightweight and hassle-free.
(full disclosure: I actually work at Microsoft these days but never developed for Windows alone - did mostly C++ and Java when I targeted it - and never did .NET before, as it only makes sense for me to use it now that I can target Linux)
Java is miles ahead in terms of cross-platform support. .NET applications may be running fine on other operating systems (I write them at $DAYJOB and they mostly do), but the development tooling is absolutely incomparable across OSes. As long as .NET is being developed and pushed by Microsoft, the situation won't change, because it doesn't align with their incentives.
Some people/companies also care about more than the big three operating systems that MS cares to acknowledge. .NET has no official FreeBSD port, for example.
.net is catching up very quickly in cross-platform support.
Tooling for. Net is miles ahead of anything else I've witnessed.
As for FreeBSD there's a huge nuance:
> FreeBSD support still requires additional work to implement features that are missing in the runtime to reach parity with the other operating systems. The community will most likely need to do that work in .Net 3.0/3.1 but I would like to see official automated daily builds for FreeBSD restarted with the master (.Net 5) branches of the necessary repos.
As for your statement on Microsoft. I'd trust Microsoft with. Net more than Oracle with Java.
VS Code is available everywhere and can even connect to remote environments. Visual Studio is on Windows, and there's a Mac version that's slowly getting better.
What other languages stacks provide a much better tooling experience? If you use IntelliJ then you get the same thing with Rider (which is just IntelliJ + Resharper), and the rest are all basically VSCode at this point.
If you're writing Java, you're going to use IntelliJ (unless you're a masochist). Conversely, if you're writing C#, you'll want to use Rider.
Rider is better than Visual Studio at the moment; we'll see what happens if they actually get VS 2022 cut over to be 64-bit, maybe the performance will be back to usable for medium-large solutions.
the miles you mention are one thing, but performance was always more important to me.
java pendant c# was always much more performance focused than java, having structs, unmanaged c# and c++ interoperability. it took java 16 years or so to accept that structs have their justification.
i also find the c# language much nicer than java. f# versus clojure are both excellent additions and again, f# is the more static and performant while clojure has very nice and inspiring features and aspects. it depends on what one wants here.
finally i think even if java is the larger universe, the .net universe certainly is not small either. if .net would not have taken the cross platform road i would have switched to the java runtime, but happily the opposite happened.
I've mostly been writing backend code which pretty much works just the same whether deployed on Windows and Linux, that's interoperability by default.
With Java the issues came from elsewhere- it was less so the interoperability and more just how messy the whole ecosystem is and how there are some aspects of the language itself (such as the excessive verbosity and the way the standard library is structured) that kept mounting up as little annoyances over time. Kotlin wasn't really an option at the time, either.
Perhaps developers should still consider .net as windows-only. Given how the large the runtime is and it's creator's reputation for pushing malware, I would not dare run .net core directly in any of my machines, and many non-windows users would probably feel the same. I don't think I even have the option in openbsd. Targeting Linux though I guess makes sense because of containers.
They played games for so long with keeping it closed source and then only opening parts of it to ECMA and then advocating Mono before finally opening more parts of it. I wanted to play with LINQ back then and couldn't. So non-MS people said screw it and moved on.
It's a great time to play with .NET on Linux/Mac these days. .NET Core (which was for not-just-Windows) became just .NET in .NET 5. F# and C# are both very easy to use.
You can even get a single static binary release that will work on platforms without .NET libraries.
True as long as you're not on an M1 Mac; right now it's a little bit of a mess since .NET 5.0 isn't fully supported and .NET 6.0 isn't quite ready for primetime (this release gets us a ton closer though). It's still doable, but with limitations; that said I still love my m1 air and .NET 6 will make it that much better/easier to do dev on it when it drops this Fall.
But yeah, it's a great time for sure, just good to keep that in mind since you also can't run any of MS's (or JetBrains) IDE's (or MS SQL) on a VM in Win10 ARM. Win10ARM VM does smoke though so hopefully they releases all that on ARM, that would another nice option.
I run and develop on the x64 versions of dotnet core 3.1 and dotnet 5 on my M1 Macbook Air every day and don't have problems. It runs via Rosetta 2 translation, and probably isn't as fast or memory efficient as it could be, but I don't have major issues and it runs a lot faster and keeps my mac cooler than if I try to run in Windows on ARM in Parallels.
I use VS for Mac 2019 (x64) and VS Code (arm64) for development work on a near daily basis.
That said, I tried installing the arm64 dotnet 6 preview and it broke the x64 versions I had installed and although I could debug/attach in VS Code, I could not get it to debug in VS for Mac 2019.
From what I understand, the issue is that the dotnet binary for x64 got replaced with the arm64 one. There is only one on the system at a time and the arm64 version doesn't know how to work with the x64 architecture sdks/runtime. There is some discussion and links to related issues in this GH issue: https://github.com/dotnet/sdk/issues/16896
Regarding SQL, I use the Docker Azure SQL Edge arm64 image and it works okay for most thing but doesn't support some of the more advanced features like full text search or spatial types.
For Database Projects (dacpac), Azure Data Studio with the Database Projects extension works okay for basic editing and deployment. However, it's not nearly as complete or refined as the database project edit/deploy experience in the Windows version of VS 2019. As far as I can tell it doesn't create new refactorlog entries for renamed objects and I can't figure out how to create a new deployment profile so I have to select the database connection every time I deploy.
I have been running the x64 build of dotnet 6 preview 4 and now preview 5 for a while and have not many issues. One thing that happened is that it broke the dacpac deploy in Azure Data Studio but there was a relatively simple workaround -- added a configuration setting in Azure Data Studio to override the dotnet SDK path to point to a folder where I had put dotnet 5.
I moved from C# to Java project. I preferred C# Syntax but amazed by the number of Java libraries. However I've found Java world full of neck-beard developers that make everything complicated. Spring is toxic - the learning curve is steep and half the devs dont understand it well enough which leaves a huge mess.
Dotnet Developers seem much more pragmatic. I wish I could go back.
EDIT - I forgot about how bad Java GC is. Still with Java 16 a ParallelOldGC Full GC is taking 30 seconds on a big server.
Toxic? Isn't this word too strong maybe? Spring provides consistent patterns and solutions for many things and their solutions is usually good (vary between mediocre to great). Learning curve is steep-ish when you start but quite a smooth ride later. It's maintained, reliable, not buggy.
Spring is an acquired taste, and many people don't like it because they don't know the right patterns, so I agree with you and think the parent is exaggerating.
I don't code very much Java or C#. I've tried to get into Spring because I wanted to save time but it was too complicated for my patience. I also evaluated ASP.NET and it seemed significantly more convoluted.
There is a ton of documentation for both Spring and ASP.NET but both are so complicated and specific to investing in exact ways of modelling users/auth/whatnot that they are both super hard to get into as a hobbiest outsider.
I like both languages and they both have good microservice libraries and general ecosystem. I just don't think it's worth saying Spring is complex without talking about ASP.NET.
>evaluated ASP.NET and it seemed significantly more convoluted
Which one? I would be very surprised if it were asp.net core, which is their current offering. It is one of the most straightforward and clean web frameworks I've ever had to work with. Spring seems to me to be a giant bowl of spaghetti in comparison to it.
You may also be interested in taking a look at [quarkus](quarkus.io) in that case. It's a relatively new platform developed by RedHat that focuses on cloud usability, performance and developer joy, while using well-established APIs like JAX-RS, JPA or microprofile
Asp.net is very well documented. I agree that authentication is a mess and the framework slightly over-engineered, but it's still very doable to use as a hobbyist.
Java GC bad? It is the state of the art (though it has multiple ones, but G1 and ZGC are the best for different workloads), no other runtime has a better one, with V8 coming somewhat close.
What's wrong with hair growing on your neck if it grows there? It's completely natural.
I know that this is slang/shorthand, but I don't agree with it at all. I work with plenty of people who have unruly beards and none of them fit the "neck-beard" stereotype.
I don't think it's a very nice term to be perpetuating. Judging people purely based on one physical attribute and then mocking them for it is not a great look for anyone.
The difficulty for me as a FT .Net Dev is the pace of development is hurting quality. There are many edge cases and bugs that get introduced as things change from nuget to dotnet pack, from netstandard to netcore, from net core 3.1 to net 5.
Each time, something is breaking which is more often than not "won't fix, just use .net 5". Net 5 isn't even finished and they are already previewing 6?
It is usually something like under .net 3.1, the build was fine and then under .net 5, an error happens, "oh yeah, you can workaround that by modifying your project file". Or you try and build in a .net 5 nuget package which means you can also reference an older netstandard 2 package that the developer has decided doesn't need updating because it hasn't changed.
This exactly! The branding and versioning of .NET is a complete disaster. There's .NET Framework (where even simply getting the current runtime version requires several convoluted hoops, since System.Environment.Version has gone the way of browser user agents and frozen itself at "4.0.30319").
Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework).
Then there is .NET Core which reset the versioning scheme again?
Then there is .NET 5 which is newer than all of these, but is it actually fully supported on non-windows platforms?
Then you need Newtonsoft.JSON, and then you get to watch your entire project blow up because you have three different dependencies that use different versions of netstandard/netcore/netframework and the assemblies aren't compatible.
I really hope going forward there will be just one unified .NET 6 that works the same on all platforms and doesn't need a million different builds of the same nuget package.
Edit: And even after all this, deploying your app by just copying the .exe and .dlls to a pristine machine often fails, because the corresponding .NET framework runtime isn't installed. And then you need to be a lawyer to figure out if you can even ship the net framework installer to your customer or how to handle that. You would think Microsoft would have a better story to sell to developers as what should be "the way" to develop and distribute windows executables. It seems like the only way to really be portable is to use an ancient version of Visual C to write win32 directly, and link the corresponding msvcrt statically.
Yes .NET 5 is supported on all platforms. It is the future of .NET Core. They dropped core because they wanted to make it clear it is the one true dotnet going forward. It actually will greatly simplify things going forward. .NET standard will no longer be necessary because there is only .NET 5 onward.
You don't "need" Newtonsoft.JSON. .NET now has a built in serializer which is much faster. But for compatability and some more advanced scenarios some people still need/prefer it.
Lastly .NET core apps (and .NET 5/6 going forward) have an option to produce a single file deployment. This includes the framework so you do not have to have it pre-installed on the target.
> Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework).
You seem to think that .NET Standard is a framework. It is a specification, like the C++ STL. Think of it as "the .NET Standard".
I agree, though I wouldn't say it's the pace of development so much as the change in approach.
.NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating.
In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink.
It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical.
Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code.
The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.
> Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating.
I'm happy to hear I'm not the only one with this problem. For me, removing assemblies from csproj ended up being the solution to many of these problems (let them load implicitly).
I don't have any .NET background or anything even particularly MS specific. However, I spent most of 2020 just playing tourist between different development / devops communities to get a feel for what are the main ideas, challenges, core truths etc in each.
I looked into Java, Ruby, C#, Dart, Kubernetes, Bazel, TypeScript, Flutter, Node, lots of CNCF stuff etc.
I have a bunch of interesting observations that I should probably write down somewhere at some point because I haven't seen people talk about them much yet.
However, one thing that kept coming up repeatedly is Microsoft is actually doing a much better job of thinking "beyond Windows" than I would have anticipated otherwise.
.NET is making its way into front end web apps now with Blazor, Microsoft has also just recently released something that they 100% do not market this way but I look at as almost a successor to .NET in some ways. The big difference is that it's language agnostic and it's entirely built around the concept of "distributed" applications. That came out of the Azure team I think and was based on everything they had learned about writing distributed / cloud native apps in the last 5-10 years. The project is called Dapr and was one of the cooler things I saw in 2020.
Given their history of abandoning front-end frameworks, I wouldn't put too much faith into Blazor.
And the Azure team is, frankly, grossly incompetent. I've never used a worse application than the Azure dashboards. It is by far the absolute worst piece of software I have ever had to endure. Pathetically slow, shockingly bad UX and incredibly inconsistent.
I'm going to ignore the "Shit HN says" vibes on this one for the most part, but I suspect that Microsoft and the Azure team specifically might have some relevant thoughts about building distributed systems regardless of if you like their dashboards or not.
As for Blazor, I think you might be missing the larger point here that I am trying to make. But .NET is still this Windows thing in the minds of most people. That hasn't officially been true for a couple of years now but the .NET crowd are coming to things like Linux and Front End now for the first time.
There are about to be a lot more conversations between say the React crowd and the Enterprise app development crowd, I am actually excited to see what they can all learn from one another.
I think I might agree that the Azure portal is slow, has bad UX and is somewhat inconsistent but I very much suspect that with the pace of change in cloud systems, it is very likely to be driven by some database so that it is easy to create new config pages for each new product without having to write an entire new web app.
It is a web app though and I wouldn't see that AWS is necessarily ahead. The IAM setup is still very head scratching, although some things like SES setup with DNS are very easy.
Like someone else said, not really related to .Net
What did they abandon? Silverlight? That went the same way as Flash because plugins were killed by browsers and mobile. Blazor is much different and a core part of the web stack. Considering you can still run WebForms apps written in C# 2.0 today, support and backwards compatibility is actually a strength of this ecosystem.
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
I'm a long time dotnet guy, but I've been working with Swift/XCode recently.
There are definitely some things I like (completions in particular), but man do I miss the dotnet world.
I recently had an issue where I was using a third party closed source library in Swift. A particular function I was calling was sometimes bombing out, and because it wasn't marked as a throwable function, I couldn't put a do/catch around it. As a result, when it did, my app would just crash and there was nothing I could do about it.
I even asked on StackOverflow and was just told that this function can't be erroring out, even though it was lol
I've worked with other languages/frameworks as well over time and nothing is as nice to work with as dotnet.
If it has been a few years since you looked at C# or F#, it may be worth a look again now. Lots and lots of optimizations have been added in the last 5 years, and you can even use SIMD intrinsics directly now. By some measures C# is now the best overall performing garbage collected language (Such as The Benchmark Game)
One of the biggest things was the addition of Span<T> and Memory<T>, and their usage in underlying types within the .Net framework. While C# always had the ability to use raw pointers, these two types allow you similar performance characteristics without unsafe blocks (and frankly are near idiot-proof instead of being a giant foot-gun with pointers to managed types).
Add in the massive standard library, project types, and overall productivity and it's the best platform available now.
I'm working in production projects across all 3 languages now and Java and Go are way behind when it comes to producing a polished product as quickly as possible.
I programmed professionally in .NET around 2003 with the initial versions. I liked it a lot and over the next years I tried to keep up to date about it on my spare time (I remember reading about LINQ development, the amazing CLR improvements, etc), all while I developed in Java, ruby and nowadays TypeScript.
The problem I see with .NET now (I did some tinkering on it via Unity) is that even though some of it is "open source", Micorsoft's grip is still pretty tight on it. Or at least it feels like that.
Given Microsoft's history I find it very difficult to "commit" to using the .NET framework for something real, because I feel I will be bitten back with the 'proprietary' aspects of it as soon as I go to production. It's a sunk cost that I cannot afford.
And it is not personal 'hatred' or anything given that I use VSCode as an editor and TypeScript itself comes from Microsoft.
I wish Microsoft would donate .NET to some 3rd party open source foundation (like what happens with all Apache projects, or LibreOffice, the MariaDB foundation, etc).
Modern .NET is legally owned by the .NET Foundation. It is MIT/Apache licensed with the exception of some debuggers in VS Code (which propably conflict with VS itself).
Granted, the .NET Foundation is not the Apache, Eclipse, Linux or CNCF Foundation and it is dominantly financed by Microsoft, but there are relative important peers like AWS or RedHat involved.
There is ongoing work[1] on porting it also on BSD systems. I hope it will help to make it even more portable in the long run. See also other FreeBSD issues[2] that need to be solved for complete support. Or the same for NetBSD[3].
Readit News
I'll admit it takes some time to get started, but it's smooth sailing once you get past the initial hurdles of setting up your project, understanding some idiosyncrasies when it comes to ASP.NET/Web API/Entity Framework if you're going that route for your backend and such. And now with Blazor, I can even work on the frontend and touch Javascript as little as possible.
So if you're an MS dev whose looking for some additional reach into other platforms, the increased interoperability is great. However for those of us not working on MS platforms, .NET has a huge uphill battle competing with every other platform available to us.
.NET is not tailored to something specific Microsofty. However, the .NET community is still challenged when taking 3rd party dependencies (which is the actual limitation) and then complaints when Microsoft is not delivering the perfect kitchen sink.
C# has been pretty groundbreaking, adding features like async await and generators before other mainstream languages.
They are also pushing forward ASP.NET pretty aggressively, even having first class support for gRPC and other popular technologies.
I want to like what I'm seeing in .net, but there just doesnt seem anything compelling when compared to say Graalvm or even nodejs.
The VM market is very very crowded with fantastic offerings these days, many of which share many commonalities easing dev while each is tailored for a slightly different market.
in the case of .net - xbox.
.Net is not even close to being driven by Microsoft’s internal needs, for the simple reason that their biggest internal products don’t use .Net.
.Net is far closer to Sun with Java or Kotlin with Jetbrains than Apple with Swift.
Biggest hurdle for me (as a UNIX greybeard, Java survivor and occasional LISPer) is ramping up on idiosyncratic C# syntax and various generations of .NET libraries
But what little I've done in the past couple of months (with .NET 5) works OK in Linux, and the tooling (VS Code + Remote to have .NET on a remote VM at a safe distance from my Mac) suitably lightweight and hassle-free.
(full disclosure: I actually work at Microsoft these days but never developed for Windows alone - did mostly C++ and Java when I targeted it - and never did .NET before, as it only makes sense for me to use it now that I can target Linux)
Some people/companies also care about more than the big three operating systems that MS cares to acknowledge. .NET has no official FreeBSD port, for example.
Tooling for. Net is miles ahead of anything else I've witnessed.
As for FreeBSD there's a huge nuance:
> FreeBSD support still requires additional work to implement features that are missing in the runtime to reach parity with the other operating systems. The community will most likely need to do that work in .Net 3.0/3.1 but I would like to see official automated daily builds for FreeBSD restarted with the master (.Net 5) branches of the necessary repos.
As for your statement on Microsoft. I'd trust Microsoft with. Net more than Oracle with Java.
What other languages stacks provide a much better tooling experience? If you use IntelliJ then you get the same thing with Rider (which is just IntelliJ + Resharper), and the rest are all basically VSCode at this point.
Rider is better than Visual Studio at the moment; we'll see what happens if they actually get VS 2022 cut over to be 64-bit, maybe the performance will be back to usable for medium-large solutions.
Rider is my daily driver - no matter what OS I use (primarily Windows/Mac and occasionally Ubuntu.)
java pendant c# was always much more performance focused than java, having structs, unmanaged c# and c++ interoperability. it took java 16 years or so to accept that structs have their justification.
i also find the c# language much nicer than java. f# versus clojure are both excellent additions and again, f# is the more static and performant while clojure has very nice and inspiring features and aspects. it depends on what one wants here.
finally i think even if java is the larger universe, the .net universe certainly is not small either. if .net would not have taken the cross platform road i would have switched to the java runtime, but happily the opposite happened.
Deleted Comment
Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?
With Java the issues came from elsewhere- it was less so the interoperability and more just how messy the whole ecosystem is and how there are some aspects of the language itself (such as the excessive verbosity and the way the standard library is structured) that kept mounting up as little annoyances over time. Kotlin wasn't really an option at the time, either.
F# is really nice, and I enjoy using it for web related things, but I have to reach for different languages if I'm looking to build a GUI right now.
You can even get a single static binary release that will work on platforms without .NET libraries.
Check out the Makefile and project file in this repo if you'd like an example: https://github.com/eatonphil/dbcore/blob/master/dbcore.fspro....
But yeah, it's a great time for sure, just good to keep that in mind since you also can't run any of MS's (or JetBrains) IDE's (or MS SQL) on a VM in Win10 ARM. Win10ARM VM does smoke though so hopefully they releases all that on ARM, that would another nice option.
I use VS for Mac 2019 (x64) and VS Code (arm64) for development work on a near daily basis.
That said, I tried installing the arm64 dotnet 6 preview and it broke the x64 versions I had installed and although I could debug/attach in VS Code, I could not get it to debug in VS for Mac 2019.
From what I understand, the issue is that the dotnet binary for x64 got replaced with the arm64 one. There is only one on the system at a time and the arm64 version doesn't know how to work with the x64 architecture sdks/runtime. There is some discussion and links to related issues in this GH issue: https://github.com/dotnet/sdk/issues/16896
Regarding SQL, I use the Docker Azure SQL Edge arm64 image and it works okay for most thing but doesn't support some of the more advanced features like full text search or spatial types.
For Database Projects (dacpac), Azure Data Studio with the Database Projects extension works okay for basic editing and deployment. However, it's not nearly as complete or refined as the database project edit/deploy experience in the Windows version of VS 2019. As far as I can tell it doesn't create new refactorlog entries for renamed objects and I can't figure out how to create a new deployment profile so I have to select the database connection every time I deploy.
I have been running the x64 build of dotnet 6 preview 4 and now preview 5 for a while and have not many issues. One thing that happened is that it broke the dacpac deploy in Azure Data Studio but there was a relatively simple workaround -- added a configuration setting in Azure Data Studio to override the dotnet SDK path to point to a folder where I had put dotnet 5.
https://rider-support.jetbrains.com/hc/en-us/articles/440192...
Dotnet Developers seem much more pragmatic. I wish I could go back.
EDIT - I forgot about how bad Java GC is. Still with Java 16 a ParallelOldGC Full GC is taking 30 seconds on a big server.
There is a ton of documentation for both Spring and ASP.NET but both are so complicated and specific to investing in exact ways of modelling users/auth/whatnot that they are both super hard to get into as a hobbiest outsider.
I like both languages and they both have good microservice libraries and general ecosystem. I just don't think it's worth saying Spring is complex without talking about ASP.NET.
Which one? I would be very surprised if it were asp.net core, which is their current offering. It is one of the most straightforward and clean web frameworks I've ever had to work with. Spring seems to me to be a giant bowl of spaghetti in comparison to it.
What's wrong with hair growing on your neck if it grows there? It's completely natural.
I know that this is slang/shorthand, but I don't agree with it at all. I work with plenty of people who have unruly beards and none of them fit the "neck-beard" stereotype.
I don't think it's a very nice term to be perpetuating. Judging people purely based on one physical attribute and then mocking them for it is not a great look for anyone.
I was surprised and found it super easy to architect, build and maintain with lots of nice patterns.
It's yaybe heavy, but I wouldn't say it's toxic.
https://malloc.se/blog/zgc-jdk16
Each time, something is breaking which is more often than not "won't fix, just use .net 5". Net 5 isn't even finished and they are already previewing 6?
It is usually something like under .net 3.1, the build was fine and then under .net 5, an error happens, "oh yeah, you can workaround that by modifying your project file". Or you try and build in a .net 5 nuget package which means you can also reference an older netstandard 2 package that the developer has decided doesn't need updating because it hasn't changed.
Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework).
Then there is .NET Core which reset the versioning scheme again?
Then there is .NET 5 which is newer than all of these, but is it actually fully supported on non-windows platforms?
Then you need Newtonsoft.JSON, and then you get to watch your entire project blow up because you have three different dependencies that use different versions of netstandard/netcore/netframework and the assemblies aren't compatible.
I really hope going forward there will be just one unified .NET 6 that works the same on all platforms and doesn't need a million different builds of the same nuget package.
Edit: And even after all this, deploying your app by just copying the .exe and .dlls to a pristine machine often fails, because the corresponding .NET framework runtime isn't installed. And then you need to be a lawyer to figure out if you can even ship the net framework installer to your customer or how to handle that. You would think Microsoft would have a better story to sell to developers as what should be "the way" to develop and distribute windows executables. It seems like the only way to really be portable is to use an ancient version of Visual C to write win32 directly, and link the corresponding msvcrt statically.
You don't "need" Newtonsoft.JSON. .NET now has a built in serializer which is much faster. But for compatability and some more advanced scenarios some people still need/prefer it.
Lastly .NET core apps (and .NET 5/6 going forward) have an option to produce a single file deployment. This includes the framework so you do not have to have it pre-installed on the target.
You seem to think that .NET Standard is a framework. It is a specification, like the C++ STL. Think of it as "the .NET Standard".
.NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating.
In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink.
It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical.
Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code.
The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.
I'm happy to hear I'm not the only one with this problem. For me, removing assemblies from csproj ended up being the solution to many of these problems (let them load implicitly).
net5 was never an LTS release, so they are moving as fast as they can to net6. I do believe 6 will be much more stable.
I looked into Java, Ruby, C#, Dart, Kubernetes, Bazel, TypeScript, Flutter, Node, lots of CNCF stuff etc.
I have a bunch of interesting observations that I should probably write down somewhere at some point because I haven't seen people talk about them much yet.
However, one thing that kept coming up repeatedly is Microsoft is actually doing a much better job of thinking "beyond Windows" than I would have anticipated otherwise.
.NET is making its way into front end web apps now with Blazor, Microsoft has also just recently released something that they 100% do not market this way but I look at as almost a successor to .NET in some ways. The big difference is that it's language agnostic and it's entirely built around the concept of "distributed" applications. That came out of the Azure team I think and was based on everything they had learned about writing distributed / cloud native apps in the last 5-10 years. The project is called Dapr and was one of the cooler things I saw in 2020.
And the Azure team is, frankly, grossly incompetent. I've never used a worse application than the Azure dashboards. It is by far the absolute worst piece of software I have ever had to endure. Pathetically slow, shockingly bad UX and incredibly inconsistent.
As for Blazor, I think you might be missing the larger point here that I am trying to make. But .NET is still this Windows thing in the minds of most people. That hasn't officially been true for a couple of years now but the .NET crowd are coming to things like Linux and Front End now for the first time.
There are about to be a lot more conversations between say the React crowd and the Enterprise app development crowd, I am actually excited to see what they can all learn from one another.
It is a web app though and I wouldn't see that AWS is necessarily ahead. The IAM setup is still very head scratching, although some things like SES setup with DNS are very easy.
Like someone else said, not really related to .Net
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
There are definitely some things I like (completions in particular), but man do I miss the dotnet world.
I recently had an issue where I was using a third party closed source library in Swift. A particular function I was calling was sometimes bombing out, and because it wasn't marked as a throwable function, I couldn't put a do/catch around it. As a result, when it did, my app would just crash and there was nothing I could do about it.
I even asked on StackOverflow and was just told that this function can't be erroring out, even though it was lol
I've worked with other languages/frameworks as well over time and nothing is as nice to work with as dotnet.
https://docs.microsoft.com/en-us/dotnet/standard/memory-and-...
By some other measure it's not, out the three fastest: Java/C#/Go they're all pretty much as fast.
I'm working in production projects across all 3 languages now and Java and Go are way behind when it comes to producing a polished product as quickly as possible.
The problem I see with .NET now (I did some tinkering on it via Unity) is that even though some of it is "open source", Micorsoft's grip is still pretty tight on it. Or at least it feels like that.
Given Microsoft's history I find it very difficult to "commit" to using the .NET framework for something real, because I feel I will be bitten back with the 'proprietary' aspects of it as soon as I go to production. It's a sunk cost that I cannot afford.
And it is not personal 'hatred' or anything given that I use VSCode as an editor and TypeScript itself comes from Microsoft.
I wish Microsoft would donate .NET to some 3rd party open source foundation (like what happens with all Apache projects, or LibreOffice, the MariaDB foundation, etc).
Granted, the .NET Foundation is not the Apache, Eclipse, Linux or CNCF Foundation and it is dominantly financed by Microsoft, but there are relative important peers like AWS or RedHat involved.
[1] https://github.com/dotnet/runtime/issues/14537
[2] https://github.com/dotnet/runtime/labels/os-freebsd
[3] https://github.com/dotnet/runtime/labels/os-netbsd