Mike
Тут как раз же срачик был, писать игры на го или нет
A.
А почему бы и нет...
Mike
Ну листани почитай
Alexey
кто какую либу для редиса юзает?
engelbart
вроде родная есть
dev_sheep
Ребят, подскажите, пожалуйста, почему, если писать так: ... f, _ := os.OpenFile("text.txt", os.O_RDWR, 0666) n, err := io.WriteString(f, "Hello World!") ... то в файл все отлично пишется, но если писать так: ... f, _ := os.Open("text.txt") n, err := io.WriteString(f, "Hello World!") ... то файл остается пустым? Возможно, дело в разрешениях, но ведь Open() юзает 0666. И вообще, если я не буду юзать Open(), то я должен определять систему юзера, чтобы там ставить выбирать, какое значение ставить, 0666 или rwxrwxrwx.
Aleksandr
Можете указать, где почитать про deploy web golang проектов. Я так понимаю придется перезагружать полностью ПО. Соответственно в минус уйдут подключения уже существующие и на время деплоя. Как это избежать
engelbart
не париться
Ivan
читать без привязки к golang. Вкратце, выводить из ротации на балансере, перекладывать, заводить в ротацию
dev_sheep
спасибо, понял. Чувак значит попутал в статье
Anton
спасибо, понял. Чувак значит попутал в статье
Лучше не статьи читать, а офф документацию
dev_sheep
Не, ну статьи тоже нужны :)
dev_sheep
Еще вопрос - как часто используется recover?
dev_sheep
panic-то оно понятно, что хорошо юзается, а вот recover...
Slava
воу воу
Slava
что значит хорошо юзается?
Slava
никто не использует panic
dev_sheep
хм... Значит мои джавистские привычки. Тоесть здесь все обрабатываем через err != nil?
Slava
Вроде того
dev_sheep
Просто в Java мы try catch давай... Если прямо дикая вещь какая-то, можно throw new ...
dev_sheep
А тут, как я понял, для этого panic
Slava
Нет
dev_sheep
но это видимо тут идеология такая, черз err
Slava
Это разные инструменты
Anton
Панику юзают, чтобы завершиться нештатно, но это не является good practice
Anton
Лучше стараться этого избегать
dev_sheep
ага, понял
Anton
А вот возврат значения и ошибки - это наше все
dev_sheep
спасибо :)
dev_sheep
получается, если надо сгенерить ошибочку свою, то errors.New?
Anton
если из строки
Anton
Хотя нет, гоню
Aleksandr
да
dev_sheep
супер
dev_sheep
значит правильно делаю :)
Aleksandr
Если из структуры, то надо реализовать метод Error()
Anton
Можно еще реализовать интерфейс Error для обьекта и вернуть этот обьект
dev_sheep
понял, благодарю
Ivan
fmt.Errorf еще есть
Anton
fmt.Errorf еще есть
Да, это как раз, чтобы из строки создать ошибку
Michael
Интересный доклад: http://talks.godoc.org/github.com/gobwas/ps1ws/notifier.slide
Илья
если он еще заопенсорсит epoll свой
Илья
тогда будет еще интереснее
Michael
Примечательно то, стандартный net/http вышел не ахти. и в большинстве презентаций пишут о том, что приходится от него отказываться.
Илья
ну, тут вопрос в требованиях, для большинства задач, он вполне ахти
Michael
fasthttp не просто так родился, например.
Michael
https://www.techempower.com/benchmarks/#section=data-r13&hw=ph&test=plaintext
Roman
Кстати, в FastHttp вроде нет возможности принимать большие файлы от клиента - читает все в память, а не на диск ((
Michael
Автор изначально писал его для RTB, т.е. куча мелких запросов. И по мелким запросам он вроде даже nginx обгонял. Сейчас пишет как вебсервер общего назначения. Про приём больших файлов не знаю. Но его точно используют и даже выставляют в инет.
Slava
Погоди Михаил =) вопрос был про то, кто пишет что net/http не ахти
Michael
с моей точки зрения он не ахти по производительности. я ж с презентации начал. Там та же мысль отражена.
Michael
автор fasthttp тоже пишет, что он по производительности не ахти.
Slava
это же мейл ру
Slava
то есть у нас уже две компании за fasthttp, автор и mail.ru
Slava
я не отрицаю что для определённых задач fasthttp хорош, но это не значит что net/http плох
Michael
в презентации mail.ru они вообще сами tcp-сокет открывают
Michael
Да, я перебрал с формулировкой. согласен.
Michael
скажу так. есть изъяны. 😊
Anonymous
я не отрицаю что для определённых задач fasthttp хорош, но это не значит что net/http плох
По вашему мнению фастхттп на во сколько раз мощнее чем http из коробки?
Slava
у меня нет мнения, потому что я его не использовал. Но Миша, думаю, может рассказать про свои эксперименты
Anonymous
Было бы хорошо
Michael
Мои эксперименты наводят на мысль, что и сам net не ахти. 😊 Ибо приём пакетов или соединений приводит к аллокации памяти на каждый пакет/соединение и невозможно от неё избавиться, не переписав всё на сисколы.
Michael
и я ожидаю, что рано или поздно появится какой-нить net2, где выделение памяти будет отделено от выполнения метода обекта.
Roman
Но все таки, когда лучше выставлять net/http или fasthttp наружу, без nginx?
Michael
про работу под виндой я вообще молчу. нельзя свой хэндлер в net передать или прочитать. Т.е. SO_REUSEPORT уже нельзя с net использовать. Т.е. кросплатформенность из коробки условная. Всё как бы работает, но нет той гибкости, что имеется под Линуксом.
Mike
Но все таки, когда лучше выставлять net/http или fasthttp наружу, без nginx?
лучше не выставлять наружу без нгинкс, например
Michael
В fasthttp надо смотреть настройки по ограничениям размеров тела, заголовков и прочего. Без них точно выставлять не надо.
Michael
Я слышал, что вроде бы в будущем в Go будет переиспользование памяти встроенным. Т.е. этакий скрытый sync.Pool. видимо из-за этого авторы Go и не заморачиваются по поводу выделения памяти под небольшие структуры внутри рантайма.
Michael
я net использую.
Michael
Алёша, используйте net/http и не переживайте про память. для большинства задач оно подойдёт .