3 ms·

This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternative

This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternatives: DHTML, PHP, Python, RoR, NodeJs And the language and framework has been thoughtfully improved over that period of time. > Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. Developers have been writing great software with these tools for decades. And rapidly-released libs could just as easily be classified as "not-yet-ready-for-production." > I think the big problem is that MS In my estimation, the biggest problem is that using .NET "requires" the rest of MS along for the ride. Yes you can use mono, yes you can use apache, but everything just works if you use the WINS stack. I like .NET and I really like C# as a language, but I'd rather have my infrastructure be linux. [1] Not all of these have "declined", but popularity has shifted focus.

Pxtl 13y ago
I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.
- deleted 13y ago
  [deleted]
- louthy 13y ago
  > But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. This is definitely changing with NuGet: Immutable collections, OWIN, SignalR, etc.
- avenger123 13y ago
  Totally agree with these iterations of libraries. The latest craziness is their authentication story for ASP.NET. Their new libraries try to fix old design flaws but at the same time leave out functionality from the original membership, role, etc. providers. So for now, their libraries work if you're building a play website but need a lot of know how and customization for a real web application. It's frankly reckless. For someone new starting on the stack, there is at least three different API's for this and they are all supported. It becomes a cat and mouse game of following employee blogs, official blogs and official documentation (which stays at a "hello world" level) to fully understand what the gaps are. I've decided for my own side projects to start using Django and Postgres. I can be pretty much be confident that two years from now whatever version python, Django and Postgres are, my gained experience and knowledge will still be very relevant as the maintainers of these projects don't have a mandate of building a brand new API, or what have you every year.

Pxtl 13y ago

I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.

deleted 13y ago
[deleted]
louthy 13y ago
> But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. This is definitely changing with NuGet: Immutable collections, OWIN, SignalR, etc.
avenger123 13y ago
Totally agree with these iterations of libraries. The latest craziness is their authentication story for ASP.NET. Their new libraries try to fix old design flaws but at the same time leave out functionality from the original membership, role, etc. providers. So for now, their libraries work if you're building a play website but need a lot of know how and customization for a real web application. It's frankly reckless. For someone new starting on the stack, there is at least three different API's for this and they are all supported. It becomes a cat and mouse game of following employee blogs, official blogs and official documentation (which stays at a "hello world" level) to fully understand what the gaps are. I've decided for my own side projects to start using Django and Postgres. I can be pretty much be confident that two years from now whatever version python, Django and Postgres are, my gained experience and knowledge will still be very relevant as the maintainers of these projects don't have a mandate of building a brand new API, or what have you every year.