Comments 19
Посмотрел очередной дайджест и хочу поднять вопрос с гоферам: есть ли такие проекты, в которых хороший Golang код? Не perl-go, java-go, php-go и так далее.
Советовали посмотреть kubernates, но и там все то де: интерфейсы ради интерфейсов на том же уровне, что и реализация…
Вполне серьезно спрашиваю: хочу хотя бы небольшую подборку хорошего гошногг кода сделать. Подчеркиваю, не хороших проектов, не удобных пакетов, а именно хорошего golang кода.
Советовали посмотреть kubernates, но и там все то де: интерфейсы ради интерфейсов на том же уровне, что и реализация…
Вполне серьезно спрашиваю: хочу хотя бы небольшую подборку хорошего гошногг кода сделать. Подчеркиваю, не хороших проектов, не удобных пакетов, а именно хорошего golang кода.
Я смотрю хороший код в стандартной библиотеке. Рекомендую начать оттуда. К примеру, вот код из net/http https://golang.org/src/net/http/
Читаю стандартную библиотеку пару лет и она не хороша везде. Очень чувствуется, что ее писали разные люди и часто еще не имеющие гошного опыта, просто в силу того, что его они же только что создали.
Так что «с одной стороны да, но вцелом нет»: однобуквенные переменные, ошибки через панику, даже есть велосипедные реализации try catch, методы по сотне строк.
Из хорошего: мне очень нравится элегантное решение с сортировкой. Универсальное, не зависящее от типов и не требующее обобщенных типов, интерфейс из одного метода — отличное решение.
Так что «с одной стороны да, но вцелом нет»: однобуквенные переменные, ошибки через панику, даже есть велосипедные реализации try catch, методы по сотне строк.
Из хорошего: мне очень нравится элегантное решение с сортировкой. Универсальное, не зависящее от типов и не требующее обобщенных типов, интерфейс из одного метода — отличное решение.
Конкретно к net: много ненужного выделения памяти, что мы все знаем и почему стали появляться проекты вроде fasthttp; создание ошибок на месте их появления, ошибки не имеют ни типов, ни своих интерфейсов, ни кодов ошибок. У Дейва хорошо разобрано про ошибки — подход стандартной библиотеки вынуждает меня или бездумно прокидывать ошибки выше, или также бездумно заменять своими, теряя контекст, или подавлять, или проверять ошибки по сообщениям в них, что совсем печально.
А вот это не смотрели? Говорят, что вполне прилично они пишут:
https://github.com/hashicorp/vault
https://github.com/hashicorp/consul
https://github.com/hashicorp/vault
https://github.com/hashicorp/consul
Ццблагодарю, посмотрю внимательнее, но пока есть сомнения:
https://github.com/hashicorp/vault/blob/master/vault/acl.go — метод за 120 строк с 4х кратной вложенностью if, использование goto без критичной необходимости.
https://github.com/hashicorp/vault/blob/master/vault/acl.go — метод за 120 строк с 4х кратной вложенностью if, использование goto без критичной необходимости.
> использование goto без критичной необходимости
На мой взгляд, вот в данном конкретном случае тут ничего страшного в использовании goto нет, наоборот упрощает код.
> с 4х кратной вложенностью if
Тут согласен, но, опять же, ничего особо страшного в этом не вижу. После ада с 8-10 if'ами, которое мне доводилось видеть, читается довольно легко.
На мой взгляд, вот в данном конкретном случае тут ничего страшного в использовании goto нет, наоборот упрощает код.
> с 4х кратной вложенностью if
Тут согласен, но, опять же, ничего особо страшного в этом не вижу. После ада с 8-10 if'ами, которое мне доводилось видеть, читается довольно легко.
Непонятна необходимость делать громадный метод со сложной логикой, которую после побеждаем при помощи goto. Хотя можно было сразу делать простые методы. Сейчас же он делаем Много чего в себе, ответственность у него большая, как следствие тесты не маленькие, а такие же большие по сути.
Если посмотреть с этой стороны — то да, один из анти-паттернов, лучше разбивать на несколько более простых. Возможно так было сделано ради оптимизации по скорости выполнения.
тоже странный аргумент: если ребята дошли до той черты, когда дополнительный вызов метода значим, то зачем они взяли язык с GC? Ну или, почему тогда на этот «супер-критичный» по производительности метод не бенчмарков?
В общем, не думаю, что такова история. Больше похоже на фигак-фигак.
В общем, не думаю, что такова история. Больше похоже на фигак-фигак.
С GC же вроде с недавних пор все хорошо? В смысле, он умно запускается при паузах, и если не успевает за какое-то время — то переносится на следующий раз. Вроде читал о подобном некоторое время назад.
Насчет «фигак-фигак» — есть сомнения, ребята довольно серьезные, и они свой софт еще в виде enterprise editions продают.
Насчет «фигак-фигак» — есть сомнения, ребята довольно серьезные, и они свой софт еще в виде enterprise editions продают.
Не совсем с GC. Если было бы так, то при любом размере кучи не было бы длительных остановок.
Верным утверждением было бы, что 90-й процентиль stop-the-world не превосходит миллисекунды. В подтверждение моих слов,например — это на 1.6, где вроде как все паузы должны были быть менее 10ms, но на большой map паузы достигают намного больших значений.
Про «фигак-фигак» — не вижу взаимосвязи между «серьезные ребята» и «хороший код».
Верным утверждением было бы, что 90-й процентиль stop-the-world не превосходит миллисекунды. В подтверждение моих слов,например — это на 1.6, где вроде как все паузы должны были быть менее 10ms, но на большой map паузы достигают намного больших значений.
Про «фигак-фигак» — не вижу взаимосвязи между «серьезные ребята» и «хороший код».
Действительно, судя по всему, ждем 1.9.
Станет получше, более конкурентный GC и не всегда съедающий по целому кванту времени, да. Но если есть GC и активно растущая куса, то рано или поздно отложенную на предыдущих шагах GC работу придется сделать и отложенная длительная пауза GC станет только в разы больше.
Фактически сейчас улучшается самый ожидаемый случай с GC, и ухудшается самый печальный.
Фактически сейчас улучшается самый ожидаемый случай с GC, и ухудшается самый печальный.
А чем https://golang.org/doc/effective_go.html не устроил?
Sign up to leave a comment.
Go дайджест. События, статьи, интересные проекты из мира Go (30 марта — 13 апреля 2017)