Сейчас я еще больше запутался, чем тогда это отличается от Go?
```go
func main() {
example_fn := func(x string) string { return x }
print(example_fn(«hello»))
example_fn2 := func(x int) int { return x }
print(example_fn2(10))
}
```
Как раз в первом варианте (тот что с callback), там выводится тип анонимной функции по первому использованию и после этого выведенный тип удовлетворяет сигнатуру функции **call**.
Можете кинуть ссылку на документацию по этому?
UPD: как раз в Go тип переменной вывелся из присваиваемого значения.
Тип анонимных функций определяется при первом использовании. Потому, если я все правильно понял.
Вот у вас функция: println!("{}", call(10, 10, |a, b| a + b));, а вот тут первое использование — c(a, b). a и b имеют тип i64, потому у этой анонимной функции будет тип Fn(i64, i64) -> i64, а не потому что в сигнатуре where F: Fn(i64, i64) -> i64.
let example_fn = |a| a;
println!("{}", example_fn(String::from("Yo"))) // вот тут уже будет тип Fn(String) -> String
let example_fn2 = |a| a;
println!("{}", example_fn(2)) // вот тут уже будет тип Fn(i64) -> i64
То есть вы мне предлагаете сделать что-то (как virtualenv или собрать python в бинарник) вместо того, чтобы ничего этого не делать и называете это преимуществом?
Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.
Тулзе А нужна 2.2 версия, а тулзе Б 3.1. Блин, надо virtualenv настраивать?
Потом pip или yum — чем мы там python зависимости ставим? А уже везде дефолтная версия python3? Ахх, тут на 100 серверах yum'ом установили, а на другой сотне pip'ом.
Блин, ansible yum модуль поставил библитеку libA-2.3.0 хотя я явно же написал поставить libA-1.9.0 (ох state: latest игнорит версию в названии пакет).
Блин, OS команда не дает нам root (не доверяют), а мне надо бы новую зависимость установить, опять virtualenv настраивать, а как же с C зависимостями?
И так далее.
Преимущество есть и оно большое (может быть конечно не "невообразимое").
Да нет, как раз вы добавляли условий, потому что вас не устраивали ответы и вы пытались подогнать все под свою позицию. При этом вы будете игнорировать безопасность, высокодоступность, чтобы только подогнать все под ваше решение.
А это уже зона ответственности PaaS-платформы, которой вы пользуетесь.
Я ее разрабатываю.
Но не все пользуются облачными платформами, не у всех 1 rps нагрузка и так далее. Вы тут подобрали специальные условия и представляете свое решение как единственно правильное учитывая только ваши условия.
Вы сейчас это серьезно?
Не надо сейчас придумывать, что там принято в Go.
Вот эта ваша самоуверенность удивляет — проблемы могут быть везде, начиная от железа, проблем сетью и до того, что админ или вы случайно кильнете ваш сервис. Но у вас «В дотнете риск существует только при обновлении.».
Магия, не иначе.
Тогда у нас есть момент, где сервер откидывает новые соединения, пока не перезагрузится. Это неприемлемо во многих ситуациях.
Он не откидывает новые соединения, он исключен из балансировки.
Если у вас только один инстанс (что случай только для балансера), то дейлайте как это сделано в nginx — старые процессы обрабатывают только текущие запросы, а все новые идут на новые.
Нет, это вы предлагаете ронять целое приложение просто чтобы обновить одно значение из конфига.
Если у вас HA, то нету никаких проблем тут. Та же стратегия во время деплоймента новой версии, только вместо релоада — рестарт.
Как предлагается рестартом сервера это решать, я не понимаю. Вот у нас есть 2 запроса, один — завершающийся старый со старыми параметрами, другой — новый с новыми.
Делать нужно graceful stop приложения (то есть не принимать новых коннектов, а только завершать старые), это должно быть уже у вас реализовано, а потом уже создавать новые коннекты, обьекты и тд — после этого принимать новые запросы.
Если у меня 1рпц, то почему бы и нет, если это облегчит подобные сценарии.
Вы только что сами придумали себе кучу проблем, вместо того чтобы просто релоаднуть приложения когда конфиг изменился (это можно уже отследить).
Смысл в таком сценарии, что мы меняем файл, и наша структура автоматически подцепляет изменения.
Не забудьте, что вам еще нужно пересоздать все обьекты, которые зависят от конфига (сделать новые коннекты, etc). Я предпочитаю делать перезагрузку всего приложения — например смотреть на конфиг, если изменился, то релоад приложения.
Хотя сейчас, когда мы используем kubernetes, смысла в этом уже нету — либо рестартануть pod (если конфиг замаунчен как раздел) или просто смотреть kubernets API на изменения конфига. В таком случае умение библиотеки изменять структура после изменения файла бесполезно.
```go
func main() {
example_fn := func(x string) string { return x }
print(example_fn(«hello»))
example_fn2 := func(x int) int { return x }
print(example_fn2(10))
}
```
Как раз в первом варианте (тот что с callback), там выводится тип анонимной функции по первому использованию и после этого выведенный тип удовлетворяет сигнатуру функции **call**.
Можете кинуть ссылку на документацию по этому?
UPD: как раз в Go тип переменной вывелся из присваиваемого значения.
Тип анонимных функций определяется при первом использовании. Потому, если я все правильно понял.
Вот у вас функция:
println!("{}", call(10, 10, |a, b| a + b));, а вот тут первое использование —c(a, b).aиbимеют типi64, потому у этой анонимной функции будет типFn(i64, i64) -> i64, а не потому что в сигнатуреwhere F: Fn(i64, i64) -> i64.> Необходимость собирать в бинарник или использовать virtualenv (я предпочитаю этот вариант) это больше неудобство, чем проблема.
Так разве удобство это не преимущество?
Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.
Анужна 2.2 версия, а тулзеБ3.1. Блин, надо virtualenv настраивать?pipилиyum— чем мы там python зависимости ставим? А уже везде дефолтная версия python3? Ахх, тут на 100 серверах yum'ом установили, а на другой сотне pip'ом.state: latestигнорит версию в названии пакет).И так далее.
Преимущество есть и оно большое (может быть конечно не "невообразимое").
А говорят в Go очень низкой порог вхождения, оказывается не такой уже и низкий.
UPD: хотя да, это вывод типа анонимной функции, но не потому что в аргументе c функции call указаны все необходимые типы для колбэка.
encoding/jsonиспользует рефлексию.azure.microsoft.com/en-us/status/history
Я ее разрабатываю.
Но не все пользуются облачными платформами, не у всех 1 rps нагрузка и так далее. Вы тут подобрали специальные условия и представляете свое решение как единственно правильное учитывая только ваши условия.
Вы сейчас это серьезно?
Не надо сейчас придумывать, что там принято в Go.
Вот эта ваша самоуверенность удивляет — проблемы могут быть везде, начиная от железа, проблем сетью и до того, что админ или вы случайно кильнете ваш сервис. Но у вас «В дотнете риск существует только при обновлении.».
Магия, не иначе.
Надежда это не стратегия, то что вам повезло, не означает, что вы правильно все делали.
ОС я так понимаю вы тоже не обновляете?
Предлагаю всегда иметь HA, иначе это уже не серьезно.
Толку с ваших стратегий по обновлению конфига, если у вас упал один инстанс и уже даунтайм.
HA это про доступность сервиса.
Он не откидывает новые соединения, он исключен из балансировки.
Если у вас только один инстанс (что случай только для балансера), то дейлайте как это сделано в nginx — старые процессы обрабатывают только текущие запросы, а все новые идут на новые.
Если у вас HA, то нету никаких проблем тут. Та же стратегия во время деплоймента новой версии, только вместо релоада — рестарт.
А что, http сервер уже не часть приложения?
Делать нужно graceful stop приложения (то есть не принимать новых коннектов, а только завершать старые), это должно быть уже у вас реализовано, а потом уже создавать новые коннекты, обьекты и тд — после этого принимать новые запросы.
Вы только что сами придумали себе кучу проблем, вместо того чтобы просто релоаднуть приложения когда конфиг изменился (это можно уже отследить).
Есть еще масса параметров http сервера, когда нужно будет его рестартануть (ключи, конфиг tls, etc).
Не только обновить коннекшн стринг, а закрыть старые и создать новые коннекты. А что, вы создаете новый коннект к базе на каждый запрос?
Не забудьте, что вам еще нужно пересоздать все обьекты, которые зависят от конфига (сделать новые коннекты, etc). Я предпочитаю делать перезагрузку всего приложения — например смотреть на конфиг, если изменился, то релоад приложения.
Хотя сейчас, когда мы используем kubernetes, смысла в этом уже нету — либо рестартануть pod (если конфиг замаунчен как раздел) или просто смотреть kubernets API на изменения конфига. В таком случае умение библиотеки изменять структура после изменения файла бесполезно.