nakem

разрешите за вас погуглить

https://github.com/gocolly/colly/blob/master/htmle...

func (h *HTMLElement) ChildTextgo(querySelector string) string

https://github.com/gocolly/colly/blob/master/htmle...

func (h *HTMLElement) ChildTexts(goquerySelector string) []string

https://stackoverflow.com/questions/61498687/how-t...

result := strings.Join(data, ",")
fmt.Println(result

How to build a web scraper with Go and Colly
https://divrhino.com/articles/build-webscraper-wit...

Building a web scraper in Go with Colly
https://blog.logrocket.com/building-web-scraper-go...

Точно так-же как и в обычном SQL. Создаешь новый changeset. Там создаешь таблицу pets.
Потом еще 2 ченжсета. Для INSERT AS SELECT dogs, и тоже самое для cats.

возвращать одно рандомное из дублей, но тогда есть вероятность вывода неправильного результата

а в чем неправильность такого результата?

В любом случае, группировка и джойн тут избыточны:

SELECT DISTINCT ON (project_id) *
  FROM tasks
 WHERE tasks.id = ANY (...)
 ORDER BY project_id, created

refresh_threshold_in_minutes_before_expiration

Более четырёх лет пишу на Go, лично для меня поддерживать проекты на других языках сложнее ))
До Go много лет писал на Perl/PHP/Python/Java/C/Ruby on rails/JavaScript и "крутил" еще не мало чего.
Сейчас пишу только на Go и Python.

Основная сложность в Go - это то, что если вы начинаете писать "криво" - то писать так очень трудно :))
Подход к реализации в Go достаточно непривычный для тех, кто приходит из скриптовых языков.
Например запрет циклических импортов - это самое первое, что "взрывает" мозг :)
Нужно время чтобы адаптироваться после скриптовых языков.

Про обработку ошибок - это да, это, пожалуй, единственное что мне не нравится в Go.
Для себя я решил эту проблему за 1-2 часа :) и больше меня это не беспокоит.

По ООП - в Go оно есть, лично мне оно нравится намного больше, чем ООП в других языках ))
Всё, что реально нужно - всё есть, но при этом ничего лишнего нет.
Интерфейсы - просто прекрасны :)) Каналы, горутины - это просто "счастье" :))

А если объективно - то я бы не стал говорить о сложности поддержки проекта применимо к какому то конкретному языку.

Как правило сложность поддержки возникает там, где нормальная архитектура не заложена в проект.
Т.е. проект как могла так и писала куча людей плюс, как обычно, сделать нужно было побыстрее )), от этого никто вообще не думал об архитектуре и получилось то, что получилось :))
Про покрытие тестами и документацию мы вообще не говорим )))

А когда в таком проекте нужно что-то доработать или исправить ошибку, то почти всегда очень не просто найти то место, где нужно править, и после правок в одном месте, как правило, что-то ломается в другом :)

Как минимум, нужно соблюдать принципы SOLID, иначе код получается, мягко говоря, не поддерживаемым.
Но понимание этих принципов так же приходит с опытом, их нельзя научиться соблюдать просто прочитавши книгу или статью. Нужно сделать несколько проектов используя эти принципы, написать криво, понять как было бы правильно, всё переделать и так несколько раз.
Тогда, со временем, начнёт получаться понятный и легко поддерживаемый код.

Так мы приходим к тому, что если опыта нет - тогда проект поддерживать будет достаточно тяжело не взирая на язык и т.д.

Хочется добавить, что как бы не писали про Go, что он простой и т.д. - он явно сложнее Python/PHP и т.д.
Это еще один повод сказать, что поддерживать код на Go сложно ))

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

"Long polling" периодически опрашивает телеграм сервер, за счёт этого пользователю будет казаться, что бот "торзмозит", т.к. между отправкой сообщения от пользователя и до получения ответа будут паузы.
По крайней мере у меня было именно так.
Еще стоит сказать о том, что "Long polling" не подойдёт если говорить о нагрузках.

После перехода на WebHook'и - сразу заработало всё очень резво.
Также с использованием WebHook'ов у вас будет возможность горизонтально масштабировать бота в случае роста нагрузок.
Если бы у меня стояла такая задача - я бы использовал WebHook'и.

В таких случаях лучше передавать структуру как параметр.
Пример

type User struct {
    Name string
    Email string
    // все нужные поля далее
}

func CreateUser(r.Context(), user)