It's been entirely open source for 7 years now....
douglasg14b
joined 2 years ago
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.
Yes, tons. But it depends on the team and the software. If I'm on a small and inexperienced team for example I'm going to be doing a lot of the work, if I'm on a small but competent team then I may be doing a lot more design & abstraction then the actual work.
Right now as a tech lead I would say ~40% of my time is actual programming.
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.