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.
It's not an IDE issue; .Net 5.0 doesn't fully run on M1, aka you can't connect to the debugger and step into the code, among other things. VS Code is native on M1, and Visual Studio for Mac also runs via Rosetta2 (but I don't run it).
Did not know that about Rider, thx I'll def check it out.
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.
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.
Eh, I've been a .net developer for almost 15 years.
The parent post is correct that the third-party ecosystem (especially OSS) is sorely lacking in quality.
Like look at logging - logging in .net is SO anemic. Even with third-party libs, there are so many features missing that have been in java libs like slf and log4j2 for years, yet we have nothing close in .NET.
Hell, you could just pick a feature from spring and compare to what's available in .NET ecosystem, and you'll be sorely disappointed.
Quantity of libraries is a poor metric. Like I said, the standard library in .NET covers a lot, and lets you make everything from CLIs to enterprise web apps. And when you do need 3rd-party code, there are plenty of commercial and OSS options to solve your problem.
Many of the .net libraries are poor afterthoughts of an existing Java library.
Java simply has developer mindshare, the .Net developer stereotype is so rigid and engrossed that the pay difference between a .Net dev and their Java peer is usually around 20% if not more.
your average .net dev gets paid less than your average COBOL dev too, but I wouldn't say that informs us of much other than scarcity of expertise.
We used to say, "you can through a rock into a crowd and find somebody who can at least be productive on .net". Finding a stone cold expert on .Net is far more difficult, but for the average enterprise doing internal development weighing whether to adopt one platform or another, resource availability/scarcity matters.
The comparison was to illustrate that scarcity of expertise absolutely affects pay rate, notwithstanding other explanations.
Whether that explains part or most or all of Java dev pay premium is at least debatable. For instance, I would never make the same "throw a rock into a crowd" statement about finding a competent (but not expert) java developer. That alone means I would expect to pay some of a premium for finding them in that crowd.
What's the counter argument to scarcity? Alignment with better paying industries, weighted so heavily in that direction that it shows up as a premium for their developers? I mean, if you start getting into the conversations about the obscurity of domains, or supplemental education associated with Java developers either by coincidence or requirement, or general demand, I think you're still commenting about scarcity.
The confusion here is perhaps that I jumped from B to F. The number of successful Opensource projects in Javaworld are astounding, and the OSS/Library work in .net is there but in comparison is miniscule. That feeds into the stereotype of .net developers being cookie-cutter VB-eseque Enterprise developers, which even feeds into their pay.
JavaWorld is bigger and Java developer count exceeds .net developer count, so the whole scarcity thing is a static explanation of a much complex dynamic environment. The intent here is not to complain about .net dev wages.
It's not just quantity. Java benefits from all the major players that are using it. Quality of libraries is head and shoulders above anything you can find in .NET world.
I don't think so anymore. It used to be that way but .NET has massively changed in the last few years. Also many of the Java libraries are unnecessary in the .NET because of its strong standard library and core frameworks. There's no need for 20 different JSON serializers or webservers. In contrast, there's nothing even close to Blazor for Java.
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.
Rider is no joke. If you haven't used it or gave up on it a few years back, give it a shot. There are a few things it can't do like attach to managed modules hosted in unmanaged processes but it's a joy to code in.
I've never heard of it but I'll keep it on my radar. I love the idea of having a universal GUI using C#. I haven't done much android development, but I only know that it would be a tad less tedious if I didn't have to deal with android studio.
Not official, but I have had good experiences with AvaloniaUI, which sticks very close to WPF and is part of the .NET foundation umbrella. It inherits quite a lot of what made WPF mature and robust
This was my question - anything like even windows Forms (which was a super easy way to get little apps together). Microsoft went crazy with their GUI approaches for a while - just straight insanity for little purpose that I could see.
Fantastic - I could never get the designer working right but after all the whiplash of microsofts UI approaches I've moved away so have no current experience. Good to hear its supported.
I find "whiplash" comments interesting. Microsoft has been relatively consistent since Vista, everything post-Vista XAML based. Some of the runtimes (which .NET versions are supported, what if any other languages are supported) and brands have shifted every five years or so, but there are lines of consistency from start to finish, and upgrade paths at nearly every stage, and XAML is generally XAML throughout. Things have generally been well supported for good maintenance lifetimes at each stage. (With the shortest probably being Silverlight, and its extended security support hasn't even expired yet, even if no one should have built new apps against it in at least five or six years now and no modern browser has supported running them.)
Compared to Win32 not changing much since roughly 1995 or so, it's wild and constantly shifting, but compared to say JS frontend frameworks it's more stable than a lot of things people are doing in UI.
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.
You're both right. I agree Spring Boot is great if you know it well and are knocking out micro-services. If you have a ball of mud like my current project with mixes of XML config, Attribute config and people rolling their own stuff it really isn't adding any value.
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.
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
Oh yes I've found a number of good microservices for both languages. I'm just astounded by how complex Spring and ASP. Net are. Though to be fair I also find Rails too complex.
I guess the problem is that I've just never had to use on of these at work.
So when programming in my free time in both Java and .NET it's way easier/more fun to just use microservice libraries that are easier to pick up.
Rails and Spring Boot both scratch a similar itch. Out of the gate, a brand new project spins up and can return output (JSON or HTML) with almost zero config. The developer is responsible for augmenting that project with controllers/services/models/etc. What this leads to are dark corners. This is fine as not every developer needs to understand all of those dark corners. But it also leads to blind dependence on the framework and its libraries. And when something goes wrong, they can go REALLY wrong. That said, Spring implements some great patterns out of the box. And spinning up a highly performant microservice with JWT auth, security, an okay ORM (I don't hate Hibernate like a lot of folks do) is cake!
>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.
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.
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.
For what it is worth, it isn't a neologism to this thread it's a (insulting) slang term for certain types of pedantic nerds in relatively common usage on the internet going back to early internet history (some of the earliest recorded usages were in the early 2000s).
It's both hilarious and jarring for me to have found myself reading a comment about ear hair grooming and the next snaps back to a comment about swift, c#, and Rider. :D
> Hair in other places is considered equally distasteful...
...by some. Clearly others disagree.
Personally, I like hairy men and women. It's a clear sign that I won't have to deal with some priggish prude who is more concerned with looks than personality.
> Personally, I like hairy men and women. It's a clear sign that I won't have to deal with some priggish prude who is more concerned with looks than personality.
Ok, but don't be shocked if some of those priggish people avoid you and unfortunately for you, they may be the ones deciding to give you a loan, to go on a date with you, to offer you a job, whatever.
Everything in life comes with trade offs.
And sometimes it's not worth winning the battle to lose the war.
Yeah and the same goes the other way too. Don't be surprised if the heavily bearded middle eastern guy won't invest with men who they think look like women or who have made known their opinions about grooming. Don't be surprised if you don't get invited to parties or if the guy working on your car or skippering your boat screws you for being a stiff.
Everything does come with trade-offs. That's correct.
Being well-traveled is a cure for bigotry though. Realizing that you're in a bubble is the first step.
It is also signals a package of personality traits:
* rejecting other personal hygiene customs
* being noticeably more pedantic
* picking every battle/argument
* lower than normal respect for other's boundaries
* lower than normal awareness of how their actions effect others
* making "being rational" a core part of their identity
* dismissing human behaviors they don't do as irrational. usually these are the ones where rational explanations do exist, they are just difficult to re-invent on the spot.
This package is common enough to have earned itself a name, which happens to be the easiest visual indicator.
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.
Take a look at F#. It's a superior language and doesn't add new features like C# does (which is mainly stealing from F# anyway). Also, Elixir is a language that is very stable from release to release.
I’m seeing this at work right now. New devs asking which way to initialize an object, the difference between record, class, and struct, how to use nullable types, etc. I can’t help but feel C# is getting too complicated for its own good.
If you have 3 teams members speaking 3 different languages then it certainly impacts their communication.
If the language has 3-10 different ways of creating a class/object and every developer does it differently then it certainly impacts the productivity ;)
Yes and no. Some of the features are really welcome, some are ghetto (like the ref performance ones) and some indeed change the visual look of the language a lot (pattern matching). It's ok to keep up for someone already knowing the language but for a newcomer it's indeed super scary.
On the other side, it is never easier to learn C# than now. The amount of ceremony removed in C#, the university educated functional programming patterns, the universal availability on operating systems and the quick setup (including eg. notebooks) are just some things.
However, when I think back to my first line of code 30 years ago, i would also be scared of modern languages (however this applies to all actively maintained languages).
You should not pick up this stack for a startup or for any operation that involves less than three full-time backend developers. Iteration is so slow because all the bad OOPy practices and patterns from the 90s are still alive.
In just a month our intern made a web app using Django/Python and InfluxDb that would have taken us two months to implement.
It's sad because modern C# is an amazing multi-paradigm language. But the .Net ecosystem insists on partying like it's 1999.
Carter is probably a better choice than Nancy nowadays, but in any case the new minimal api features coming in 6 look to provide a really excellent way to build elegant web APIs without large framework overhead.
We kinda stopped developing Nancy when .NET core came out because MVC became more opt in rather than opt out, and was more performant. (Prior to .NET Core, Nancy could handle more RPS over .NET Framework mvc)
Master Jonathan Channon (and contributors) have done an awesome job with carter! It’s definitely an awesome alternative. And I think with the stuff David Fowler has been working on to make hello world easier it will help make carter better too.
You should definitely use this stack for a startup or any operation with less than three full-time developers.
I've literally done this at three enterprise scale startups with just three devs (including myself). Working on the 3rd startup right now. The productivity of .NET, Visual Studio, and Azure is amazing.
I’m going to be the voice of balance and say .Net and associated tooling is fine, but Azure should be avoided: never a more frustrating experience have I had.
I must admit I'm a little confused at this (but not downvoting), I think the speed of development is probably equivalent but with the benefit that as the codebase grows you at least have types to make scaling easier but having not tried Django I can't really give a fact-based view.
Without knowing what exactly was being implemented it's hard to assess. However I think any halfway decent .NET developer can probably stand up a low-medium complexity MVC app in a couple of weeks. Granted you could go full OO-brain and use all sorts of patterns, service layers, onion architecture etc. to bloat the code. But you don't have to, if it's a quick throwaway you could simply do data access directly in the controllers (even using EF to abstract away any SQL writing).
Can you expand some more on what exactly the bloat is that you feel slows .NET development down?
I've used .NET stack in my last 4 startups, and it's let me (alone or in a small team) compete with much bigger companies by building faster and more thorough projects.
A single django/influxdb project doesn't say much, and I bet you can find .NET devs who'll build that in a day.
The DI obsession in ASP.NET is a little weird, and I'm not a great fan of how magic it makes everything. You don't have to do things that way, but if you don't, you'll be fighting against the grain the whole time, because everything comes packaged as middlewares and components and services that you're supposed to just plug into that framework.
DI frustrates me every time I have to do it, or touch code that uses it. It’s all magic layers and unnecessary abstractions over the apparently heinous crime of “passing arguments down into functions” and setting it up feels like the programming equivalent of performing a sacred incantation.
I used this stack to replace a Django/Python app that was built over 2 years by another dev in 2 weeks. We regularly have 1 hour turn arounds between when an issue/feature is filed on Github and when a new build is live with that code. The self-contained deployments have made it simple to deploy this app, and now its supporting apps, to our linux-based cloud instances.
I've built on many stacks and although I agree that iteration speed is important; It has more to do with how you organize your project and the quality of your tooling than with the specific language/framework.
If you don't like the OOPy style, don't write in it. Pattern matching in C# is quite nice, and you can always mark you functions as static. As a bonus, simple functions are easier to test to.
Totally different experience here, been a dev for 20 years tried multiple things and .net is so so so much productive and straightforward it's the obvious first choice. Sold my last project (1 man) to a company now worth 500M+, running strong on .net+EF in pgsql without issues.
I completely disagree. In fact, my friend and I used .NET our last Startup Weekend event and were the only team to build a complete product against teams using Python/Ruby/NodeJs. You can in fact write C#/ASP.NET in a rapid hacked together way similar to Python if you want.
In our startup products, we've built entire production sites with data stores, front-ends, payment systems, and the core product, in a few weeks.
I think it greatly depends on the skill level of the developer. In the end, "startup dev" is mostly tying together a dozen libraries, a datastore, and whatever your secret sauce product might be.
The only problem with .NET is that the best tooling is quite expensive. Visual Studio with ReSharper or JetBrains Rider are both up there in price and MonoDevelop didn't work with .net core last I tried (2 years ago). That kind of leaves you with VSCode or a plain old editor (vim/emacs), but you really don't want to write C# code in a basic editor.
It really depends on your 'license' with them. For me as an individual it is basically 'free'. As the community edition is basically pro in all but name. But for a corp env it is like you say it is not 'trivial expensive'. They mowed down everyone else because it was that choice for a long time. You were talking 20-30k per year per dev in the 90s for some stacks. 150-500 per year was a bargain by that metric. But now there are 5 other IDEs you can pick from that are either cheaper or free. In some cases for some langs the cheaper ones are better in all respects. In some cases they are charging anywhere from 500-9k per year depending on how you buy it. Why would I start a greenfield project with VS in that sort of env, unless I was already a 'MS shop'?
VS is nice, and one of the better IDEs but by comparison it is wildly overpriced.
Yes, after looking up average salaries and doing a quick currency conversion, USD 500 is around 60% of a whole month's salary for an average software developer.
The median salary of a software developer in Mexico for 2020 was of $1750 USD gross, so after Taxes is around $1400. $500 USD a year is crazy expensive.
Interesting. I've been in and out of the .NET world over the last 15 years, and I've used Visual Studio. If my employer sprang for MSDN, I'd use Professional, but for most projects, Community worked great. I did have access to ReSharper at one point, but I didn't end up using most of the features. I've found in my own workflow, you don't need any of those things, though I'm sure some people rely on them for some personal efficiencies.
At any rate, I've never found even the free Visual Studio Community to feel like a "basic editor."
Visual Studio Community or even VSCode with Omnisharp is a very solid choice. You can easily write C# code of any complexity without any extra bells and whistles of Rider because the language itself is that good.
Free for some in some cases, depending on the number of users in your organization, the number of computers and some other things. They got rid of the actually free but less complete version (Express).
What about 1 developer and >250 computers in a different part of the organization? The VS Community license doesn't permit this case. The discontinued VS Express did.
> Yeah, >250 developers or >1mill revenue and _not_ being willing to pay for developer tools would be an enormous red flag :)
The cutoff for Community is >5 VS Community users (not developers, either, as VS is also intended for testers, etc.), not 250, or >250 PCs in the org (not “developers” or “using VS Community”, just PCs existing in the org.)
Visual Studio Community has been free for years and lets you build anything. VS Pro and Enterprise are for bigger teams/projects with some advanced features but nothing you absolutely need.
Also what's the problem with VS Code? It's great for C#, and basically the mainstream choice for many other stacks like Go and Node already.
> Visual Studio Community has been free for years and lets you build anything.
As long as you have a small number of total VSC users (not just on a team/project, but in an org; ≤5), and are in a small, luddite, or mostly-tablets org (≤250 PCs), and don’t have much money coming through (≤$1 million revenue.)
Otherwise, its only usable for open source work, academic research, and classroom training.
At a quick googling, the basic VS Pro subscription costs $45/mo. That doesn't seem unreasonable to ask, even from a small company with $1M annual revenue.
So? The claim I was addressing was about what VS Code Community allows for free, not about the reasonability of the price of the more functionally limited, but less restrictively licensed, VS Code Pro.
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.
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.
Everything. There isn't a single first-party desktop GUI framework left that is actively supported and developed. UWP is of course still available but modern apps have failed.
You can still use WPF and WinForms, but they have serious limitations and feel old. WPF for example makes G-SYNC switch to 60 Hz.
WinUI 3 includes all of what used to the the UWP controls and Renderer but "lifted and shifted" out of OS updates and also made accessible to non-UWP (primarily Win32) applications in Project Reunion (and techniques such as "XAML Islands").
Well, yes and no. We can certainly agree that neither WPF nor WinForms are dead. How could they be? There’s simply no alternative. However, they sure aren’t alive either. Development has been stalled for many years and both are very old.
I’m pretty sure it’s no longer feasible to modernize even WPF. I just checked: It still has its G-SYNC issues, even on .NET 5.
Totally forgot about Xamarin too because it’s so irrelevant. But maybe MAUI will change that, who knows. I’ll believe it when I see it I guess.
What is the alternative then? How would you have created a new Windows desktop application in 2015? 2018?
And yes, since 2012 there were no major changes to WPF. And even these changes were small. The last truly major change came with .NET 4.0. So there was a decade of almost nothing, even while XAML evolved with UWP. It truly doesn't get any more dead than that.
Of course I'm salty. WPF promised a lot, delivered some then died. Xamarin wasn't even part of Microsoft back then. UWP is a joke. Microsoft neglected the "Win32" desktop for way too long. Now it lets the community do what it should've done ages ago.
> How would you have created a new Windows desktop application in 2015? 2018?
Xamarin worked in 2016, as did UWP itself. Failing those Win32. Funny that you're arbitrarily throwing in a year, given that your OP didn't mention it, but whatever. If anything you can criticize MS for making too many UI frameworks lol.
You keep calling things that are literally still supported "dead". How about you use terms with real meaning, instead of just saying things that are literally untrue...
> It truly doesn't get any more dead than that.
> Of course I'm salty. WPF promised a lot, delivered some then died.
> We can certainly agree that neither WPF nor WinForms are dead.
Okay I'm done here. I wish you the best with your salt.
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'd agree with them that the portal is terrible. Multiple times a day I get blank page errors, where the page is completely blank except for a single non-sensical error message in black text.
However their actual services are also pretty terrible. Pretty much everything takes significantly longer to deploy than the AWS couterpart. There are so many preview and deprecated features that it is often hard to judge exactly what feature set you are getting, this is often compounded by the fact that almost everything has multiple SKUs which also change available features. Azure AD RBAC is a bit of a mess, although its conceptually simpler than AWS IAM policies its just a pain to use in practice, and its often slow for changes in permissions to actually reflect. Azure VM disks are annoying to use too, you can't set the size of the OS drive at creation and extra data disks come unformatted. "Grossly incompetent" is probably an overstep though, Azure is very impressive, just not as impressive as its competitors right now.
Having said all that their are a couple places where Azure really shines in my opinion:
* Resource groups (GCP has a similar feature) allow you to more easily keep track of related resources across services.
* Price transparency. Many (not all) services tell you up front hourly/monthly costs as you are deploying them through the portal. You don't have to track down a pricing page or calculator yourself.
* Azure functions are amazing when using C#/.Net. A huge amount of the regular boilerplate is abstracted away into simple C# annotations so you can get a large % of business logic.
Hi, can you guys look at the portal security? In some corporate accounts most people have limited access to do stuff, but it is all enabled; you spend a few minutes to create a new resource just to get an access error after you submit, when it should be disabled (displayed, but disabled) if you cannot do it, do the access check before not after. There are so many options we never know which one is enabled and which one is not.
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
Dashboard takes 12s
An app service takes 40s
The deployment centre takes 22s
Opening a single deployment log takes 4.5s
Opening process explorer takes 30s
Opening kudu took 12s
And this is on a saturday morning, obviously during the week it's much worse.
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.
I wonder when whey will make the debugger work with non-proprietary versions of VS Code.
I am not joking, I wish I was. The official C# debugger is not only proprietary, it’s also not licensed for VS Code versions compiled from source.
The rest looks cool, hopes are high for MAUI. But really man, forcing me to jump through a bunch of hoops just to get a (somewhat) working debugger ... That kind of a move is a remnant of the old Microsoft that absolutely needs to die for the new Microsoft to live on.
Not gp, but think about it that way: what makes necessary for VSCode to have a proprietary version and key plugins?
In addition, I'm not even sure if the telemetry on VS Code can be turned off. I think "yes", but never bothered checking while VS Codium was available.
As far as I know they have (somewhat, they do use MSBuild) completely developed their own .NET tooling ecosystem (ReSharper being the most prominent example).
And it shows that they actually know what they’re doing. I don’t know what it is with Microsoft in particular, but they have really mastered the art of building user hostile applications. God, Visual Studio is a mess. I envy you.
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.
There isn't really a "default" GUI library at this point. WinForms and WPF are both rather equal in support. (Arguably WPF gets far more updates than WinForms, most months.)
MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.
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.
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.
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.
When it comes to what it is tailored: there are two VM models: CoreCLR optimized for speed and throughout and MonoVM optimized for aot and small size workloads (aka apps and webassembly).
Nodejs is beat by CoreCLR dramatically on its own domain.
GraalVM i have to little insights but CoreCLR beats/equals performance of it java equivalent. I guess you can tweak GraalVM a lot more than CoreCLR because that is an actual weak point of the CoreCLR.
What's lacking? I'm sorry, I last fooled around with message queues like over ten years ago (and it was MSMQ and IBM MQ), but was recently working on a hobby Rpi project where I came close to dinking around with RabbitMQ via Python. It looks like RabbitMQ has a library for .Net. Or are you talking about how the native library System.Messaging is not generic enough to go outside the bounds of MSMQ still?
Truly not challenging anything you're saying, just curious to know what you'd prefer to see.
HTTP has a huge infrastructure for translating http request into endpoints. With all the bells and whistles. Nothing is there for messaging. You can get a library for everything but there is no focused stack for processing messages.
SignalR can be used for some applications, but “messaging” is a pretty broad category of different solutions, and I’m not sure what you’d want baked into ASP.NET to accommodate that. HTTP is standardized enough that basically everybody is doing it in very similar ways, but many pieces of a web application are better left for libraries to support.
Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?
Agree with what you said. It is a complicated problem.
I do not look into other platforms. I look into my solutions: http i can write my business logic and that is mostly it. On messaging i have to think about threading, acknowledging, dead / poison letters, decoding, trace contexts, etc. And these is all non trivial code especially when done right.
I mean, HTTP is a protocol with huge footprint/mindshare/utility to put it mildly. Messaging has.. who can name it? AMQP. I think it would be brilliant if System.Messaging was reoriented to AMQP, especially since MSMQ is not coming back. It's a bit lame that the namespace is locked into to a proprietary and EOL product, for sure.
It is mainly about non functional needs. A message queue you would use when you have no need in synchronous results, peeks in traffic or want a higher reliability.
If you are ab embedded dev, imagine you want to hand of sensor value to a central service without required immediate response.
If you are a game dev, imagine a play turn result hand off to a central leadership board.
Queues and related Message processing are a tool everywhere not just web development.
Proper AOT compilation and better handling of low level COM APIs.
NGEN never was anything more than a good enough start-up accelerator, and while .NET supports COM, is cannot directly use COM like APIs like DirectX without some extra help in wrapping.
Every time .NET teams try to improve these scenarios, usually Windows Dev team comes around and steals the show, apparently too much .NET isn't welcomed in some units.
This is how you end up with Longhorn and Midori being sabotaged, or .NET Native being dropped.
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.
Up until very, very recently .NET was absolutely useless on non-Windows platforms, only supporting the bare minimum APIs you need for web apps. It's still not very useful on non-Windows platforms.
I might be in a minority because I write a lot of .NET which in production is almost exclusively deployed on Linux. It's absolutely viable, performance is great, and tool support is fantastic. We agree so far.
However, I have to point out that .NET does have a Windows-only heritage, and as a result, a lot of lower-level APIs (files, processes, signals, pipes, terminals) still have some painful Windows-isms. Fortunately, the situation improves every year, and for a typical server application that exclusively communicates over the network, you're completely fine (and have been for several years now).
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.
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.
Well, perfview, for one. I have to keep a Windows VM nearby just for that thing. It doesn't come in handy every day, but is absolutely indispensable when it does. They have a shitty Linux port which basically doesn't work and receives almost no development.
I should also add that you /can/ dump a dotnet application running under Linux. It's just you can't do anything really useful with it, the best tooling is Windows-only. Clearly shows you their priorities.
It's been a while since I looked at .Net, but last time I checked it was inferior in terms of multi-platform tooling to many languages.
So take VS Code for example, last I looked you could not build Xamarin apps in it, where as with Go, JS, Dart, etc you can use VS Code to create anything in those languages.
I second this. .NET core works flawlessly on Linux and JetBrains Rider (and on Mac, which is what I develop on). The standard libraries and ASP.Net core are really well designed and a joy to work with.
Yea Jetbrains Rider is fantastic. I'm assuming the parent never tried it. Seeing as it is essentially IntelliJ the comparison to Java tooling seems ironic.
Rider is a solid mix of C#, F#, Kotlin, and Java (and likely more). The R# engine is a very large .NET codebase, and the F# plugin to that is written largely in F#. So it's a little more complicated than whatever the shell is written in.
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.
> Conversely, if you're writing C#, you'll want to use Rider.
Sure, that's what I do, and what my friend did before he went to another company where they somehow managed to fuck up the project configuration so bad it was absolutely impossible to deploy from under anything other than Visual Studio. It's using some sort of integrated Azure wizardry, I don't work there and can't pry into their secrets. The thing is, you can't work with that project without a Windows license and a Visual Studio license. MS has zero interest in supporting this use case (can't blame them, I'm just stating the fact.)
And that is the thing right! When you stop understanding the tools, you are screwed. I (as a .NET fanboy) prefer CLI tools anytime over some VS Azure toolbox no one understands).
When I write Java I actually don't ever touch InteliJ because I am not a masochistic.
No support for JNI debugging, no incremental compiler, 10 finger key chords, requires explicit menu actions to display project errors, never stops indexing the world,....
.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.
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 wouldn’t call it performance, but control. The Java and .NET world focus on different things - the JVM has a very very advanced JIT compiler and due to the programmer not being able to specify all that much about certain aspects of code it has a better chance of optimizing it (similarly to how SQL queries can be made very fast precisely because they are at a high level of abstraction). The CLR provides more control at the expense of less optimization opportunity. This escape hatch is really useful for some programs, but not all of them would benefit from it.
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.
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].
Don't intend to undermine the progress being made. Nevertheless here I am, migrating my dot net core 3.0 application back to Dot Net Framework 4.5.1 because I need my applications to run in all those Windows 8.1 (enterprise-internal) PCs without needing admin privileges to install dot net runtime. Since 4.5.1 runtime comes pre-installed with Win 8.1. So that is the version I target for all my new inhouse civil-engineering applications. There isn't much point bloating the application by 80+ MB just to make it self contained executable of dot net core version. After all, I need civil engineering to speedup, not fighting latest framework versions.
If using the self-contained deployment isn't an option then this is the correct solution. I don't see what the problem is. You can't always use the latest and greatest. I often had to use .NET 4.0 because it had to run on some way outdated systems where client IT was refusing to install updates.
Bet they got hacked by now, as they should be. ;-)
You might not need to do this. You can roll a fully self-contained distribution that will work for this OS with options to dotnet publish.
Unless you're sending your software to Mars, I say that saving 80mb of package bloat is not worth the engineering time especially for an OS that will be EOL in less than 2 years.
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.
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).
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".
The newtonsoft json dlls (and other) distribution contains different dlls in different folders called "net45", "netstandard2.0", "portable-net40+sl5" etc.
So it is obviously more than just a specification, since binary dlls can target different values of "netstandard" in addition to .net framework and .net core.
It is the same use case. c# is slightly more modern and lib space is cleaned up. I do not know your age, but long time ago Microsoft messed with Java and got into huge legal troubles. As a consequence they developed .NET with the language designer who did before TurboPascal and afterwards Typescript. It is a bit more optimized for productivity but so are many other languages nowadays.
When I first started development work (my background was in engineering math), couple of my colleague mocked me for liking c# and .net. They responded by saying, “I don’t want to reply to that because I don’t want to say anything insulting”. This was in regard to good backend language for crud web server with somewhat complex business logic. Responder worked in my team, and I was their manager.
It really lowered my confidence, as I had comparatively less dev exp than him. It is good to see HN also sees c# as solid and good language.
then GO came to the party and completely deprecated both java/dotnet, at least to me, i never looked back
- native AOT compiled executable
- 1 small file
- ultra fast compile time
- great ecosystem
for all my backend needs, it's GO
with dotnet everything feels heavy, ancient and bloated, msbuild and their xml for their projects, when you need to add some logic things becomes unreadable with XML logic, it's a mess, their json attempt wasn't great either, it was just JSON vs XML, they should have went with C#, build.cs, that's it
then you have deployment, it's MUCH MUCH easier than with java and with their jar/classpath bullshit, but it still is a bloat, it's a DLL mess
and let's not even talk about how everything is attached to microsoft
even their WASM effort isn't called WASM, you can't target a WASM module, it's BLAZOR, with MONO (why mono still exist when you have dotnet core? i have no clue, it adds to the bloat sentiment), wether you like it or not, it's BLAZOR, wich sucks because i wan't to handle hosting my way, from the beginning they vendor lock you
Go is ridiculously verbose and it is funny when Go advocates call Java that. The “C with GC” is sort of true about it in terms of no abstraction power resulting in one having to write many times more code with real redundancy.
Also, its performance for low-level situations is not-bad due to not having to use gc due to structs, but it has place to improve on more complex use-cases with lots of garbage generated.
small single file publishing, native AOT executables, fast iteration time with quick build time, non existent cold start, simplicity of the whole stack
239 comments
[ 3.0 ms ] story [ 260 ms ] threadYou 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.
https://rider-support.jetbrains.com/hc/en-us/articles/440192...
Did not know that about Rider, thx I'll def check it out.
You might have to update .NET 5 SDK to a more recent version.
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://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.
There are currently 244,641 libraries through nuget
https://www.nuget.org/packages
Ps. You can use libraries from f#, c# and VB.net. So as a .net developer, your statement doesn't make any sense.
You could have mentioned the different frameworks. But there is interop through the CLR between languages.
The parent post is correct that the third-party ecosystem (especially OSS) is sorely lacking in quality.
Like look at logging - logging in .net is SO anemic. Even with third-party libs, there are so many features missing that have been in java libs like slf and log4j2 for years, yet we have nothing close in .NET.
Hell, you could just pick a feature from spring and compare to what's available in .NET ecosystem, and you'll be sorely disappointed.
Being able to monitor levels via an administrative endpoint.
A decent rolling file implementation that can compress the archived files.
These are all things I've had to implement (on top of serilog, no less) in the past year.
log4j2 has these out of the box.
LoggingLevelSwitch?
> Being able to monitor levels via an administrative endpoint.
I wrote actuator endpoints for this one, was not hard but yeah.
> A decent rolling file implementation that can compress the archived files.
serilog-sinks-file has FileLifecycleHooks?. There's OOB serilog-sinks-file-gzip but you can also implement your own.
All the sinks for whatever you want.
Java simply has developer mindshare, the .Net developer stereotype is so rigid and engrossed that the pay difference between a .Net dev and their Java peer is usually around 20% if not more.
I don't see how this is a valid comparison. Java being paid better has nothing to do with scarcity of expertise.
Whether that explains part or most or all of Java dev pay premium is at least debatable. For instance, I would never make the same "throw a rock into a crowd" statement about finding a competent (but not expert) java developer. That alone means I would expect to pay some of a premium for finding them in that crowd.
What's the counter argument to scarcity? Alignment with better paying industries, weighted so heavily in that direction that it shows up as a premium for their developers? I mean, if you start getting into the conversations about the obscurity of domains, or supplemental education associated with Java developers either by coincidence or requirement, or general demand, I think you're still commenting about scarcity.
JavaWorld is bigger and Java developer count exceeds .net developer count, so the whole scarcity thing is a static explanation of a much complex dynamic environment. The intent here is not to complain about .net dev wages.
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.
https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Unfortunately I don't know much about it yet, it's not my area. Is it not sane?
Example: https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Compared to Win32 not changing much since roughly 1995 or so, it's wild and constantly shifting, but compared to say JS frontend frameworks it's more stable than a lot of things people are doing in UI.
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.
I guess the problem is that I've just never had to use on of these at work.
So when programming in my free time in both Java and .NET it's way easier/more fun to just use microservice libraries that are easier to pick up.
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.
Oh, and every single person who has hair on their neck looks unkempt, without exception, am I hearing that right?
Sure, OK.
https://en.wiktionary.org/wiki/neckbeard
Yes, shave it. Especially if you have long neck hair and short or no facial hair.
There are some exceptions, if you have a long beard, maybe.
Hair in other places is considered equally distasteful (long nose hair, ear hair, whatever).
...by some. Clearly others disagree.
Personally, I like hairy men and women. It's a clear sign that I won't have to deal with some priggish prude who is more concerned with looks than personality.
Ok, but don't be shocked if some of those priggish people avoid you and unfortunately for you, they may be the ones deciding to give you a loan, to go on a date with you, to offer you a job, whatever.
Everything in life comes with trade offs.
And sometimes it's not worth winning the battle to lose the war.
Everything does come with trade-offs. That's correct.
Being well-traveled is a cure for bigotry though. Realizing that you're in a bubble is the first step.
* rejecting other personal hygiene customs
* being noticeably more pedantic
* picking every battle/argument
* lower than normal respect for other's boundaries
* lower than normal awareness of how their actions effect others
* making "being rational" a core part of their identity
* dismissing human behaviors they don't do as irrational. usually these are the ones where rational explanations do exist, they are just difficult to re-invent on the spot.
This package is common enough to have earned itself a name, which happens to be the easiest visual indicator.
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
You don't need to use any of the new C# features. You can still build and run C# 1.0 code today.
That’s like saying the English language has accumulated too many new words, and that impacts your speech.
You have that new guy that comes in and whant to rewrite everything with the new immutable feature.
If the language has 3-10 different ways of creating a class/object and every developer does it differently then it certainly impacts the productivity ;)
However, when I think back to my first line of code 30 years ago, i would also be scared of modern languages (however this applies to all actively maintained languages).
You should not pick up this stack for a startup or for any operation that involves less than three full-time backend developers. Iteration is so slow because all the bad OOPy practices and patterns from the 90s are still alive.
In just a month our intern made a web app using Django/Python and InfluxDb that would have taken us two months to implement.
It's sad because modern C# is an amazing multi-paradigm language. But the .Net ecosystem insists on partying like it's 1999.
Master Jonathan Channon (and contributors) have done an awesome job with carter! It’s definitely an awesome alternative. And I think with the stuff David Fowler has been working on to make hello world easier it will help make carter better too.
You should definitely use this stack for a startup or any operation with less than three full-time developers.
I've literally done this at three enterprise scale startups with just three devs (including myself). Working on the 3rd startup right now. The productivity of .NET, Visual Studio, and Azure is amazing.
Without knowing what exactly was being implemented it's hard to assess. However I think any halfway decent .NET developer can probably stand up a low-medium complexity MVC app in a couple of weeks. Granted you could go full OO-brain and use all sorts of patterns, service layers, onion architecture etc. to bloat the code. But you don't have to, if it's a quick throwaway you could simply do data access directly in the controllers (even using EF to abstract away any SQL writing).
Can you expand some more on what exactly the bloat is that you feel slows .NET development down?
A single django/influxdb project doesn't say much, and I bet you can find .NET devs who'll build that in a day.
Check this one out: https://www.falcoframework.com/
The coding patterns and practices are _very_ different in the F# space. I personally find them much cleaner.
As proof: https://github.com/AccelerateNetworks/NumberSearch
I've built on many stacks and although I agree that iteration speed is important; It has more to do with how you organize your project and the quality of your tooling than with the specific language/framework.
If you don't like the OOPy style, don't write in it. Pattern matching in C# is quite nice, and you can always mark you functions as static. As a bonus, simple functions are easier to test to.
In our startup products, we've built entire production sites with data stores, front-ends, payment systems, and the core product, in a few weeks.
I think it greatly depends on the skill level of the developer. In the end, "startup dev" is mostly tying together a dozen libraries, a datastore, and whatever your secret sauce product might be.
VS is nice, and one of the better IDEs but by comparison it is wildly overpriced.
At any rate, I've never found even the free Visual Studio Community to feel like a "basic editor."
I would be hesitant to join a company that isn't even willing to pay for vs professional.
The cutoff for Community is >5 VS Community users (not developers, either, as VS is also intended for testers, etc.), not 250, or >250 PCs in the org (not “developers” or “using VS Community”, just PCs existing in the org.)
Also what's the problem with VS Code? It's great for C#, and basically the mainstream choice for many other stacks like Go and Node already.
As long as you have a small number of total VSC users (not just on a team/project, but in an org; ≤5), and are in a small, luddite, or mostly-tablets org (≤250 PCs), and don’t have much money coming through (≤$1 million revenue.)
Otherwise, its only usable for open source work, academic research, and classroom training.
ReSharper isn't really needed although nice to have and actually not expensive. It costs less than a decent toolbox for a handyman.
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.
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
https://docs.microsoft.com/en-us/lifecycle/announcements/sil...
As context, AngularJS EOL's December 31st 2021. Silverlight debuted 2007, AngularJS 2010.
You can still use WPF and WinForms, but they have serious limitations and feel old. WPF for example makes G-SYNC switch to 60 Hz.
https://github.com/xamarin/Xamarin.Forms
https://github.com/dotnet/winforms
>There isn't a single first-party desktop GUI framework left that is actively supported and developed.
This is demonstrably false...
https://github.com/dotnet/maui
https://github.com/microsoft/microsoft-ui-xaml (WinUI 3)
WinUI 3 includes all of what used to the the UWP controls and Renderer but "lifted and shifted" out of OS updates and also made accessible to non-UWP (primarily Win32) applications in Project Reunion (and techniques such as "XAML Islands").
I’m pretty sure it’s no longer feasible to modernize even WPF. I just checked: It still has its G-SYNC issues, even on .NET 5.
Totally forgot about Xamarin too because it’s so irrelevant. But maybe MAUI will change that, who knows. I’ll believe it when I see it I guess.
They could be EoLed.
> There’s simply no alternative.
Are you seriously saying there are no alternatives to WPF or Winforms?
>However, they sure aren’t alive either. Development has been stalled for many years
https://www.youtube.com/watch?v=NDYcq1yKhiA
> and both are very old.
Linux is old.
> I’m pretty sure it’s no longer feasible to modernize even WPF. I just checked: It still has its G-SYNC issues, even on .NET 5.
Or because the issue only has 6 thumbs up on Github, so MS is spending its resources elsewhere.
> Totally forgot about Xamarin too because it’s so irrelevant.
Sorry, but you just read as so salty you're hard to take seriously.
And yes, since 2012 there were no major changes to WPF. And even these changes were small. The last truly major change came with .NET 4.0. So there was a decade of almost nothing, even while XAML evolved with UWP. It truly doesn't get any more dead than that.
Of course I'm salty. WPF promised a lot, delivered some then died. Xamarin wasn't even part of Microsoft back then. UWP is a joke. Microsoft neglected the "Win32" desktop for way too long. Now it lets the community do what it should've done ages ago.
Xamarin worked in 2016, as did UWP itself. Failing those Win32. Funny that you're arbitrarily throwing in a year, given that your OP didn't mention it, but whatever. If anything you can criticize MS for making too many UI frameworks lol.
You keep calling things that are literally still supported "dead". How about you use terms with real meaning, instead of just saying things that are literally untrue...
> It truly doesn't get any more dead than that.
> Of course I'm salty. WPF promised a lot, delivered some then died.
> We can certainly agree that neither WPF nor WinForms are dead.
Okay I'm done here. I wish you the best with your salt.
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.
However their actual services are also pretty terrible. Pretty much everything takes significantly longer to deploy than the AWS couterpart. There are so many preview and deprecated features that it is often hard to judge exactly what feature set you are getting, this is often compounded by the fact that almost everything has multiple SKUs which also change available features. Azure AD RBAC is a bit of a mess, although its conceptually simpler than AWS IAM policies its just a pain to use in practice, and its often slow for changes in permissions to actually reflect. Azure VM disks are annoying to use too, you can't set the size of the OS drive at creation and extra data disks come unformatted. "Grossly incompetent" is probably an overstep though, Azure is very impressive, just not as impressive as its competitors right now.
Having said all that their are a couple places where Azure really shines in my opinion:
* Resource groups (GCP has a similar feature) allow you to more easily keep track of related resources across services. * Price transparency. Many (not all) services tell you up front hourly/monthly costs as you are deploying them through the portal. You don't have to track down a pricing page or calculator yourself. * Azure functions are amazing when using C#/.Net. A huge amount of the regular boilerplate is abstracted away into simple C# annotations so you can get a large % of business logic.
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
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.
I am not joking, I wish I was. The official C# debugger is not only proprietary, it’s also not licensed for VS Code versions compiled from source.
The rest looks cool, hopes are high for MAUI. But really man, forcing me to jump through a bunch of hoops just to get a (somewhat) working debugger ... That kind of a move is a remnant of the old Microsoft that absolutely needs to die for the new Microsoft to live on.
In addition, I'm not even sure if the telemetry on VS Code can be turned off. I think "yes", but never bothered checking while VS Codium was available.
Pretty important in case they fall back into old Microsoft‘s Embrace, Extend, Extinguish hab... oh, look ...
And it shows that they actually know what they’re doing. I don’t know what it is with Microsoft in particular, but they have really mastered the art of building user hostile applications. God, Visual Studio is a mess. I envy you.
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.
Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?
MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.
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.
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 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.
When you wanted to address unity, that is far more than Xbox.
And gaming is a maybe 20% share of .NET.
Nodejs is beat by CoreCLR dramatically on its own domain.
GraalVM i have to little insights but CoreCLR beats/equals performance of it java equivalent. I guess you can tweak GraalVM a lot more than CoreCLR because that is an actual weak point of the CoreCLR.
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.
Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?
I do not look into other platforms. I look into my solutions: http i can write my business logic and that is mostly it. On messaging i have to think about threading, acknowledging, dead / poison letters, decoding, trace contexts, etc. And these is all non trivial code especially when done right.
If you are ab embedded dev, imagine you want to hand of sensor value to a central service without required immediate response.
If you are a game dev, imagine a play turn result hand off to a central leadership board.
Queues and related Message processing are a tool everywhere not just web development.
NGEN never was anything more than a good enough start-up accelerator, and while .NET supports COM, is cannot directly use COM like APIs like DirectX without some extra help in wrapping.
Every time .NET teams try to improve these scenarios, usually Windows Dev team comes around and steals the show, apparently too much .NET isn't welcomed in some units.
This is how you end up with Longhorn and Midori being sabotaged, or .NET Native being dropped.
First class support for native code. I'm not too sure where their IL stuff is going anyway.
.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.
However, I have to point out that .NET does have a Windows-only heritage, and as a result, a lot of lower-level APIs (files, processes, signals, pipes, terminals) still have some painful Windows-isms. Fortunately, the situation improves every year, and for a typical server application that exclusively communicates over the network, you're completely fine (and have been for several years now).
.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.
Back in the early Windows days it was C and C++, then VB came along and it was VB for business while real developers used C++/MFC.
With .NET management tried to create an homogenous runtime, hence why it even supported Managed C++ (replaced with C++/CLI on .NET 2.0).
But they made an huge mistake that persists to this day, splitting the languages across these divisions, thus fuelling their feudal politics.
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.
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.
I should also add that you /can/ dump a dotnet application running under Linux. It's just you can't do anything really useful with it, the best tooling is Windows-only. Clearly shows you their priorities.
Since that is adapted to use Linux specifics :)
So take VS Code for example, last I looked you could not build Xamarin apps in it, where as with Go, JS, Dart, etc you can use VS Code to create anything in those languages.
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.
Sure, that's what I do, and what my friend did before he went to another company where they somehow managed to fuck up the project configuration so bad it was absolutely impossible to deploy from under anything other than Visual Studio. It's using some sort of integrated Azure wizardry, I don't work there and can't pry into their secrets. The thing is, you can't work with that project without a Windows license and a Visual Studio license. MS has zero interest in supporting this use case (can't blame them, I'm just stating the fact.)
Azure CLI just works fine without VS.
No support for JNI debugging, no incremental compiler, 10 finger key chords, requires explicit menu actions to display project errors, never stops indexing the world,....
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.
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.
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.
[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
Don't intend to undermine the progress being made. Nevertheless here I am, migrating my dot net core 3.0 application back to Dot Net Framework 4.5.1 because I need my applications to run in all those Windows 8.1 (enterprise-internal) PCs without needing admin privileges to install dot net runtime. Since 4.5.1 runtime comes pre-installed with Win 8.1. So that is the version I target for all my new inhouse civil-engineering applications. There isn't much point bloating the application by 80+ MB just to make it self contained executable of dot net core version. After all, I need civil engineering to speedup, not fighting latest framework versions.
Bet they got hacked by now, as they should be. ;-)
https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
Unless you're sending your software to Mars, I say that saving 80mb of package bloat is not worth the engineering time especially for an OS that will be EOL in less than 2 years.
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.
.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).
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".
So it is obviously more than just a specification, since binary dlls can target different values of "netstandard" in addition to .net framework and .net core.
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.
It is the same use case. c# is slightly more modern and lib space is cleaned up. I do not know your age, but long time ago Microsoft messed with Java and got into huge legal troubles. As a consequence they developed .NET with the language designer who did before TurboPascal and afterwards Typescript. It is a bit more optimized for productivity but so are many other languages nowadays.
It really lowered my confidence, as I had comparatively less dev exp than him. It is good to see HN also sees c# as solid and good language.
Technologies should be debated by weighting their pros and cons, not with insults.
- why dotnet when java exists?
then GO came to the party and completely deprecated both java/dotnet, at least to me, i never looked back
- native AOT compiled executable
- 1 small file
- ultra fast compile time
- great ecosystem
for all my backend needs, it's GO
with dotnet everything feels heavy, ancient and bloated, msbuild and their xml for their projects, when you need to add some logic things becomes unreadable with XML logic, it's a mess, their json attempt wasn't great either, it was just JSON vs XML, they should have went with C#, build.cs, that's it
then you have deployment, it's MUCH MUCH easier than with java and with their jar/classpath bullshit, but it still is a bloat, it's a DLL mess
and let's not even talk about how everything is attached to microsoft
even their WASM effort isn't called WASM, you can't target a WASM module, it's BLAZOR, with MONO (why mono still exist when you have dotnet core? i have no clue, it adds to the bloat sentiment), wether you like it or not, it's BLAZOR, wich sucks because i wan't to handle hosting my way, from the beginning they vendor lock you
Also, its performance for low-level situations is not-bad due to not having to use gc due to structs, but it has place to improve on more complex use-cases with lots of garbage generated.
small single file publishing, native AOT executables, fast iteration time with quick build time, non existent cold start, simplicity of the whole stack
something both Java/Scala/C# fail to provide
for my low level needs i use C or D/Rust
for everything else it's GO