douglasg14b
Well I'm evil, so System.Text.Json.
Maybe after the whole world dunks on it feature champions devs will change their asinine stances on keeping it terrible...
If it helps, I've been a visual studio user for the last 9 years.
In order to better support non-C# devs onboarding to C# (who where mostly on Mac, and vs for Mac is terrible) I switched to Rider 6 months ago, so we are using the same IDE and I can help them out.
Holy crap, it's good. There are a few things that aren't quite as nice (no more intellicode, stack traces are kinda shitty), but after fixing some garbage default settings, it's turned into a pretty good IDE.
The visual studio debugger is still better though.
A codebase is different than the language itself enabling many ways to do the thing.
You may not think it's likely to cause problems, but have you actually onboarded non c# devs onto new C# projects?
I have been for the last 6 months and let me tell you it really opened my eyes to new problems. One of those is that there are many ways to do the same thing, which has been a consistent pain point for non-c# devs, and has been hurting adoption and general sentiment.
Honestly I didn't think much of it till now, and didn't think it would be that big of a deal. Turns out it is.
TBH I wouldn't recommend you be building applications in .Net Framework.... Most complaints about it have been a solved problem for years with .Net Core/.Net 5+. And there are upgrade paths, at least if you aren't maintaining WPF/Winforms
Bugs and regressions? I wonder if that's for different things than I touch, I've had almost no disruptions for the last 9 years. But I've mostly worked on console apps and backends. Almost no UI work aside from some WPF and Winforms side projects ages ago.
It's been entirely open source for 7 years now....
Performance limits of LINQ...?
You're getting nearly the same performance out of loopes generated by LINQ as you would normal for loops.
If you're referring to LINQ and EF Core, you're generation SQL with it, not running LINQ. And that query generation is incredibly performant these days (I think EF 7 was something like 5% slower than dapper?).
So luckily you can squeeze a ton of performance out of it!
You'll eventually get used to different casing conventions in different languages that's just something that you have to mature into.
Depending on the language you are writing the conventions will be different, it's often within your best interests to adopt to those conventions instead of trying to fight against them.
Type system rigidity, I started using TypeScript a lot over the last few years with FE work. TS is so much more flexible and expressive. I really wish that I could express constraints in C# as fluently as I can in TS
Enums really need more flexibility, unions, discriminated unions, left hand implicit type, better value support....etc
System.Text.Json still sucks, it's not greedy, no global setting , non-sane default,no expando support....etc it's awful to use.
Unstructured data in general is an absolute pain to work with.
Composability of tests is still super painful and verbose. Dynamic test generation is awkward and unergonomic. After doing testing and other languages that let you simply compose tests imperatively, C# testing is definitely painful.
IMHO C# is an acceptable language with an absolutely fantastic framework.
I love C#, but these are my primary gripes
That's pretty cool, but it doesn't address the big elephant in the room which is security and privacy.
No way my org would allow this if our code or data can leak to a 3rd party.
To be fair it's not a good comparison to compare an IC role against a management role for time breakdown.
Kind of sucks that the source is locked away...
Would be a lot more convenient to read it when I don't have the whereabouts to watch a video about it(env, data...etc).
Edit: Finally was able to get the whole thing to load, commented on my thoughts.