> Конечно «внутри себя» он использует delta-diff'ы
это делает очень не часто и в зависимости от внутренней логики git и то только в процессе запуска gc при формировании паков. и да это скрыто ото всех и никто, в том числе и все что есть в поставке гита, эти «дифы» не видит. Все работают с полными версиями.
> Никакой истории у файлов нет
я как бы этого и не утверждал
ну так и svn храня патчи пользователю отдает полные файлы, но говорить что svn хранит полные файлы всех версий не корректно.
также и наоборот не корректно сказать что git хранит отличия между версиями файлов и вообще как-то отслеживает что меняются файлы
ну самоубийцам не обязаны, там где есть камеры например это помогает, знаю примеры когда чувак пытался покончить с собой целенаправленно на узкой улице. Второй когда чувак каким-то образом попал на МКАД и его там насмерть сбил микроавтобус — полицейские в принципе после фиксации реквизитов сразу отпустили водителя.
в городе же в целом можно ехать так что даже если выскочит будет не смертельно.
ну а так весь уголовный кодекс расписывает, что люди нарушают закон и что за это бывает. там же и превышение самообороны кстати, которое ещё более не логично.
картинка в статье фотошоп, это факт.
В игры не поиграешь — одна рука занята, а там где будешь касаться палец будет тень.
Ну и летом ещё ладно, а весной, осенью, зимой как с ним быть? Снимать одежду, чтобы посмотреть кто звонит?
> Так вот, я вполне могу считать, что ошибки «сервис погоды недоступен» и «на сервере не хватило памяти на обработку» эквивалентны
ну так есть recover я же не os.Exit в конце концов написал. внутри своей либы общения с погодой я не могу ничего сделать с тем что нет памяти, а вот на уровне приложения уже можно решить что делать.
то есть вы запустили горутины общения с погодой она упала по памяти, вы в recover решили что нужно делать и сделали. (panic кстати не закрывает приложение, он только раскручивает стек вызовов горутины и если дошел до конца завершает её, приложение может условно даже не заметить этого)
Собственно в случае исключений будет та же самая логика.
> О, это внезапно performance-driven decision?
внезапно в мире есть не только черное и белое, а решения не обязательно принимаются лишь из-за чего-то одного, но производительность тут сыграла не последнюю роль, это факт.
> только что мне делать, если у меня никогда не будет столько ошибок
Не использовать Go? Пишите на чем-то скриптовом, с точки зрения скорости написание это будет быстрее, я например пишу на PHP.
Ни один язык не заменяет здравый смысл.
> Весь пост про это.
Ну так пост то не мой. В целом я тоже приходил к выводу, что Go простой в обучении язык. Но аргументация в посте мне нравится.
> Это возвращает нас к вопросу «кто принимает решение о том, стоит ли складывать приложение или нет».
это зависит от того что произошло, если вас вызывают не правильно, говорят выдели мне 200гб памяти, а столько нет или обратись к -2 элементу в массиве это паника, это не нормально, программа написана не правильно, ее нужно переписывать и т.п.
если вы не можете достучаться до сервиса погоды, это нормально это ситуация, которая должна быть предусмотрена и обработана, если у вас http библиотека, вы возвращаете error если сервис запроса погоды вы ее обрабатываете и можете скрыть внутри себя (например вернуть старые данные или ничего не вернуть, а в фоне повторять попытки)
Ну вы же сами выделил критические исключения, кто решает критическое это исключение или нет?
> Всегда же можно поставить blank identifier.
мотивировать != заставить (это кстати можно притянуть к простоте — несмотря на строгость типизации, писать программу ты можешь как хочешь)
error в Go не содержит информации о месте где его создали и т.п., даже больше error это обычно глобальный immutable объект. так что вы можете получать 10, 100к и т.п. ошибок в секунду и у вас приложение будет работать, а вот если вы попробуете сгенерировать столько же исключений, будет грустно.
> я получу panic в другом месте, и happy debugging.
я вам на конкретный вопрос отвечал про ожидаемую ошибку. не хотите обрабатывать, не обрабатывайте, оно все равно упадет
> Необработанное исключение долетит доверху и сложит приложение
Так. в том то и цель чтобы не было не обработанных ошибок, для складывания есть panic.
> Зачем? Вы про какой-то конкретный язык говорите?
затем, что вы должны понимать что происходит иначе когда у вас закончится память, у вас исключения повалятся например в том же блоке catch хотя по идее не должны.
> И, что важнее, я точно не считаю, что то, как сделано в Go — проще (или «меньше понятий», ага).
а я кстати не говорил, что это проще, вообще обработка ошибок это то что на самом деле мало кто делает, потому что это скучно, сложно и не интересно и такая явность их возврата как раз для мотивации этой обработки и делалась
в смысле предположения?
Если вы не обработаете err в случае открытия файла например программа все равно дальше упадет при обращении к nil, так что не вижу проблемы с разным поведением
в Go ошибки не ловят, ошибка это просто некое значение. Вот вы вызываете некий метод, у него есть error вы его обрабатываете, хотите выкинуть его наверх, выкидывайте.
Хотите возвращать прям свой объект ошибки (ну вот хотите), напишите defer который будет оборачивать err если он != nil
Я так понимаю вы хотели что-то такое:
func test() (b byte, err error)
{
if err = some_method; err != nil {
return
}
}
С одной стороны кода становится немного больше (на первый взгляд), но в коде сразу видно где бывают ошибки и что с ними происходит.
Ну и самое главное — «никто не обрабатывает исключения», именно для нивелирования этого и придумали всякие аннотации с информацией о том что метод что-то там генерирует и т.п.
А ещё в библиотеках нужно оборачивать исключения в свой тип исключений иначе его могут не правильно поймать. И в целом делать это правильно вызывая из своего кода чужой будет даже тяжелее чем обрабатывать error который приходит, как одно из значений.
В общем то как это сделано в Go не серебрянная пуля, собственно как и исключения, но причины у этого вполне обоснованные.
в Go разделены ошибки и исключения.
Ошибки это предусмотренные состояния, файл не открылся, сеть упала и т.п., то что можно обработать и жить дальше.
Паника, это что-то что не входит в нормальную работу и после нее возможно стоит вообще оставить выполнение программы: выход за границу массив, ошибка выделения памяти, дедлоки и т.п. то есть то что в месте непосредственного вызова не решается, а перехватывается каким то совсем абстракным кодом, который грубо говоря залогирует панику, сдампит что сможет на диск и завершит приложение.
ЗЫ панику бывает ещё используют для раскручивания стека, но вот гугл от этого уходит кстати
ну справедливости ради у вас там больше 100мс (по крайней мере сейчас)
кстати то что выбранные значения исчезают немного расстраивает, посмотришь цвет, а твои фильтры уже сбросились наполовину
я думаю правильнее сравнивать с чтением литературы на не родном языке. Так вот это как минимум в среднем становится сложнее, чем больше там разных слов и по разному составленных предложений
а можете указывать на каких языках это примеры? c# по maxBy я вроде опознал (только там результат без maxDate будет?)
по поводу сформировать массив для для max — на вскидку такое должно быть либо в компилятор встроено либо что-то с ленивыми вычислениями, иначе у нас мало того что массив создастся так ещё и кучу элементов туда надо добавить будет.
ну смотрите — на абстрактном max(a, b) вроде и правда всё плохо, но давайте что-то более жизненное:
например есть список неких структур, например заказов, нужно найти дату последнего заказа:
var maxDate uint = 0
for o := range orders {
maxDate := max(maxDate, o.createdAt)
}
или так:
var maxDate uint = 0
for o := range orders {
if o.createdAt > maxDate {
maxDate = o.createdAt
}
}
в читаемости как по мне даже несколько выиграло + в отличии от первого варианта, во втором кол-во присваиваний будет равно кол-ву заказов только в худшем случае. про формирование списка массива значений я думаю и говорить не стоит
PS сейчас с читаемостью всё плохо в обоих случаях т.к. хабр удаляет пробелы и не дает делать подсветку кода
по поводу gc уже в августе должен выйти 1.5 в котором всё будет немного по другому
это делает очень не часто и в зависимости от внутренней логики git и то только в процессе запуска gc при формировании паков. и да это скрыто ото всех и никто, в том числе и все что есть в поставке гита, эти «дифы» не видит. Все работают с полными версиями.
> Никакой истории у файлов нет
я как бы этого и не утверждал
также и наоборот не корректно сказать что git хранит отличия между версиями файлов и вообще как-то отслеживает что меняются файлы
в городе же в целом можно ехать так что даже если выскочит будет не смертельно.
ну а так весь уголовный кодекс расписывает, что люди нарушают закон и что за это бывает. там же и превышение самообороны кстати, которое ещё более не логично.
В игры не поиграешь — одна рука занята, а там где будешь касаться палец будет тень.
Ну и летом ещё ладно, а весной, осенью, зимой как с ним быть? Снимать одежду, чтобы посмотреть кто звонит?
ну так есть recover я же не os.Exit в конце концов написал. внутри своей либы общения с погодой я не могу ничего сделать с тем что нет памяти, а вот на уровне приложения уже можно решить что делать.
то есть вы запустили горутины общения с погодой она упала по памяти, вы в recover решили что нужно делать и сделали. (panic кстати не закрывает приложение, он только раскручивает стек вызовов горутины и если дошел до конца завершает её, приложение может условно даже не заметить этого)
Собственно в случае исключений будет та же самая логика.
> О, это внезапно performance-driven decision?
внезапно в мире есть не только черное и белое, а решения не обязательно принимаются лишь из-за чего-то одного, но производительность тут сыграла не последнюю роль, это факт.
> только что мне делать, если у меня никогда не будет столько ошибок
Не использовать Go? Пишите на чем-то скриптовом, с точки зрения скорости написание это будет быстрее, я например пишу на PHP.
Ни один язык не заменяет здравый смысл.
Ну так пост то не мой. В целом я тоже приходил к выводу, что Go простой в обучении язык. Но аргументация в посте мне нравится.
> Это возвращает нас к вопросу «кто принимает решение о том, стоит ли складывать приложение или нет».
это зависит от того что произошло, если вас вызывают не правильно, говорят выдели мне 200гб памяти, а столько нет или обратись к -2 элементу в массиве это паника, это не нормально, программа написана не правильно, ее нужно переписывать и т.п.
если вы не можете достучаться до сервиса погоды, это нормально это ситуация, которая должна быть предусмотрена и обработана, если у вас http библиотека, вы возвращаете error если сервис запроса погоды вы ее обрабатываете и можете скрыть внутри себя (например вернуть старые данные или ничего не вернуть, а в фоне повторять попытки)
Ну вы же сами выделил критические исключения, кто решает критическое это исключение или нет?
> Всегда же можно поставить blank identifier.
мотивировать != заставить (это кстати можно притянуть к простоте — несмотря на строгость типизации, писать программу ты можешь как хочешь)
error в Go не содержит информации о месте где его создали и т.п., даже больше error это обычно глобальный immutable объект. так что вы можете получать 10, 100к и т.п. ошибок в секунду и у вас приложение будет работать, а вот если вы попробуете сгенерировать столько же исключений, будет грустно.
я вам на конкретный вопрос отвечал про ожидаемую ошибку. не хотите обрабатывать, не обрабатывайте, оно все равно упадет
> Необработанное исключение долетит доверху и сложит приложение
Так. в том то и цель чтобы не было не обработанных ошибок, для складывания есть panic.
> Зачем? Вы про какой-то конкретный язык говорите?
затем, что вы должны понимать что происходит иначе когда у вас закончится память, у вас исключения повалятся например в том же блоке catch хотя по идее не должны.
> И, что важнее, я точно не считаю, что то, как сделано в Go — проще (или «меньше понятий», ага).
а я кстати не говорил, что это проще, вообще обработка ошибок это то что на самом деле мало кто делает, потому что это скучно, сложно и не интересно и такая явность их возврата как раз для мотивации этой обработки и делалась
Если вы не обработаете err в случае открытия файла например программа все равно дальше упадет при обращении к nil, так что не вижу проблемы с разным поведением
в Go ошибки не ловят, ошибка это просто некое значение. Вот вы вызываете некий метод, у него есть error вы его обрабатываете, хотите выкинуть его наверх, выкидывайте.
Хотите возвращать прям свой объект ошибки (ну вот хотите), напишите defer который будет оборачивать err если он != nil
Я так понимаю вы хотели что-то такое:
func test() (b byte, err error)
{
if err = some_method; err != nil {
return
}
}
С одной стороны кода становится немного больше (на первый взгляд), но в коде сразу видно где бывают ошибки и что с ними происходит.
Ну и самое главное — «никто не обрабатывает исключения», именно для нивелирования этого и придумали всякие аннотации с информацией о том что метод что-то там генерирует и т.п.
А ещё в библиотеках нужно оборачивать исключения в свой тип исключений иначе его могут не правильно поймать. И в целом делать это правильно вызывая из своего кода чужой будет даже тяжелее чем обрабатывать error который приходит, как одно из значений.
В общем то как это сделано в Go не серебрянная пуля, собственно как и исключения, но причины у этого вполне обоснованные.
Ошибки это предусмотренные состояния, файл не открылся, сеть упала и т.п., то что можно обработать и жить дальше.
Паника, это что-то что не входит в нормальную работу и после нее возможно стоит вообще оставить выполнение программы: выход за границу массив, ошибка выделения памяти, дедлоки и т.п. то есть то что в месте непосредственного вызова не решается, а перехватывается каким то совсем абстракным кодом, который грубо говоря залогирует панику, сдампит что сможет на диск и завершит приложение.
ЗЫ панику бывает ещё используют для раскручивания стека, но вот гугл от этого уходит кстати
кстати то что выбранные значения исчезают немного расстраивает, посмотришь цвет, а твои фильтры уже сбросились наполовину
по поводу сформировать массив для для max — на вскидку такое должно быть либо в компилятор встроено либо что-то с ленивыми вычислениями, иначе у нас мало того что массив создастся так ещё и кучу элементов туда надо добавить будет.
например есть список неких структур, например заказов, нужно найти дату последнего заказа:
var maxDate uint = 0
for o := range orders {
maxDate := max(maxDate, o.createdAt)
}
или так:
var maxDate uint = 0
for o := range orders {
if o.createdAt > maxDate {
maxDate = o.createdAt
}
}
в читаемости как по мне даже несколько выиграло + в отличии от первого варианта, во втором кол-во присваиваний будет равно кол-ву заказов только в худшем случае. про формирование списка массива значений я думаю и говорить не стоит
PS сейчас с читаемостью всё плохо в обоих случаях т.к. хабр удаляет пробелы и не дает делать подсветку кода