Да, вы правы, сейчас это так. Хотел скорее написать, что на становление Erlang сильно оказала влияние теория Хоаровского CSP, и практическая реализация Smalltalk и Prolog.
> абстрагировать бизнес логику от инфраструктурного слоя.
Так как мы работу с базой делаем сразу отдельным слоем (что-то вроде паттерна repository, но без фанатизма), то необходимости в ORM не возникает. Собственно, из-за того, что gopg чуть переусложнена, не хочется её использова. Ну и опыта с pgx просто больше)
Спасибо! Вы правы, в данном случае экранирование делает сам драйвер. Я надеюсь найти время, закоммитить в pgx передачу параметров в бинарном виде. Но, кстати, этот протокол не стандартизирован и может быть изменен в следующих версиях постгреса. Впрочем, это не так страшно, так как переезд на новую версию дело долгое и можно будет подготовить драйвер к этому.
Как преимущество, с simple query меньше запросов в сеть и ниже latency)
Я воспринимаю пул как ведро) Мы в него кладём соединения если их не используем и забираем оттуда, когда нужно заиспользовать. Но когда в ведре нет соединений — приходится устанавливать новое соединение с базой.
Кроме примера из треда, могу еще вот такой PR показать https://github.com/lib/pq/pull/714. О том, что библиотека заброшена пишут даже люди имеющие статус Collaborator.
Основными людьми, поддерживающими жизнь в библиотеке остаются ребята из cockroachdb. Но, например mjibsonпишет
It is indeed sad this has no active maintainers. Open source has its problems.
I don't have permissions to grant permissions so I'm not able to do anything. A few of us from cockroach just asked the last time this was a problem and they gave us commit here. We just keep limping along.
Мне кажется, правильным решением будет пометить библиотеку как deprecated, заархивировать проект и забыть о нём. pgx давно обогнал. А с 4 версии станет совсем хорошо)
Аудитория у gorm, действительно, большая. Я это объясняю только тем, что люди переходя с других языков тащат за собой практику использовать orm.
Но, по разным причинам, в Go чуть меньше распространены orm.
А в целом, у постгри много функциональности, которая слабо покрывается orm'ками: мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по json (а в 12 версию закоммитили jsonpath www.postgresql.org/docs/12/datatype-json.html#DATATYPE-JSONPATH) и большое кол-во других вещей, которые делают использование orm неразумным.
orm-холивар предлагаю не разводить. Отличный вопрос, мне понравился, спасибо!)
Зависимости для сборки держать на хост машине не удобно. Процесс билда при использовании CI становится прозрачнее, на агентах достаточно иметь только Docker. Имхо, правильнее, собирать проект в том окружении, в котором он будет запускаться.
Думаю, что сейчас никаких поддержек для новой фичи в docker-compose нет, просто потому что еще даже в самом Docker не зарелизили.
Правда, есть практика использовать по одному Dockerfile на сервис. Поэтому, если есть общая часть какая-то, то может стоит вынести её в родительский image?
Вполне рабочий вариант! Многие так делают. При таком подходе обычно уменьшают размер финального образа вызывая `apt-get clean` после установки зависимостей.
Robert Virding (один из отцов Erlang) про это написал так: "Actually we had never heard of the actor model, not before ppl told us we had implemented it" (https://twitter.com/rvirding/status/766242280592277504)
Более подробное обсуждение можно вот тут почитать: elixirforum.com/t/does-earlier-erlang-concurrency-model-stem-from-csp/16905
Спасибо за ваше замечание, я поправлю текст!)
Так как мы работу с базой делаем сразу отдельным слоем (что-то вроде паттерна repository, но без фанатизма), то необходимости в ORM не возникает. Собственно, из-за того, что gopg чуть переусложнена, не хочется её использова. Ну и опыта с pgx просто больше)
Как преимущество, с simple query меньше запросов в сеть и ниже latency)
В issue глянул — с ходу не нашел. Возможно еще не осознали, что пора.
Спасибо вам)
Кроме примера из треда, могу еще вот такой PR показать https://github.com/lib/pq/pull/714. О том, что библиотека заброшена пишут даже люди имеющие статус Collaborator.
Основными людьми, поддерживающими жизнь в библиотеке остаются ребята из cockroachdb. Но, например mjibson пишет
Мне кажется, правильным решением будет пометить библиотеку как deprecated, заархивировать проект и забыть о нём. pgx давно обогнал. А с 4 версии станет совсем хорошо)
Но, по разным причинам, в Go чуть меньше распространены orm.
А в целом, у постгри много функциональности, которая слабо покрывается orm'ками: мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по json (а в 12 версию закоммитили jsonpath www.postgresql.org/docs/12/datatype-json.html#DATATYPE-JSONPATH) и большое кол-во других вещей, которые делают использование orm неразумным.
orm-холивар предлагаю не разводить. Отличный вопрос, мне понравился, спасибо!)
hackernoon.com/why-senior-devs-write-dumb-code-and-how-to-spot-a-junior-from-a-mile-away-27fa263b101a
Правда, есть практика использовать по одному Dockerfile на сервис. Поэтому, если есть общая часть какая-то, то может стоит вынести её в родительский image?
Best practice и при использовании новой фичи остаются актуальны: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/