я вот использую go build как линтер в редакторе, сразу видно, что и где у меня не используется и все остальные проблемы (хорошо, что компилятор очень быстрый).
Ничего себе заявления. А вы случайно свои сайтики не в DigitalOcean хостите? А дропбоксом пользуетесь?
Все проекты в CNCF написаны на Go (а те что не были, как linkerd, переписали на Go). Вот тут у Go как раз своя ниша — все что связано с платформой.
Как бы вам не хотелось, но Go это как раз не домашние проектики.
ну тут проблема в стиле — «вот в json не нужно запятую после последнего элемента ставить, а в Go нужно, ууууу, неудобно».
@zubor правильно подметил — запятая после последнего элемента в много строчном объекте требуется специально (даже Russ Cox об этом писал), как раз из-за того, что при удалении и добавлении элементов (и генерации кода) не нужно было постоянно проверять последний ли элемент это или нет.
OpenShift сейчас самый популярный дистрибутив Kubernetes. Весь интерпрайз (типа больших банков) ломанулись внедрять стильный-модный-молодежный Kubernetes, а тут и RedHat c OpenShift — OS они им уже сапортят, связи налажены.
А еще RedHat недавно CoreOS купили со всеми их поделками (Tectonic, etcd, etc).
я не готов дискутировать на эту тему, так как не знаю как это реализовано.
Знаю что в расте оператор? или макрос try! это такая же обработка ошибочной ситуации паттерн матчингом.
Точно тоже, что делает check с дефолтным хендлером в Go или вручную с if err != nil.
действия который происходят во время ошибочной ситуации (то есть после диагностирование) есть обработка ошибочной ситуации. Возврат ошибки — это остановка дальнейшего выполнения функции/метода.
нет, я считаю, что
* вызов дефолтного хендлера это обработка ошибки, так же как `?` в Rust — это обработка ошибки. Так же как `unwrap` это обработка ошибки — бросает панику если есть ошибка.
* будут не только дефолтные хендлеры, конечно же, хотят добавить больше возможностей (что бы добавлять контекст во все ошибки функции, например)
Я вам привел пример того, что в Rust есть «обработчик ошибки в Rust, который определяется задолго до места, в котором ошибка диагностирована»
Задача '?' и 'try!' лишь в том, чтобы проверить результат операции и, если результат отрицательный, возвратить его в вызывающую функцию.
И
Все. Никакой обработки ошибок ни '?', ни 'try!' не задействует.
Тоже самое будет делать check c дефолтным хендлером.
Обработка реализуется в вызывающей функции посредством обычного паттерн-матчинга (либо через match, либо через if let). И, что важно, обработчик ошибки в Rust-е пишется там же, где результат операции проверяется.
а что не так? Если не определять handler то будет использоваться дефолтный handle err { return nil } — как в Rust c?..
В тоже время можно определить свой в начале метода/функции или обработать ошибку в месте, где возникла if err != nil {}.
я вот использую
go buildкак линтер в редакторе, сразу видно, что и где у меня не используется и все остальные проблемы (хорошо, что компилятор очень быстрый).Это только в случае удаления последней строки, в середину тоже самое, то есть редкий кейс. Да и правильно —
git diffи код ревью вам в помощь.Рантайм рантайм — сборщик мусора, планировщик goroutine, etc. Рантайм.
Все это будет в вашем одном бинарном файле.
Ничего себе заявления. А вы случайно свои сайтики не в DigitalOcean хостите? А дропбоксом пользуетесь?
Все проекты в CNCF написаны на Go (а те что не были, как linkerd, переписали на Go). Вот тут у Go как раз своя ниша — все что связано с платформой.
Как бы вам не хотелось, но Go это как раз не домашние проектики.
@zubor правильно подметил — запятая после последнего элемента в много строчном объекте требуется специально (даже Russ Cox об этом писал), как раз из-за того, что при удалении и добавлении элементов (и генерации кода) не нужно было постоянно проверять последний ли элемент это или нет.
А еще RedHat недавно CoreOS купили со всеми их поделками (Tectonic, etcd, etc).
Судя по тому, что хотят дефолтный хендлер добавить вида
handle err { return err }, то так и будет, как вы написали во втором случаене делает, но то что предлагают, конечно же
Знаю что в расте оператор? или макрос try! это такая же обработка ошибочной ситуации паттерн матчингом.
Точно тоже, что делает check с дефолтным хендлером в Go или вручную с if err != nil.
Вы считаете, что все что в теле `if err != nil` все еще диагностирование?
* вызов дефолтного хендлера это обработка ошибки, так же как `?` в Rust — это обработка ошибки. Так же как `unwrap` это обработка ошибки — бросает панику если есть ошибка.
* будут не только дефолтные хендлеры, конечно же, хотят добавить больше возможностей (что бы добавлять контекст во все ошибки функции, например)
Я вам привел пример того, что в Rust есть «обработчик ошибки в Rust, который определяется задолго до места, в котором ошибка диагностирована»
И
Тоже самое будет делать check c дефолтным хендлером.
Как и в Go c `if err != nil`
а что не так? Если не определять handler то будет использоваться дефолтный
handle err { return nil }— как в Rust c?..В тоже время можно определить свой в начале метода/функции или обработать ошибку в месте, где возникла
if err != nil {}.?иunwrap