5 ms·

For large enterprises, that use AWS / GCE / Azure, these improvements directly translate into huge savings in server capacity. I have always loved .NET and it

For large enterprises, that use AWS / GCE / Azure, these improvements directly translate into huge savings in server capacity. I have always loved .NET and it keeps getting better and better. They have shown remarkable flexibility to throw away ideas that don't work and have modernized. A large part of that is due to active involvement of the community. This could be a new model moving forwards, a software worlds equivalent of "the customer is always right".

3np 5y ago
I’m thorn on that. As someone who has had intermittent periods of .NET, it’s a complete mess every time I’ve come back after a couple of years off and figuring out what new APIs are the new thing to use, which have been deprecated and when looking for a solution of something involving e.g. configuring stuff in the web server request handing stack it’s a real confusing mess. Docs of course aren’t all up to date and are some times contradictory. Maybe it's better today but I've had plenty of 404s on official docs as well. It’s way worse than React in this regard (if not only by its sheer size and larger scope) The rapid changing allows them to do good stuff like you say, but it’s like the only way to write modern .NET properly is to have throughly read every release notes since about v4....
- eitland 5y ago
  > It’s way worse than React in this regard (if not only by its sheer size and larger scope) FWIW, I've used React for 18 months now. Except Java and classic core PHP it is one of the most stable platforms I've developed on. So, in my view being less stable than React isn't a big problem.
  - 3np 5y ago
    Yeah, I'm talking about having used React extensively since its inception 8 years ago with a couple of 1-3 years periods of being out of that ecosystem and coming back again. I'm sure it's a completely different game these days. Especially I recall that with lifecycle methods, previously idiomatic patterns would be deprecated with stern runtime warning within a year. Like this: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin... Granted React team has been way more effective at communicating than the .NET team, again facilitated by a much smaller scope. As for the ecosystem: Anyone else remembers when react-saga was The One Way To Manage Effects? Or going through all the major versions of react-router?
  - kqr 5y ago
    I agree, React itself can be remarkably stable because they found the right abstractions early on and have been able to evolve just small variations of those central patterns over time. All the stuff people expect to use around react, on the other hand. That sees huge amounts of churn.
    - eitland 5y ago
      Luckily, if you can get everyone to accept it you can often manage just fine without. I'm lucky to be on a team that agreed that redux etc wasn't necessary somewhere before I arrived, and coming from other places that insisted on latest fads it has been blissful.
  - girvo 5y ago
    React itself is incredibly stable, for sure, but its third party dependencies (core libraries most use) are a little less so
    - eitland 5y ago
      For what it is worth this is one thing the team I work on did before I arrived there and that I now tell new team members: we actively avoid dependencies, especially redux. React actually works fantastic without if you do it correctly and we rarley have any hard debugging problems that get my head to feel it will explode. I had one big debugging job during the last few months and that quickly turned out to be on the backend.
- GiorgioG 5y ago
  Major version releases have breaking changes. I don't see the issue. I've been doing .NET development since the original version was in beta (20 years now?) For the most part I have no complaints about the docs - and hey you're free to submit a PR against the docs if you want to contribute, have at it: https://github.com/dotnet/AspNetCore.Docs https://github.com/dotnet/AspNetCore.Docs
- ripley12 5y ago
  There has been more churn than usual during+following the .NET Framework -> .NET Core migration. Some of it was necessary due to the migration, some of it is making up for lost time after being tied to Windows (and very constrained in their ability to make changes) for so long. I understand your pain but I think most of the recent changes are necessary for the long-term health of the ecosystem, and I would not expect the breakneck pace of the last 5 years to continue forever.
- robertwt7 5y ago
  Worse than react? I honestly never complained about react at all. It's great, the community, the docs, the way they release new features. Not sure what's bad for you
- addicted 5y ago
  I think the transition from .NET Framework to .NET Core was inherently difficult, but was made worse by poor naming strategies and extremely poor communications. But now that MS is largely over that hump, I think they’ve been doing a really good job.
oaiey 5y ago
They still have problems with listening. It got much better but they often do not hear or understand when it does not fit into the world picture of their product managers. This is human (and in that level not bad or malicious) but they are a bit too proud for it.
- pjmlp 5y ago
  I can vouch for it, given my failed attempts that IDL gets first class development experience given COM, UWP and C++/WinRT. It is up for the community to provide syntax highlighting for a 30 year old language.
  - ripley12 5y ago
    That’s on the Windows team, not the .NET team.
    - pjmlp 5y ago
      Except .NET and Windows belong to same package and some APIs are only available in .NET as COM wrappers.
      - oaiey 5y ago
        The languages are all owned by Scott Hunter. Including e.g their Java support etc. The windows sdk not. Where exactly the language projections are, no idea. IDL and COM however sounds indeed more like Windows team and not language and runtimes team.
        pjmlp 5y ago
        Yeah, classical Microsoft where externals have easier time talking across divisions than internal employees, only interested on their own silos. I know of cases where externals where tasked with fetching information due to that culture.

