3 ms·
There is no reason to bash C#, but there is still reasons to be on the fence about it. The runtimes and libraries for non windows platforms are still behind, a
by jlawer 10y ago
There is no reason to bash C#, but there is still reasons to be on the fence about it.
The runtimes and libraries for non windows platforms are still behind, and are quite new. Additionally while there has been efforts to grow the community and get outside involvement, it is still obvious that Microsoft is the big player, and without their involvement the community might shrink to a fraction of its size.
Microsoft itself complicates matters as for some people it takes a lot to be convinced that "new Microsoft" isn't just old Microsoft in sheeps clothing, and its all a ploy to get people onto their platform so they can lock you in. I have started to be convinced that microsoft has actually turned a leaf and is actually working to build a community and genuinely will support other platforms, but I am always going to be a little cautious... call it post traumatic stress from the early 2000s.
Finally I don't see a reasons to rush to build in C#. It seems a perfectly decent language, but without being experienced in the language is there a problem domain (outside rich client windows apps) where the language is significantly better then other choices?
I don't think C# should be bashed, but I also think it still needs to prove itself to the non windows platform and open source developers.
- hacker_9 10y agoIntegrated Development Environment, Built in package manager, massive maintained ecosystem of libraries, fastest compiler in production (after lisp languages), compiler as a service, full runtime reflection and emit capabilities, three GUI libraries + Designers built into the IDE, A full blown MVC web backend toolset. There is more, but is this not enough? The language isn't perfect, but the idea that it has to prove itself to anyone is quite an arrogant stance to be honest.
- jlawer 10y agoIf I am going to have to support an application written in it to clients, then damn straight the language needs to prove that it will be worth the investment. Many of the features you mentioned are not available for the .net core version. The .net core version is not a standard install on client servers (it is not shipping with RHEL/CENTOS) and is still very recent. Having supported dozens of Java apps through the early versions, the last thing I want to do is spend my time discovering esoteric runtime / os library version conflicts. So yes, the language needs to prove itself that as a platform for delivering Linux / Mac server apps that it is as boring and reliable as the rest of the stack.
- mikekchar 10y agoIt's been about 10 years since I used C#, but even in it's nascent form I enjoyed programming in it. Also dev studio for C# is the only IDE that I've ever enjoyed using (for C++, not so much ;-) ). But the OP did specify for non-Window OSes and for Open Source. And I don't think they meant that the language itself had to prove itself, I think they meant that it needs to prove that it can inspire programmers in those other cultures. That's quite a reasonable statement IMHO. MS stumbled out of the gate with this. They made a reference implementation, but used their crazy shared source license for it. The Mono/Gnome guys had a huge love affair with MS (to the point of trying to make their own implementations of Com objects and the registry (!)). MS was vague about their feeling about Mono for far too long. Even now, my understanding is that Mono is very careful not to tread on any toes when re-implementing things that are in .Net. And I'm probably one of the few people who used the open source .Net library (whose name I forget now... Mobile.Net... or something) and was constantly cursing that MS made it difficult for code to run on both that platform and a full blown windows .Net platform. If you want to write proprietary code on Windows? Absolutely C# and .Net all the way (or, these days F# is looking very nice). But open source on a Posix box? Not touching it with a ten foot pole. I've got lots of better options.
- rektide 10y agothree GUI libraries is basically my view of C#. MS kept designing APIs and kept throwing more things at the platform, hoping for something to stick. The result felt like a massively over-inflated platform with all manners of solutions no one else uses. I was around when MS was inventing a new take on ASP.NET twice a year (MVC, Razor, &c). I'm still super not a fan of the base runat='*' GWT imitation, and would easily suggest Apache Tapestry as a far more consistent and usable set of tech for people wanting seamless server-powered webapps that also does Ajax far more cleanly. At the time I was using Jayrock to eskew the rest of the platform & do some basic RESTful JSON services, which seemed very low on the priority list in favor of the mixed GWT-alike full interface building in C#, with deep ViewState magic, and I'm still not sure where if at all C# and ASP.NET's sweet spots are when you want to do your front end in JS. There's a lot of table stakes you've mentioned, and my experience is very historical, but what it felt like watching it happen at the time was that a lot of the platform was an attempt to clone other existing technologies, while not rebuffing older MS users, resulting in constant compromise and shifts as the previous stance proved insufficient and in need of amendment. You've listed some very nice, well implemented technical things the platform has (that a lot of other people have versions of), but what is most impactful for a language is it's standard library, is the platform of APIs it offers, and while the core C# language and structures are pretty good, there's a huge amount of historical baggage one has to wade through to understand what platform APIs are good and useful and in use and which ones one is better off avoiding. It's been a long time since I was in this world, so perhaps some of the newest ones have finally gotten everything right, but the base model- especially for webdev- felt grotesquely off in every permutation, already doomed by desire to keep dragging yesterdays coders and backwards compatibility forward as it tried to make an ok future.