[extrememacaroni]

I like how everyone here and the repo’s readme talks about performance as if the problem with Automapper was the fact that it was making your enterprise app that waits N seconds for a db query and relies on caching to be even remotely usable, slow.

The problem with automapper is that it throws the compiler out the window and invites all the bugs that would normally not be there.

Mapping code is still your code and should receive the same care as your fancy services.

I hate automapper, and I hate this too, just less because at least it has the potential to catch bugs at compile time… I think.

Some people really want to write libraries, I guess.

[mpawelski]

> The problem with automapper is that it throws the compiler out the window and invites all the bugs that would normally not be there.

I've seen projects when Automapper was the main reason for the cold startup of an app, which caused terribly slow "write->build->run" developer experience.

So it's not only a problem of runtime exception vs compiler errors. Performance also matters.

> Mapping code is still your code and should receive the same care as your fancy services.

I've also seen project where all mapping code was written by hand and it was required to write unit test for it. It was also not pleasant.

[extrememacaroni]

Yes, trade code safety & quality for programmer comfort. Amateur mindset, much like the mindset behind automapper.

“Yeah we may risk introducing more bugs but it’s so much nicer to develop now!”

[tryfinally]

Performance is a feature. For certain use cases, it’s a top priority. It’s OK to let users know that your library is designed with performance in mind.

It’s also OK to write libraries.

Some people really want to write mean comments, I guess.

[extrememacaroni]

oh yes, I will forever be mean to automapping libraries