[hnthrow289570]

The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack.

You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project.

I envy people who only do hobbyist C# so get to work on code bases that have all the newest language feature usage.

[djeastm]

>You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project.

I've been spending the past couple years migrating various platforms from Framework to the new .NET and as long as you've got a head on your shoulders it's not too bad. Also, new projects in .NET are fantastic to work with, imo.

[progmetaldev]

I have been doing the same, but I would be willing to bet that you're probably more disciplined than the average .NET developer (or at least have taken the time to learn more than just the surface features available). In my experience, most .NET developers don't take the time to really learn the framework (whether traditional .NET Framework, or the Core framework). It is a great feeling once you've got a Framework project migrated over to current .NET and everything is running along smoothly. My experience has mostly been migrating content management systems.

[rafaelmn]

I definitely dislike most C#/.NET developers/community (every time mediator is mentioned I want to stab myself) and would rather work with people in F#/FP.

But when you have to work on "diverse" development teams having some sort of patterns established (flawed as they are) brings some order to the insanity.

[xeromal]

My brain really likes how organizes C# libs tend to be compared to the 50 different organization schemes I deal with in node and python

[eterm]

Out of interest, what "patterns from the .NET framework era" do you think don't work well in .Net core?

( I'm someone who deals all day with legacy .Net framework projects, mixed with the kind of mix of .Net core 3, .Net 6, .net standard 2.0, and .Net 8 projects that you'd expect from a 20+ year old company with 260+ projects. And yes, I too envy hobbyists at time. )

[hnthrow289570]

>Out of interest, what "patterns from the .NET framework era" do you think don't work well in .Net core?

Overriding equals to do memberwise comparisons on POCOs

Any checking of types where pattern matching would be better

Old-style tuples without names (old style is tuple.Item1, tuple.Item2, etc.)

Checking of multiple tuple values at once without pattern matching

Any code that could be refactored with the new LINQ methods

Long ifs/switches that could be replaced by pattern matching

Concatenate a lot of strings (one per line) so there wasn't a ton of horizontal scroll, particularly for SQL in C# code

using statements still needing a level of nesting

[g15jv2dp]

Are the codebases produced by companies in other languages nicer?