ORM are one of those kind of libs where very few ones are great. Python has lots of them, and only SQLAlchemy can be considered of high quality. Not that Djan

ORM are one of those kind of libs where very few ones are great. Python has lots of them, and only SQLAlchemy can be considered of high quality. Not that Django's ORM, peewee or eloquent don't get the job done. But they only cover 80% of the use cases. SQLA gets you to 95%, and you bridge the five remaining percents with raw sql injected in the proper places for those rare projects where the extra is important. The cost of it is that it's a harder to use ORM, and a more verbose one. Which is why I generally use https://github.com/absent1706/sqlalchemy-mixins https://github.com/absent1706/sqlalchemy-mixins to make things easier. What's more, ORM for languages like c++ or Rust have it extra hard as they are used from a low level tech while SQL is quite high level and easy to manipulate. It's hence attractive to use it directly. If you use PHP, Ruby or Python, SQL doesn't seem that big of a gain anymore for the simple operations. Now diesel is quite young, and the rust ecosystem has proven to be moving not only fast, but generally in a sane direction, so I wouldn't count it out just yet. However, I've yet to find an even acceptable JS ORM. Not only do they fail to provide any decent operation beyond simple ones, but they have such poor introspection capabilities that they can't be used to create an ecosystem around them. Which is, after all, __the main point of an ORM__. Avoiding to write SQL is definitively NOT the most important feature of an ORM. The critical one is having a common API you can build upon to create form generators, auth systems, data validation units, serializers, automatic UI, etc. Without this, the case for using an ORM is way weaker.