I think your post makes a lot of assumptions. I do not believe scale to be a reason not to use an ORM. If you pay attention to what you're doing you can scale a system that uses an ORM just fine.

The orm is usually not the problem, it's usually that people don't know what they are doing and introduce serious performance issues.

My db issues for last ten years have frequently been a mix of bad query plans and terrible orm layers. Doctrine in Symfony rarely yield good queries in mysql for us. We've been moving away from orm where possible because we don't need to support multiple databases. Further if I switch my db to postgres I'm changing out everything else anyway to remove php from the codebase. I didn't write the original code but my team has to maintain it. The orm makes that hard actually compared to staight sql in the end.

As I understand it, the point of an ORM is to make relational data look and feel more like the objects in my program; I shouldn't have to think about the consequences of my data living on the other side of a network connection. Even if that isn't the official point, it's at least a widely-held misunderstanding. If you're going to write code that uses the ORM this way, you're going to have a bad time, but if you write your code intelligently, you end up using your ORM as a glorified query builder.

I think an ORM makes more sense in a functional language since the interfaces are more likely to be declarative than imperative. For example, an in-memory List and a SQLQuery can both implement a filter() method that takes a function and applies it in the way most efficient to that data structure; in traditional OO languages, we usually loop over our in-memory structures explicitly, and doing that with a database is prohibitive.

While I prefer vanilla SQL to the current generation of ORMs, I think ORMs are trying to address a real problem--namely that SQL (despite being high level) isn't very abstraction-friendly. Abstractions in SQL can be expensive and often unpredictably so, despite how clever databases are today. I think part of the problem is the mismatch between the largely imperative OO paradigm and the largely declarative relational paradigm, but I suspect that there's some semantic impedance between SQL and a truly relational model which contributes to the problem.

I advocate ORM use for guaranteed type-safety - so long as SQL queries are processed as strings inside your application there's always the risk of column names and types not matching your entity classes - by using an ORM that generates SQL based on your classes (e.g. Entity Framework with Linq) it promotes mismatches to compile-time errors. This alone makes it worthwhile.

How does an ORM know what your database schema is at compile time? Honest question.

You either generate a model based on your database, or generate your database from your model. That way the database and model are always in sync and you get errors in the code. In Entity Framework this is called either "Code first" or "Database first"

The reason for me to use ORM rather than direct SQL queries is so I can keep everything written in a single language, so I can develop with one IDE. Having everything under one roof is a huge boon to productivity, rather than having to edit the logic in the IDE, then edit the database queries in a different editor, and the two knowing nothing about each other. It lets me directly map my source language's type system to the database's schema, avoiding discrepancies.

Don't most IDE's do SQL in the mix with everything else or am I just spoiled by Visual Studio?

My opinion is that one uses an ORM for different situations than they would use SQL. Many applications can use an ORM and nothing else. Some can use an ORM for basic CRUD tasks and then raw SQL to do analysis or reporting.

you (and I) are absolutely spoiled by Visual Studio w/SSDT. there is nothing even remotely close to that level of integration for database development in other stacks.

Err... any of the JetBrains IDE's? They have database integration.

It's also available standalone as "DataGrip", though I've never used it:

https://www.jetbrains.com/datagrip/

the level of integration with SSDT is way beyond that - the database structure and stored procs live side-by-side with your code, are source controlled together, built and deployed together. there's compile-time checks for stored procedures, code analysis, etc. DataGrip is just an alternative for SQL Developer/Management Studio, SSDT is much more.

I can sympathize.

For me, that's Scala JVM on the server, ScalaTags/ScalaCSS/ScalaJS in the web browser, Slick for the ORM, and SBT for the build system. The bliss of learn once, program anywhere.

When this hits reality though, I use Relate https://github.com/lucidsoftware/relate (disclaimer: I'm a contributor)

It's SQL, but with minimal syntactic overhead.

    sql"SELECT * FROM users WHERE email IN ($emails)".asList[User]()

Since you're already using Slick, what's the difference between Relate and Slick's native SQL literals[1]?

[1]: http://slick.lightbend.com/doc/3.2.0/sql.html

Or Anorm [1] for that matter. They're all pretty similar in the idea of typed Scala string interpolation.

[1]: https://www.playframework.com/documentation/2.5.x/ScalaAnorm...