причем ,уже лучше сразу брать версию 2.0, хоть она еще и  alpha2 пока что

👍🏻 спасибо

о прикольно, он и honeysql решил переписать чтоли?

ага

он уже давно говорил

главное, что уже переписал

ну, какая-то функциональность для этого есть и в hugsql, но тут уже предметно сравнивать надо.
скажем так, если бы у меня были запросы с произвольным количеством предикатов или критериев сортировки(пользовательский ввод), я бы взял сразу honeysql.
если нет - вероятно, hugsql.

Нем могу понять профит в hugsql, такое ощущение что как-то запутанно выглядит. А в honeysql, все понятно из коробки)

Да сортировка и фильтрация будет применяться часто

был у меня например сервис на 5 таблиц, две вью,  2-3 ручки в апи на чтение и один etl на загрузку.
написан на эрланге в стиле абсолютно hugsql - sql завернутый в функции.
просто писался, просто поддерживался, всё максимально тупо.

Понял

Автокомплиты чистого sql лучше, если с запросом проблемы ты сразу видишь запрос, а не дсл с которого он будет сгенерен, если работать на bleeding edge, то скорость обновления библиотек хромает по сравнению с чистым sql

Ну и мой любимый пункт – с hugsql просто неудобно размазывать слой работы с базой, все запросы агрегированы в паре файлов, а с любым дсл/орм – никто не запрещает размазывать запросы по всей код базе ещё и собирать запросы из разных файлов налету

Другими словами четкое разделение на слои приложения

Кто-то предпочитает писать SQL как SQL, а не генерить непонятно из чего. Вот для них и профит.
Видишь запрос в логах приложения или сервера, идёшь в код приложения и находишь его.
Ну и когда проектируешь, отлаживаешь запрос отдельно в консоли сервера базы данных, потом пихаешь в приложение.
Так же всегда можно взять запрос из кода и выполнить его в базе любым доступным способом.
Ну и написать можно запрос, используя все фичи сервера, а не только то, что заложено в dsl.
Ну в общем вы понели 😊

я люблю агрегировать запросы в одной папочке, по одному файлу на запрос 😊

Пример, у меня CRM, на экране  таблица с заказами, в которой много различных фильтров, и эти фильтры клиенты используют в различных комбинациях. Таблица заказов подтягивает данные из 10-ка других таблиц. Что реально эту задачку решить через Hugsql? Или вообще другой инструмент использовать для этого?

Да это удобнее, согласен

ну это как бы вопрос, реально ли написать такой запрос 😊
всё реально
думаю даже статичный запрос можно написать, который будет не учитывать в фильтре незаданные поля фильтра

а по обычному там эти условные фрагменты кода, что становится уже не так красиво