Евгений Попов

Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

Если тебе приходится при работе с ORM писать куски SQL-я (например для WHERE), передавать названия колонок в параметрах, и при этом ты не можешь использовать специфику твоей базы не опускаясь до уровня сырого SQL, то это плохая ORM.

Нормальная орм-ка должна упрощать код и при этом не увеличивать пространство для ошибок.
На сколько я знаю, Go не позволяет хорошую ORM-ку создать чисто из-за своего синтаксиса и системы типов.

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.

В далеком прошлом, я занимался пустой тратой времени. А именно - выбором языков программирования.

И продолжаешь этим заниматься.