55
What programming languages aren't too criticized here?
(lemmy.fbmac.net)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Sep 2023
55 points (100.0% liked)
Programming
17334 readers
146 users here now
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
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
C# doesn't have a big spotlight on it like Rust or Python, but it is a popular and very unhated language. It's a good language that is regularly improving and has phenomenal documentation. Seriously, I've not gone to Stack Overflow for anything C# (outside of third-party libraries) for years; Microsoft's documentation gives me everything I need.
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.