Комментарии 10
— Главный «объективный» довод: код на Go показался мне на много более читабельным.
— Главный субъективный довод: я захостил всё это не VDS-ке за $10 в год. Там не очень много места. Гошный бинарь можно собрать где угодно, а туда просто положить. И всё — никакие зависимости больше не нужны.
Но нода тоже очень и очень не плоха! Если интересует, вот вариант примерно того же самого, но на ноде github.com/michurin/instant-bot Развивать его я пока не планирую, но любой желающий может форкнуть это добро и делать с ним что угодно.
Я смотрел в сторону фреймоворков и что-то не стал с ними связываться по нескольким причинам
- Последний раз я смотрел где-то в 2017 году, и тогда всё, что я видел, показалось мне каким-то не зрелым (возможно, сейчас это уже не так)
- В данной случае, я использую, наверно процентов 3-5 от всех возможностей API. Тащить для этого какой-то фреймворк?.. см. следующий пункт
- Так как реально я использую только часть функциональности только двух методов (getUpdate и sendMessage (ну ладно, и чуть-чуть sendPhoto :-))), заимплементить самому API — тривиальная задача.
Так и получилось, что я не использую фреймворки. Как видите, это связано со спецификой задачи. В других условиях фреймворки были бы вполне уместны.
Хотя… одна из ценностей Go: не прятать вещи за слишком развесистыми абстракциями (not hiding things behind too much abstraction). API телеграма на столько простое, что я не очень понимаю, надо ли вообще строить для него какой-то фреймворк. Но тут уж как кто любит :-)
отслеживания прогресса (графики)
Можете показать примеры?
Спрашивали — отвечаем https://yadi.sk/i/G0pO9FhoK4zO1g Но там нормальному человеку ничего не понять. Это вес за 1000 дней с поездки на самокате за 1000 дней. Да, спором я занимаюсь не очень регулярно )
Список тупиковых идей, которые выглядят хорошо, но на деле мало полезны.
Вот конкретно это было бы полезным и интересным.
Тут можно посмотреть прошлые поделья на JS и Python. Основные проблемы: (1) сложный контракт, (2) преусложнения типа возможностей пробросить или зафорсить переменные окружения. Так же кучка технических проблем. Главные: (1) нет гарантий, что одновременно бежит только один скрипт, это создаёт и риск гонок и риск ДДОСа и (2) текущая версия запускает процесс в группе и по таймауту убивает не только его, но и всех его потомков, старые версии могли оставлять грязь, что тоже приводило к возможностям ДДОСа.
Про переменные окружения могу сказать отдельно. Сейчас скрипту передаются только те переменные, которые выставил сам движок. Кажется, что это слишком жёстко. Но на самом деле, это позволяет избежать кучи плохоотлавливаемых проблем, связанных с тем что в "тесте" и в "проде" разные переменные окружения. Нужен тебе определённый LANG или PATH или LD_PRELOAD — напиши явно.
Как превратить любой скрипт в Telegram-бота