douglasg14b

If you're trying to build a company then stop using Blazor, and start using react/vue...etc for your frontend and make an Asp.Net API.

If you need a web app, then use well known technology to do it. Otherwise you're just playing in the sandbox, not building something that can be built quickly, and can be easily onboarded to.

So many C# devs are scared of FE tech, learning how to use it effectively will only make your work better, and speedier.

Essentially, use boring technologies and be pragmatic.

Isn't this an entire class of problems that's avoidable by using strict DDD-style entities?

You don't have the same "purists" OOP problems, you don't have extension methods to get lost in, you don't have publicly mutable state, and you have a clear surface area for state changes. And your ORM is happy.

Purists OOP has all sorts of issues, more procedural, pragmatic, approaches can alleviate that pain. And strict entities provide the same surface area as the functional approach, without concerns over breaking ORM tracking. With the added benefits of closely guarding local state.

Opinion time.

This is less "what you can't do in OOP" and more "what you can't do if you use OOP design as dogma" 🤔. Perhaps that's an important distinction to make, depending on your viewership, but to me this feels like a solution looking for a contrived problem.

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.

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.