3np 5y ago

I’m thorn on that. As someone who has had intermittent periods of .NET, it’s a complete mess every time I’ve come back after a couple of years off and figuring out what new APIs are the new thing to use, which have been deprecated and when looking for a solution of something involving e.g. configuring stuff in the web server request handing stack it’s a real confusing mess. Docs of course aren’t all up to date and are some times contradictory. Maybe it's better today but I've had plenty of 404s on official docs as well. It’s way worse than React in this regard (if not only by its sheer size and larger scope) The rapid changing allows them to do good stuff like you say, but it’s like the only way to write modern .NET properly is to have throughly read every release notes since about v4....

eitland 5y ago
> It’s way worse than React in this regard (if not only by its sheer size and larger scope) FWIW, I've used React for 18 months now. Except Java and classic core PHP it is one of the most stable platforms I've developed on. So, in my view being less stable than React isn't a big problem.
- 3np 5y ago
  Yeah, I'm talking about having used React extensively since its inception 8 years ago with a couple of 1-3 years periods of being out of that ecosystem and coming back again. I'm sure it's a completely different game these days. Especially I recall that with lifecycle methods, previously idiomatic patterns would be deprecated with stern runtime warning within a year. Like this: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin... Granted React team has been way more effective at communicating than the .NET team, again facilitated by a much smaller scope. As for the ecosystem: Anyone else remembers when react-saga was The One Way To Manage Effects? Or going through all the major versions of react-router?
- kqr 5y ago
  I agree, React itself can be remarkably stable because they found the right abstractions early on and have been able to evolve just small variations of those central patterns over time. All the stuff people expect to use around react, on the other hand. That sees huge amounts of churn.
  - eitland 5y ago
    Luckily, if you can get everyone to accept it you can often manage just fine without. I'm lucky to be on a team that agreed that redux etc wasn't necessary somewhere before I arrived, and coming from other places that insisted on latest fads it has been blissful.
- girvo 5y ago
  React itself is incredibly stable, for sure, but its third party dependencies (core libraries most use) are a little less so
  - eitland 5y ago
    For what it is worth this is one thing the team I work on did before I arrived there and that I now tell new team members: we actively avoid dependencies, especially redux. React actually works fantastic without if you do it correctly and we rarley have any hard debugging problems that get my head to feel it will explode. I had one big debugging job during the last few months and that quickly turned out to be on the backend.
GiorgioG 5y ago
Major version releases have breaking changes. I don't see the issue. I've been doing .NET development since the original version was in beta (20 years now?) For the most part I have no complaints about the docs - and hey you're free to submit a PR against the docs if you want to contribute, have at it: https://github.com/dotnet/AspNetCore.Docs https://github.com/dotnet/AspNetCore.Docs
ripley12 5y ago
There has been more churn than usual during+following the .NET Framework -> .NET Core migration. Some of it was necessary due to the migration, some of it is making up for lost time after being tied to Windows (and very constrained in their ability to make changes) for so long. I understand your pain but I think most of the recent changes are necessary for the long-term health of the ecosystem, and I would not expect the breakneck pace of the last 5 years to continue forever.
robertwt7 5y ago
Worse than react? I honestly never complained about react at all. It's great, the community, the docs, the way they release new features. Not sure what's bad for you
addicted 5y ago
I think the transition from .NET Framework to .NET Core was inherently difficult, but was made worse by poor naming strategies and extremely poor communications. But now that MS is largely over that hump, I think they’ve been doing a really good job.

oaiey 5y ago

They still have problems with listening. It got much better but they often do not hear or understand when it does not fit into the world picture of their product managers. This is human (and in that level not bad or malicious) but they are a bit too proud for it.

pjmlp 5y ago
I can vouch for it, given my failed attempts that IDL gets first class development experience given COM, UWP and C++/WinRT. It is up for the community to provide syntax highlighting for a 30 year old language.
- ripley12 5y ago
  That’s on the Windows team, not the .NET team.
  - pjmlp 5y ago
    Except .NET and Windows belong to same package and some APIs are only available in .NET as COM wrappers.
    - oaiey 5y ago
      The languages are all owned by Scott Hunter. Including e.g their Java support etc. The windows sdk not. Where exactly the language projections are, no idea. IDL and COM however sounds indeed more like Windows team and not language and runtimes team.
      - pjmlp 5y ago
        Yeah, classical Microsoft where externals have easier time talking across divisions than internal employees, only interested on their own silos. I know of cases where externals where tasked with fetching information due to that culture.