Well it has kept me employee for quite some time now so that's something to celebrate.
The opposite side to that it I think every commercial .Net system I've ever worked with / on has been an absolute mess. Not sure if it's .Net or the companies but something there seems to attract devs to make ill performing, over abstracted, confusing, massive architecture systems that in reality could be simplified down to a bunch of data forms.
As I say I shouldn't complain keeping these things running pays my bills.
It makes me really sad to read things like this. .NET/C# gives you the tools to write elegant, performant code in any domain, and really rewards high level of expertise, with stuff like advanced parallelism support, and optimizing things like memory layout with structs, really great native interop story, or the ability to write Source Generators/Analyzers, so you can develop AST-parsing compiler plugins to do stuff like automated code generation/analysis.
Imo it has a way higher skill ceiling, than something like, say NodeJS, which is supposedly part of the cool kids club.
I have literally had conversations with hardcore devs that had the 'enterprise offshore-bait' perception of the language and were surprised when I showed them all the awesome stuff you can do with it.
I really think this is because of the way companies act and not the fault of any technology. We work in a field where companies really believe they should try for the cheapest labor possible without thinking about the consequences. When written with thought programs with .NET or any other platform work well. When you start replacing the person who had real knowledge and experience with the recent boot camp grad, "because that was the more affordable option" that's when problems start to arise.
I liked seeing the expressions of frustration when developers that were sloppy with their coding style were no longer able to get away with code that didn't meet the coding standards.
When it was adopted it literally made some people scream in frustration, and I loved it for that.
The default ruleset of StyleCop is absolutely brutal and unforgiving with messy code.
I wonder if this is because the languages we use today like C#, Java etc evolves mostly horizontally, like standard library improvements, syntactic sugar, performance etc, instead of vertically like higher abstraction and modularity.
What I’m trying to say is that we lack abstractions to model our intent on a higher level.
I think that is why we invent things like micro services because we can’t express modularity on higher level good enough , when that type of abstraction should be built into the language itself (and irrelevant if it is on a separate network node or not).
I guess Java modules is a go at this, don’t know if successful or not.
That is how I at least feel when I’m maneuvering huge projects, a building block is missing.
I started my career as a .NET dev, and until recently was the stack I've worked the longest with. I have fond memories of working with C#.
However I am no longer interested in any job that uses .NET and have removed all mention of C# and .NET on my LinkedIn and resume. This is because even despite great recent advances, .NET still seems to be almost exclusively used by tech-as-a-cost-center enterprise companies that I have no interest in working for anymore.
I'm sure there are some great companies in some corners of the world working with C# and .NET, but as far as I can tell, they are still by far, the exception, not the rule.
The landscape has been changing rapidly since .Net Core (now just .Net) matured 3-4 years ago. As you say there are a LOT of big enterprise shops out there using .Net, but more and it's catching the attention of small companies and startups. I work at a small-ish (~300 employees) B2B SaaS that has a wide variety of legacy code bases: .Net Framework, Node, Ruby, Php, and a few others. We made the decision last year to make .Net our default choice for new projects.
That's a good point I don't see mentioned much about choice of tech stack and impact on career.
It's not so much about the technical merits of the stack itself as about what kinds of companies and projects use that stack, and sometimes it might be worth learning some technologies you might not be particularly invested in if you want to work at those companies.
It's not easy to switch stacks either - yes you can learn a new stack but you need those golden "years of experience" in your resume, making a switch an expensive and risky proposition, so you need to choose wisely.
I feel seen with this comment and I'm glad I'm not the only one that has been feeling this way.
I'm about to start a new position that uses C#/.NET and seems like a technically mature/sophisticated organization. Finding this position was hard though.
If that fell through, I was thinking of ways I could try to switch tech stacks. As you stated, the types of companies that gravitate towards .NET are not the types of companies I want to work for anymore.
Not to mention, after talking to several recruiters, it seems like salary for .NET devs are much lower than counterparts in other languages. I'm probably at the top of what I can expect to make as a senior engineer in .NET. I spoke to a few recruiters who recruit for other stacks and my salary is what senior devs typically start at for those organizations.
I'll agree upfront that it's been adopted very corporately, but it's worth noting that the Unity game engine uses C# extensively. If you enjoy video-games and one of them is on this list[1] it was likely written in C#.
I’m in the same boat. C# and F# are excellent languages. But C# jobs are as you describe. F# jobs are practically nonexistent. So, I’ve moved on to other stacks. I do miss LINQ. Other than that, I’m quite happy with Go and Node+TypeScript.
Technology is still central to "tech-as-a-cost-center" enterprises. I'm absolutely a cost center and contribute to the firm's market differentiation by using technology effectively.
Sigh (fond memories) - I had just signed a deal to make my 1-person consulting company a Sun Certified Partner, as Java was clearly the future. VB6/COM was an obvious dead-end, and my other preferred alternative - Borland Delphi - was just not being considered by my enterprise clients.
A friend who had recently been hired into Microsoft got me into the alpha pre-release program for .NET. And boom - I never touched Java again, except to port code to C# (or tell IBM sub-contractors how to integerate with .NET/Windows authentication ecosystems).
Weirdly enough - as a programmer who got my start with VB1, I ended-up immediately preferring C# over VB.NET - mostly because my first paying .NET client was facing a complete dead-end with FoxPro - so, as we were performing architectural and technical evaluations of .NET, it was exciting to see that C# was submitted very early-on for ECMA (and eventually ISO) certification.
Myself - I see the release of .NET as the point where Microsoft started to become more open, more platform-agnostic and more developer-friendly than it had ever been before.
> Myself - I see the release of .NET as the point where Microsoft started to become more open, more platform-agnostic and more developer-friendly than it had ever been before.
.NET certainly was more developer friendly, and I guess more open in a way by engaging with standardizing bodies. But more platform-agnostic? The original .NET (anything before dotnet) was very windows-centric. You couldn't take your .NET code and run it anywhere else. The C# language was ISO-certified, sure, but not the APIs. And C# without the APIs is quite uninteresting.
MS only started being interested in platform agnosticism again in the last 3-4 years, because they aren't the dominant platform anymore in a few important verticals (servers and mobile). But for most of the previous decade, they have not cared at all about it.
As someone coming from Node who has only recently (with .NET 6) taken a good look at the ecosystem, it appears to me that there have been a lot of breaking changes to get where they are now.
On one hand, I love that they’re trying to reduce boilerplate and align closer to something like Node with Minimal APIs. On the other hand, nearly every reference guide or tutorial I look up is outdated and I’m left trying to figure out what changed between .NET 5 (or earlier) and .NET 6. I was following the Little ASP.NET Core book one day and things like there being no Startup.cs anymore (being merged into Program.cs) took me a minute to figure out, as there’s also no definitive resource for a newcomer on what has changed that would make older documentation inaccurate.
Both should cover the majority of scenarios. The main takeaway is that everything you usually configure in `ConfigureServices` now hangs off `builder.Services`, and everything you'd configure in the middleware pipeline `Configure(IApplicationBuilder app)` is available after you call `var app = builder.Build();`.
I'll note that the change to the Minimal API was only in the project templates, so the old model does continue to work without any breaking changes.
Most of the changes are not _breaking_. There are new ways to do things but the old still works. You can have both an api controller and a minimal api in the same application. I agree that it is hard to know which version a specific blog post or tutorials works for.
I really don't understand the obsession the ASPNET team has with minimal APIs. I'm firmly in the camp of wanting things to be explicit rather than implicit, because it gets difficult to keep implicit conventions in your head as things shift and melt chasing the latest fashions.
A lot of the changes are aimed at making it easier for people to get started with Asp.Net, and most of those aren't breaking changes. Traditionally Asp.Net has had a lot of boilerplate around project setup and configuration, and things like minimal APIs aim to change that. The unfortunate side effect is that it adds more complexity (more ways to do the same thing) to the ecosystem, and the newer minimal approaches probably aren't what you're see used in the typical production project.
For sure. There has been a lot of pushback in the community from both sides of that issue. They wanted to reduce the boilerplate and make it cleaner to make simpler projects (with the goal of enabling microservice scenarios). But that moved some people's cheese from the standpoint of what the recommended path is. The problem is that there's a huge amount of very good documentation on the microsoft documentation site, but it's not organized in a way that makes it easy to find.
I think in 50 years if Microsoft is still around, it’ll probably be because of .NET. For a company I have very little time for, .NET is an exceptionally awesome tool and ecosystem.
I must say props for the insane compatibility that was kept over the years/decades!
Even migrating some apps from vb6 was relatively easy, that effort shouldn't be underestimated.
A minor nit would be with Silverlight, but I wasn't affected by it. I didn't use much of wpf because of that though. Since around that time, everything migrated to the web.
On the bright side, a lot of Silverlight code still works since it wasn't a completely separate class library etc. Back when I was still working on JSIL, I had one enterprise customer who was slowly porting over a huge pile of Silverlight code to run on top of my stack. It was more feasible than you'd think since so much of the code could be used without modification. You basically only had to replace the frontend.
Currently working in the world of TypeScript/Node/JavaScript there's so much stuff I miss from .NET.
* Awesome standard library - very little need to install packages from randos on the internet
* LINQ makes performing complicated work with collections simple and readable
* Great async model for work that needs to be done in parallel or scheduled
Was also impressed at how much stuff they managed to add to it over the years:
* Generics
* Now runs just about anywhere: Windows/Linux/macOS/mobile
* Null reference types largely gets rid of the endless 'Object not set to instance of ...' errors
* Now supports some form of immutable data types (records)
Frankly most of the complaints I'm reading about here come from the companies that choose to use the technology rather than the tech itself.
This is microsoft not .net's fault. .Net was just jam to spread over the turds.
Microsoft tried to jump on every fad that came along and proceeded to burn all the old ones yet still keep the customers limping on them.
Lets not forget stuff like Velocity, DNA, AppFabric, Workflow Foundation etc all of which we had to spend millions rewriting out of products. Before that it was the C++ frameworks: MFC, ATL etc etc etc.
Not sure what you’re implying here. Those technologies, especially WPF with XAML, allowed me to be insanely productive developing desktop apps back in the day. In a way XAML is the precursor to stuff like React native and the like.
Granted, I feel like MS dropped the ball in failing to have an overarching vision of how their .NET technologies would work together and evolve for the future.
As a user (not developer) I liked Silverlight at the time, compared to Flash. Flash applications made my computer run very hot and the fans go loud. With equivalent Silverlight apps on the other hand my computer didn't break a sweat.
1. use .Net that work with open standard like ASP.net (html/css/javascript) never buy into Microsoft's own technology like Silverlight. Blazor look promising since its based on webassembly
2. Microsoft fat client is a mess. winform? wpf? uwp? which one to use? don't forget winRT
Has anyone seen some numbers on the .net core vs .net full usage? A lot of my projects are stuck on full, either because of incompatible dependencies, CLR APIs not implemented or winform. I can’t be alone. As a result I kind of stopped following what’s new on .net. It feels like a python 2/3 split of the user base, though a lot quieter.
In my opinion, almost every complaint I could possibly have about .NET would not exist if it weren't for windows. From the weird idiosyncrasies that make cross platform GUI development hard, to the dumb enterprisey software patterns, to the weird build systems and packaging...all of them can be traced back to windows somehow.
[+] [-] Dave3of5|4 years ago|reply
The opposite side to that it I think every commercial .Net system I've ever worked with / on has been an absolute mess. Not sure if it's .Net or the companies but something there seems to attract devs to make ill performing, over abstracted, confusing, massive architecture systems that in reality could be simplified down to a bunch of data forms.
As I say I shouldn't complain keeping these things running pays my bills.
[+] [-] torginus|4 years ago|reply
Imo it has a way higher skill ceiling, than something like, say NodeJS, which is supposedly part of the cool kids club.
I have literally had conversations with hardcore devs that had the 'enterprise offshore-bait' perception of the language and were surprised when I showed them all the awesome stuff you can do with it.
[+] [-] nikanj|4 years ago|reply
The others go bankrupt before it happens.
[+] [-] hughrr|4 years ago|reply
I got paid. That's all the good stuff I can say about it.
[+] [-] kemiller2002|4 years ago|reply
[+] [-] ahoka|4 years ago|reply
[+] [-] 29athrowaway|4 years ago|reply
I liked seeing the expressions of frustration when developers that were sloppy with their coding style were no longer able to get away with code that didn't meet the coding standards.
When it was adopted it literally made some people scream in frustration, and I loved it for that.
The default ruleset of StyleCop is absolutely brutal and unforgiving with messy code.
[+] [-] tored|4 years ago|reply
What I’m trying to say is that we lack abstractions to model our intent on a higher level.
I think that is why we invent things like micro services because we can’t express modularity on higher level good enough , when that type of abstraction should be built into the language itself (and irrelevant if it is on a separate network node or not).
I guess Java modules is a go at this, don’t know if successful or not.
That is how I at least feel when I’m maneuvering huge projects, a building block is missing.
[+] [-] em10fan|4 years ago|reply
[+] [-] marcos100|4 years ago|reply
[+] [-] throwaway6532|4 years ago|reply
[+] [-] mbrodersen|4 years ago|reply
[+] [-] decafninja|4 years ago|reply
However I am no longer interested in any job that uses .NET and have removed all mention of C# and .NET on my LinkedIn and resume. This is because even despite great recent advances, .NET still seems to be almost exclusively used by tech-as-a-cost-center enterprise companies that I have no interest in working for anymore.
I'm sure there are some great companies in some corners of the world working with C# and .NET, but as far as I can tell, they are still by far, the exception, not the rule.
[+] [-] Merad|4 years ago|reply
[+] [-] danjac|4 years ago|reply
It's not so much about the technical merits of the stack itself as about what kinds of companies and projects use that stack, and sometimes it might be worth learning some technologies you might not be particularly invested in if you want to work at those companies.
It's not easy to switch stacks either - yes you can learn a new stack but you need those golden "years of experience" in your resume, making a switch an expensive and risky proposition, so you need to choose wisely.
[+] [-] rc_hackernews|4 years ago|reply
I'm about to start a new position that uses C#/.NET and seems like a technically mature/sophisticated organization. Finding this position was hard though.
If that fell through, I was thinking of ways I could try to switch tech stacks. As you stated, the types of companies that gravitate towards .NET are not the types of companies I want to work for anymore.
Not to mention, after talking to several recruiters, it seems like salary for .NET devs are much lower than counterparts in other languages. I'm probably at the top of what I can expect to make as a senior engineer in .NET. I spoke to a few recruiters who recruit for other stacks and my salary is what senior devs typically start at for those organizations.
[+] [-] moritonal|4 years ago|reply
https://en.wikipedia.org/wiki/List_of_Unity_games#2021
[+] [-] christophilus|4 years ago|reply
[+] [-] sbergot|4 years ago|reply
[+] [-] wsostt|4 years ago|reply
[+] [-] strikelaserclaw|4 years ago|reply
[+] [-] gameswithgo|4 years ago|reply
[+] [-] jjkaczor|4 years ago|reply
A friend who had recently been hired into Microsoft got me into the alpha pre-release program for .NET. And boom - I never touched Java again, except to port code to C# (or tell IBM sub-contractors how to integerate with .NET/Windows authentication ecosystems).
Weirdly enough - as a programmer who got my start with VB1, I ended-up immediately preferring C# over VB.NET - mostly because my first paying .NET client was facing a complete dead-end with FoxPro - so, as we were performing architectural and technical evaluations of .NET, it was exciting to see that C# was submitted very early-on for ECMA (and eventually ISO) certification.
Myself - I see the release of .NET as the point where Microsoft started to become more open, more platform-agnostic and more developer-friendly than it had ever been before.
[+] [-] roblabla|4 years ago|reply
.NET certainly was more developer friendly, and I guess more open in a way by engaging with standardizing bodies. But more platform-agnostic? The original .NET (anything before dotnet) was very windows-centric. You couldn't take your .NET code and run it anywhere else. The C# language was ISO-certified, sure, but not the APIs. And C# without the APIs is quite uninteresting.
MS only started being interested in platform agnosticism again in the last 3-4 years, because they aren't the dominant platform anymore in a few important verticals (servers and mobile). But for most of the previous decade, they have not cared at all about it.
[+] [-] sylens|4 years ago|reply
On one hand, I love that they’re trying to reduce boilerplate and align closer to something like Node with Minimal APIs. On the other hand, nearly every reference guide or tutorial I look up is outdated and I’m left trying to figure out what changed between .NET 5 (or earlier) and .NET 6. I was following the Little ASP.NET Core book one day and things like there being no Startup.cs anymore (being merged into Program.cs) took me a minute to figure out, as there’s also no definitive resource for a newcomer on what has changed that would make older documentation inaccurate.
[+] [-] Hawxy|4 years ago|reply
The two pages you want are: https://docs.microsoft.com/en-us/aspnet/core/migration/50-to... and https://docs.microsoft.com/en-us/aspnet/core/migration/50-to...
Both should cover the majority of scenarios. The main takeaway is that everything you usually configure in `ConfigureServices` now hangs off `builder.Services`, and everything you'd configure in the middleware pipeline `Configure(IApplicationBuilder app)` is available after you call `var app = builder.Build();`.
I'll note that the change to the Minimal API was only in the project templates, so the old model does continue to work without any breaking changes.
[+] [-] jbergens|4 years ago|reply
[+] [-] thrower123|4 years ago|reply
[+] [-] Merad|4 years ago|reply
[+] [-] mpmpmpmp|4 years ago|reply
[+] [-] mindwok|4 years ago|reply
[+] [-] NicoJuicy|4 years ago|reply
I must say props for the insane compatibility that was kept over the years/decades!
Even migrating some apps from vb6 was relatively easy, that effort shouldn't be underestimated.
A minor nit would be with Silverlight, but I wasn't affected by it. I didn't use much of wpf because of that though. Since around that time, everything migrated to the web.
A well deserved thanks!
[+] [-] kevingadd|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
https://opensilver.net/
[+] [-] disease|4 years ago|reply
* Awesome standard library - very little need to install packages from randos on the internet * LINQ makes performing complicated work with collections simple and readable * Great async model for work that needs to be done in parallel or scheduled
Was also impressed at how much stuff they managed to add to it over the years:
* Generics * Now runs just about anywhere: Windows/Linux/macOS/mobile * Null reference types largely gets rid of the endless 'Object not set to instance of ...' errors * Now supports some form of immutable data types (records)
Frankly most of the complaints I'm reading about here come from the companies that choose to use the technology rather than the tech itself.
[+] [-] onphonenow|4 years ago|reply
Something about .net made Microsoft lose their minds
[+] [-] hughrr|4 years ago|reply
Microsoft tried to jump on every fad that came along and proceeded to burn all the old ones yet still keep the customers limping on them.
Lets not forget stuff like Velocity, DNA, AppFabric, Workflow Foundation etc all of which we had to spend millions rewriting out of products. Before that it was the C++ frameworks: MFC, ATL etc etc etc.
[+] [-] prmph|4 years ago|reply
Granted, I feel like MS dropped the ball in failing to have an overarching vision of how their .NET technologies would work together and evolve for the future.
[+] [-] thefz|4 years ago|reply
[+] [-] yakubin|4 years ago|reply
[+] [-] MangoCoffee|4 years ago|reply
2. Microsoft fat client is a mess. winform? wpf? uwp? which one to use? don't forget winRT
[+] [-] d--b|4 years ago|reply
Some things do change
[+] [-] pharmakom|4 years ago|reply
[+] [-] munchler|4 years ago|reply
[+] [-] cm2187|4 years ago|reply
[+] [-] ksec|4 years ago|reply
Just wondering as someone who doesn't have a clue about anything .Net.
[+] [-] darksaints|4 years ago|reply
Windows ruins everything.
[+] [-] Aurelius3|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Lapsa|4 years ago|reply