C#, I still love you dearest
blog.tnwdevlabs.com
blog.tnwdevlabs.com
C# is my "not quick one off" language. When I want a one-off, I use Ruby because it's quick and easy... but when I need more than 1 file and I'll be dealing with lots of classes and complications that come with that, give me C#.
I've tried getting to know Rust, but despite my love for it's core ideas and syntax I just can't get into it for the projects I've had. Most of my projects don't tend to be things where I care about strict memory requirements or ridiculous performance. I mainly just want something that works good enough for my own use.
I also tried Go, but I quickly left that when I found it had no generic support and the community is basically anti-functional constructs, preferring pure procedural stuff instead.
This might get downvoted and all but ... I'm not sure how someone who has written C# for 8 years would think this.
I'm not even talking complicated things. Just OO basics like interfaces and abstract classes (with compile time enforcement) are pretty helpful as you evolve a code base.
Also, the way the various Microsoft frameworks use strings to specify property and type names drives me insane. It's just like.. "Hey, we have a really nice type and generics system... but here lets hop around that and instead use strings that we hope you never need to refactor, as well as magic method names (ie, RegisterRoutes, Application_Start)". This seems to be getting a little better, but it's still way too prevalent. It's almost like the people responsible for writing C# frameworks had a disagreement over strict typing and decided to just contaminate a ton of APIs to spite the type system.
IMO:
In the lower level architecture it's just more powerful designing functions and data structures to play with each other as you wish (but power is not necessarily a good thing, you can shoot yourself in the foot). You just do it, no need to define all those fancy interfaces, abstract methods, base classes...
In the higher level architecture, sure, you really miss those securities that interfaces and such enforces, JavaScript is amazingly breakable. But, fortunately, JavaScript/Node community modularizes so often (and well), that this is practically not an issue. The modules are well done, tested, there's community input, etc.
Or what if I want to check if a property exists in a dynamic object? Catch the exception? Use the ExpandoObject? Will this affect performance?
What about local delegates?
And I just won't start with reflection. Have you seem those snippets on SO? Now compare the same with JavaScript.
Don't get me wrong, I've been developing in C# for some good years in a row and I really like the language. C# traditional OO way of doing things kinda gets you by the hand when design your application. JavaScript is more on your shoulders. It's a tradeoff, you have to be more careful but you also have more power.
What about local delegates? Func<int, int> localDelegate = x => x + 1;
You don't need to use reflection as often in c# as you would in javascript.
I can't imagine trying to do such a thing in JS, which provides so little information about exactly what I'm reflecting over. And it's so clunky. Some things you can typeof, some you have to instanceOf, such that you basically end up doing both all the time.
With JS, I know that I have a bag full of things named something. I have to do my own work from there to find out if they are methods or properties or fields. In C#, I can just ask it to give me all of the properties. Oh, but stick to just the public ones. Or skip any that have an attribute named "Exclude" tagged to them.
Yeah, I have no idea what people are talking about that JS is better for reflection. That's just bonkers.
C++ allows way to many things and no normal human could ever hope to understand the entire language.
Java went too far the other way - it was so simple you ended up with a lot of boilerplate code (although this has supposedly gotten better since I last wrote much Java in Java 6).
C# gets the mix just right.
Lately I've been seeing C# as having that same affliction (though not nearly to the same extent). It all started with perusing some F# code samples, then following a few tutorials, and now C# is ruined for me forever.
For example, C# async/await is a compiler hack. In F# it was implemented as a library. This shows how powerful F# is and C# is not.
One of our reasons: The pool of (good) developers who can write C# is already pretty small in our little city. My company has enough trouble finding developers qualified to play with C#. If we switched to F#, our already-slow hiring would grind to a halt.
Credit is due to MS for learning to adapt to demand, not fight it.
The two biggest pillars of my experience developing C# though are ReSharper and NuGet. Resharper is without a doubt the best couple hundred bucks I've spent on programming tools (if only they didn't always seem to release updates seemingly the day after my year of free point releases expires...). And Nuget is the best thing since sliced bread. I don't think I would ever want to go back to trying to manually manage and install third-party libraries the way I used to have to when I was doing Java and C++ ten years ago.
To another 10 years!
C# has evolved greatly in 15 years. JavaScript is only just now seeing any useful change.