Главное преимущество Go

> типизацию, наследования и прочие плюшки ООП
так и в Go error это:

interface error {
    Error() string
}

что там будет кроме этого реализовано уже на вашей совести

тут как раз и вопрос что когда у вас контекст перед глазами вам проще обработать его, напишите тот же вариант с двумя файлами на Java и попробуйте ответить на вопрос правильно ли все работает с учетом того что между try {} и catch {} будет кусок кода, вам как минимум придется скролить вниз и смотреть чтоже там написано, а так у вас весь код перед глазами и когда вы пишите так 50 раз за день при том же ревью если код написан по другому (нет закрытия файла например) у вас глаз уже зацепится за это

опять же по коду видно когда именно он может завершиться, тоесть когда вы вызываете чужой код из его вызова не видно может там быть исключение или нет, а в Go явно видно где точки выхода из метода

Главное преимущество Go

кстати ветка ниже навела на мысль, что это не так, если не удастся открыть второй файл, то первый нужно будет закрыть… и всеравно придется добавлять блок finally с проверками открыт ли файл, если да то закрыть его

Главное преимущество Go

это не равноценный код, у вас файл будет закрыт при выходе из анонимной функции

Главное преимущество Go

понятно, что error это интерфейс и никто не мешает передавать значения с более широким набором методов, тоже самое используется и в языках с исключениями — через создание кастомных классов от базового исключения.

Главное преимущество Go

Просто это часть философии языка — что код все форматируют одинаково

Главное преимущество Go

к сожалению пока не изобрели клонирование людей, поэтому нужно брать «в среднем по больнице».

В Go попроще чем с кодами возврата — возвращается по сути текст ошибки и в большинстве случаев ее просто перекидываешь наверх, плохо что не всегда в сторонних либах реализована возможность нормально определить что именно за ошибка произошла.

Главное преимущество Go

тоесть

go fmt

вы в проекте ни разу не запускали?

Главное преимущество Go

Что в данном случае можно вынести и куда?

func diff(filename1, filename2 string) string, error {
     file1, err := os.Open(filename1)
     if err != nil {
         return "", err
     }
     defer file1.Close()

     file2, err := os.Open(filename2)
     if err != nil {
         return "", err
     }
     defer file2.Close();

     // some work
}

Главное преимущество Go

операции ввода/вывода (и не только) в go возвращают ошибки (error), это часть нормальной работы, то есть предусмотренное поведение, как аналог исключений можно рассматривать конструкции panic (например выход за границу массива)

Например io.EOF это тоже error и после него скор. всего не нужно падать, а можно например сказать что все хорошо, просто данные кончились.

Главное преимущество Go

да каждый раз нужно проверять, с общим try/catch и поведение разное, тут выполнение не прервется если есть ошибка

Главное преимущество Go

Так и задача направить, а не заставить любой ценой. Фокус в том что с подчеркиванием это место получается выделенным и если что на него проще обратить внимание и заподозрить неладное
Ну и пропуск значений при присваивании это стандартная конструкция языка, тут все соответствует принципу заложенному в Go — чем проще тем лучше.

Браузер-в-браузере сделает сайт намного безопасней

вот картинка:
blog.cloudflare.com/content/images/2014/Sep/illustration-keyless-ssl-explained-01.png

получается что разница только в том что они не хранят приватный ключ, для этого используется специальный key server который дешифровывает для них сообщения на этапе рукопожатия, содержимое запросов как я понял они после этого видят

Браузер-в-браузере сделает сайт намного безопасней

не помню — вроде у cloudflare тоже было — он может проксировать ssl трафик

Браузер-в-браузере сделает сайт намного безопасней

Как раз в версии с DOM он будет показан сразу на экране

А как тогда это будет синхронизироваться? то есть один запрос упал, подвис и т.п.

Хедеры проксируются

Ну это тоже добавляет проблему доверия — так как в tcp данным об айпи более менее верить можно, а вот кто именно и как указал хедер непонятно, ну и нужно будет доработать антифрод чтобы он верил тогда этим заголовкам.

Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.

Я в принципе и имел ввиду это, просто если вы сам софт не сертифицируете то банкам придется делать это в рамках конкретной инсталяции с нуля.
Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).

Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?

Это доп. компонента, поэтому это доп. точка отказа.
Разве в webkit не существует уязвимостей или 0day? В случае банка я через такую получу доступ на выполнение кода на сервере банка.

Браузер-в-браузере сделает сайт намного безопасней

Все равно задержки будут адовые, любой символ который я ввожу прежде чем быть отображен должен быть обработан webkit'ом возможно даже на другой стороне нашего шарика, а потом мне должны придти изменения dom (в каком виде кстати? тотже ввод значения не меняет dom а меняет свойство)
Взаимодействие с пользователем будет ограничено (например врятли вы будете передавать события перемещения мыши), банку нужно будет еще как-то данные об айпи и т.п. пользователя передавать, языке и т.п.
Ну и накладные расходы на запущенные вебкиты — для крупного процессинга это тысячи одновременных сессий вебкита

И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.

В общем это добавляет сложности, точек отказа, а также возможно иллюзию безопасности, так что я бы поставил "-"

Пора заменить Python как язык для обучения

И что? Задач в которых требуется максимально возможная производительность на самом деле не так и много, время и затраты зачастую куда важнее
Ну и в довесок: А ничего что Java тоже интерпретируемая (JVM, Dalvik)? И это кстати свойство реализации, а не языка, для PHP тоже есть компиляторы и интерпретаторы c JIT, а начиная с 7 версии это (JIT) обещают сделать и в Zend реализации

Ошибки в архитектуре от людей зависят, а не от языка. В С++ гораздо проще отстрелить себе ногу и потом несколько дней искать почему же оно падает.

Ну а по поводу неоднозначностей и противоречий там много написано по делу, но половина из этого решается соблюдением CS и использованием всегда ===, что-то устарело, например пункт про finally, так что работа идет

в общем в вашей фразе:

PHP, мне кажется, нельзя никому изучать, не то что первым языком, а вообще

чувствуется снобизм и воспоминания о личном неудачном опыте

Пора заменить Python как язык для обучения

Если очень хочется дженериков, кодогенерируйте, это официально одобренный путь…

«Хабрахабр» представляет «Мегамозг»

если он изгнанный, почему он тогда «Последний раз был на сайте 21 января 2015 в 11:51»

Пора заменить Python как язык для обучения

это некорректное сравнение и go и pascal это языки программирования.

какие есть плюсы у Pascal в сравнении например с Go кроме того что его придумал Niklaus Wirth для целей обучения?
Зачем тогда учить чему-то чтобы потом переучивать?

Пора заменить Python как язык для обучения

«ограничен в применении» — тут не только чисто технические ограничения, так-то в паскале (delphi точно) можно и ассемблерные вставки делать, тут я имел ввиду комбинацию того насколько это легко делать технически, с тем насколько это вообще оправдано, то есть вот написали вы веб сервер на паскале, дальше что делать? на работе то скорее всего попросят писать на C/Python/Ruby/Php. Может лучше сразу писать на языке который имеет боевое применение?!
С tcl сравнить не могу — я на нем не писал.