While I do agree you in general, I believe the comparison is valid in this case.
The history of our product is like this.
The MVP was about 80% done in Laravel around the time I joined the company.
I joined the company as a symfony developer who was supposed to migrate the MVP to using symfony because "enterprise" and yadda yadda yadda as desired by our CEO.
We were successful in migrating to symfony 2 after about 2 months of work. From there, the system evolved over a few months going through multiple chaotic pivots.
While the product worked, we had taken on a non-trivial amount of technical debt due to the rapid pace of evolution and numerous pivots.
As we were about to move to the next phase in our development, I spoke with our CEO about the technical debt we had incurred and possible ways in which we could shed it.
Being a technical guy, he understood where I was coming from and allowed us a month to clean things up.
The plan was to migrate to symfony3 while cleaning up the mess we had created.
However, while were working on the update, we started experiencing some of the same pain points we had before including performance issues, composer memory issues, poor library availability, late or no feedback on github issues etc...
Since I had done a project using the rc1 bits of asp.net core and updated the application to rc2 bits after and had a good experience I suggested that we gave it a try.
The performance and dependency management issues went away. Development speed also improved as we had better tools to work with.
I spearheaded the move from php(symfony) to .NET Core at the startup where I work.
We have had a pleasant experience so far. Performance is better across the board. Development is as fast or even faster in most cases. Deployment has also been simplified.
We started the port of our code base around October last year and released the update to our product at the end of December.
During that time frame, we migrated from 1.0 to 1.1.
We are using some awesome libraries from the community and a few small ones we wrote internally.
Libraries include:
openiddict (for openid connect and oauth 2.0)
rawrabbit (simple rabbitmq library)
entity framework core with npgsql
mailkit for smtp email sending
We wrote these library wrappers around third party services because they did not exist in a stable form:
twilio wrapper
nexmo wrapper
gcm wrapper (now fcm wrapper)
bitgo wrapper (hosted bitcoin wallet provider)
blocker wrapper (blockchain explorer)
openexchangerates wrapper
api layer wrapper (mobile number verifications)
ip-api wrapper
among others.
A service monitor for monitoring availability of third party services
We have also a spin off from our main product where we are using an private blockchain-like solution(openchain) for a niche market.
We have been very pleased with the overall experience using .NET core so far and we are looking forward to moving to 1.2.0 as soon as it is out.
The only real issue we've had is that the new signalr library does not have a stable release though we are using it in production.
We've had to isolate it into a separate project but because of compatibility issues with 1.1 libs. Can't complain about hat though as we knew it is an unreleased pre-beta level library.
To manage the risk of using it, we try to follow the development closely and prepare in advance for any changes we can see coming.
I've recently updated a project from RC1 to RC2. It was fairly easy. I don't know about compatibility with "legacy" full .NET class libraries as I do not have such requirements.
I prefer the new tooling. Overall, things seem much more stable. The ecosystem of 3rd party libraries seems like it will be healthy in a few months for most commonly used things.