По-настоящему живая перезагрузка кода в golang

[handicraftsman]

Милота. Не хватает разве что возвращения многомерных массивов SQL-запросами.

[andboson]

Хот релоад без костылей в коде:
https://github.com/tockins/realize

к примеру
Есть и другие.

[youROCK]

С остальными подходами есть один нюанс: они все требуют перезапуска приложения. Мой подход работает без перезапуска

[andboson]

Я уважаю ваш труд. Но вы же не пишете без ошибок? Паники — ваши постоянные друзья будут. Т.е. просто вручную придется запускать опять )

[youROCK]

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

[datacompboy]

В свое время я так же создал живое обновление кода для Перла, в связи с чем открыл для себя erlang...

[miolini]

Не вижу кода, который выгружает предыдущую версию. Когда именно это происходит?

[youROCK]

Предыдущую версию выгрузить в go нельзя

[rustler2000]

Блин — а я так надеялся, что можно сделать gouchdb :S

[miolini]

Ну т.е. много раз такое не сделать, иначе ресурсы закончатся в системе. Процесс придется перезагружать.

[youROCK]

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

[equand]

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

Парент процесс будет держать соединение и отправлять его в новый форк, Старый форк соединения принимать не будет и будет по мере заканчивания очереди отрубаться чисто сам. Примерно так и работает mod_php mod_python и иные (только там фактически форк на каждый запущенный скрипт).

[youROCK]

Да можно, конечно, только весь смысл hot swap кода заключается в том, что полная перекомпиляция не требуется и соответственно время цикла сохранил-подождал_пока_скомпилится-проверил сокращается и благодаря этому ускоряется разработка и дебаг. Ваша же идея описывает "плавный рестарт" и нужна в продакшене, а во время разработки она ничего не ускоряет

[equand]

Я писал подобный Вашему релоадер на Python. Основная проблема с которой я столкнулся это не загрузка нового, а выгрузка старого — по-крайней мере с JIT Python это не работает верно. Дело в том, что GC там удаляет "когда посчитает нужным". В итоге нужно обходить все локали и удалять их, но появляется другая проблема — закрытие соединений и файлов. И вот так раз за разом идет куча ликов.
Помимо этого проблема с форсированной загрузкой из файла, а не из прекомпилированного кода тоже появляется. Помимо этого reload(module) работает неконсистентно, то есть его вообще надо не использовать, а нельзя, иначе импорт эррор.

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

[gobwas]

Как-то стремновато будет выглядеть monkey patching в production коде?

Как-то использовал эту прекрасную либу, но только для того, чтобы делать stub'ы в структурах, при использовании которых хотел избежать интерфейсов.

[youROCK]

В продакшен-коде такое использовать ни в коем случае нельзя

[seweb]

Люди, используйте go install вместо go build при разработке.

go install кэширует скомпилированные пакеты и сохраняет их в папке $GOPATH/pkg, то есть перекомпиляция будет происходить только при изменении отдельного пакета, а не всех, как это работает с go build.

Для веб-разработки, конечно, удобно использовать какой-то перезагрузчик, который следит за изменением файлов в проекте. Рекомендую использовать этот — https://github.com/cortesi/modd

Мой файл конфигурации modd:

**/*.twig.html {
    # gost это простой сервер для отдачи статических файлов: https://github.com/vwochnik/gost
    # можно использовать вместо него обычный python -m http.server
    daemon +sigterm: cd public && gost
}

**/*.go {
    # запускаем компиляцию приложения
    prep: go install ./cmd/webapp-main

    # запускаем приложение, полный путь к нему будет $GOBIN/webapp-main
    # где $GOBIN по-умолчанию $GOPATH/bin
    daemon +sigterm: webapp-main
}

Это не тоже самое, что написал автор поста, но при таком подходе не нужно описывать множество правил для патчинга функций.