55
What programming languages aren't too criticized here?
(lemmy.fbmac.net)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
It is incredible really, I worked with C# for so long, and I tend to be very critical of the stuff I've used for a long time. For C#, I am struggling to figure how I would improve it, because all the stuff that suck in C# is usually the lesser of two evils.
Of course if you hate classes, types, managed memory or anything invented in the last 20 years you will hate it, and I've met people like this. That is why you gotta keep learning as a dev, you don't want to be one of those.
The 2 that I struggle with on a daily basis:
missing discriminated unions. Third party libraries kind of sort of fill the gap, but it's a pain point.
a flawed async programming model. Namely, there are multiple models (for historical reasons / backwards compatibility), and the more current one (task-based) throws a wrench in your ability to effectively design interfaces, functions, delegates etc. that can be shared between synchronous and asynchronous code. Green threads would have fixed this, at the cost of some other potential issues, but it looks we're stuck with tasks for now. Also, there is the awkwardness of needing to constantly use .ConfigureAwait(false) after every await, unless you shouldn't (e.g. in the UI thread), and if you get it wrong you might cause a deadlock in your app but not in a console app... A bit confusing and easy to mess up.
F# will give you discriminated unions and do-notation (it calls it 'computational expressions') while retaining full access to the .net ecosystem.
I really like ReactiveX for async programming, though having to go through a library is definitely a pain. It also does not make it less awkward to design your public API unless you're okay exposing Rx types. Fair points!