Thread by @Nick_Craver

Been asked several times this week about "right tool for the right job". Do I believe in it? Absolutely.

I help maintain Dapper, the most popular third party ORM in .NET, yet I'm contributing to EF Core at the moment. The goal is helping developers; both tools do that.

Some people like raw SQL, ultimate flexibility, and things generated SQL can't sanely do. We do. We built Dapper around it.

Some people like easier development and data models, EF Core is for them.

These aren't distinct groups. We're about to be using *both* at Stack Overflow.

When someone asks about inserting object graphs which have rows across several tables and want to do it all raw...it sounds great, **if it stays simple**. When it gets complex: you're basically then building a data context. We would be. But why? EF Core exists. We'll use it.

We do certain things for performance for Stack Overflow. Most things are not at that scale. While I believe performance always matters and it's super important to *us*, it's a lower priority for others. And that's okay!

Make the tradeoffs that are best for you, not someone else.

If code simplicity, portability between database providers, or just staying away from SQL are worth more than performance: I'd absolutely recommend EF Core over Dapper.

I'm still working on our port over here, but we'll let you know how it works at scale too. Tweets as we go!

I also want to say: when you can simplify: simplify. We had to do things for performance in #AspNet (non-Core) like writing our own localization. Replacing the compiler. Replacing the Razor view engine.

These choices weren't awesome, but were necessary. Now, with .NET Core...

We're meeting with some Microsoft teams and hoping to improve the landscape for all. We'd much rather our approaches be pluggable so we can address issues for everyone and simplify our setup at the same time. It's win-win for everybody.

Luckily, .NET Core has a ton of this already done. It's already immensely more friendly and we can drop a lot of customization. That's a HUGE maintenance win for us.

The reason we never open-sourced our MoonSpeak localization was: the build pipeline is too complicated.

Now, @m0sa is looking at how we drop everything into Analyzers and MSBuild (looks incredibly promising and we may be able to do it with .NET Core as it is today). The optimizations we do at build-time aren't needed due to how fast the #AspNetCore team made Razor compilation.

@m0sa Anyway, our move to .NET Core isn't "move the code". It's about simplifying everything along the way as well to take advantage of the hundreds of wins the new platform has.

Guess I (or hopefully we) have a lot of blogging to do as we go. I'll try to make sure we find the time.