Да ну. Усомнился, проверил прямо сейчас в питоне. При стеке f1 <- f2 <- f3 и возбуждении исключения в f1 его можно поймать в f3, а f2 ничего о нём не знает.

Питон вообще много что позволяет делать, в том числе и писать совершенно упоротые реализации DSL, работающие с применением внутренних механизмов кодировки файлов, но это не значит, что так надо делать. Подобное просто не пройдёт code review.

не использовать транзакции

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

не знать архитектуры проекта

Теперь я начинаю понимать, как люди умудряются писать на жабе код более бажный, чем код на крестах.

Знание архитектуры проекта != знанию интимных деталей каждой функции проекта. Ну и по традиции, расскажи мне пожалуйста, где взять реализацию транзакций для UDP или для записи в UNIX socket.

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

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

Теперь я начинаю понимать, как люди умудряются писать на жабе код более бажный, чем код на крестах.

Сравнивать два разных проекта на разных языках от разных людей это идиотизм. Если уж хочется оценить язык по проектам, то только по количеству.

Знание архитектуры проекта != знанию интимных деталей каждой функции проекта. Ну и по традиции, расскажи мне пожалуйста, где взять реализацию транзакций для UDP или для записи в UNIX socket.

Ты пишешь по одному пакету на каждый байт? Обычно сначала формируется информация со всякими возможными в этом процессе исключениями, а потом готовое отправляется в сокет. Если что-то сломалось в момент отправки, то тут уже вряд ли можно что-то предотвратить.

Ссылку на githutinfo уже давали

Это устаревшие данные (2014 год).

почему в с++ нельзя выбрасывать исключения в конструкторе?

Учил бы ты матчасть. И заодно про уровни exception safety, а то открываешь америку уже полтреда.

Интересно, сколько комментаторов треда реально относится к новости?

Fix.

Подобное просто не пройдёт code review

Разупорись. Проброс исключений по стеку - это повседневность как минимум в C++, java, C#, python.

http://sogrady-media.redmonk.com/sogrady/files/2015/01/lang.rank_.plot_.q1152...

Ну вот от красных макак на начало 2015-го (го на 17-том месте). Если надо еще ближе, анализируйте SO и github сами. Тот же DS SO за 2016 год

http://stackoverflow.com/research/developer-survey-2016

For the second year in a row Rust, Swift and Go make the top 5 most loved programming languages. VB tops the list of the most dreaded technologies – developers wouldn’t miss it if it went extinct. Developers who don’t currently develop with Android, Node and Angular want to do so.

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

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

Что-то ты погорячился)

В haskell есть исключения. Понятное дело, что в чистом коде их не обработаешь, и они непредсказуемы из-за ленивости, но в императивном коде исключения прекрасно кидаются и отлавливаются, точно также как в какой-нибудь java.

Это примерно, как утверждать, что в haskell потоки только зеленые, что не так.

Погоди, ты тут про транзакции рассказываешь. Ну так давай, пили прохладную про транзакции. Вот собрался я отправить данные, скажем, 200 килобайтов, по IPv4/UDP. Нарезал их на пакеты по 65507 байтов отправил первый и тут что-то случилось. Как откатить транзакцию?

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

Именно. Даже если ты наставил обработчиков исключений на каждой строке, всё равно пакеты могут потеряться в процессе передачи.

Приведи пример ошибки которую нужно обрабатывать на 10 уровней выше?

Пример: у тебя во время доставания количества звёзд регистранта на лоре случилась ошибка. Это место в коде находится так: отрисовка страницы - отрисовка треда - отрисовка сообщения - отрисовка метаданных юзера - отрисовка звёзд.

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

Поздравляю, вы изобрели TCP! :)

Чего не сделаешь ради анонимуса.

Go будет продавливаться корпорацией

Кто сказал?

Эффективные менеджеры Гугла довольны тобой. Защищай этот езык от ЛОРовцев.

Зачем в 2016 году процедурный язык? без ФП и ООП?

Чего не сделаешь ради анонимуса.

Awwwww <3

Проброс исключений по стеку - это повседневность как минимум в C++

Упоролся, там исключения выбрасываются только в вызывающий код. Не обработал — std::terminate

Там не те исключения. Их не предполагается ловить. Тем более на 10 уровней выше, как тут некоторые особо рьяные советуют.

Что ты имеешь в виду? В haskell есть те самые исключения, такие же как в Java. Или о чем ты?

там исключения выбрасываются только в вызывающий код

Вообще непонятно о чем ты. Покажи, где другие исключения?

Он, наверное, об обработке исключений. О том, что их обрабатывают максимум в виде

while (true)
{
    try
    {
        // ...
    }
    catch (const std::exception& e)
    {
        log() << "shit happened: " << e.what();
    }
}

Закопать смолоду

Минорщина, маргинальщина.

Минорщина

Да.

маргинальщина.

Нет: http://githut.info/

Зачем в 2016 году процедурный язык? без ФП и ООП?

Сама ООП уже не новинка, а давно классика. Такая же классика структурное программирование.

Зачем в 2016 году процедурный язык? без ФП и ООП?

Сама ООП уже не новинка, а давно классика. Такая же классика >структурное программирование.

В Go есть поддержка декларативного ООП в минимально необходимом виде, без лишнего усложнения. Элементы FP планируется ввести в следующих версиях, пока этого нет чтобы не нарушать совместимость. Уже сейчас есть ФП языки, которые транслируются в Go, так что вопрос времени. Java в начале своего пути тоже мало что поддерживала, поэтому выводы о Go делать пока рано.

как он собирается потеснить с/с++ где такая приятная мелочь есть как личный стиль и выразительность конкретного разработчика?

Зато в Go есть прокрустово ложе gofmt, от которого некоторые в большом восторге.

Сама ООП уже не новинка, а давно классика. Такая же классика структурное программирование

да, и это не значит что можно без него

В Go есть поддержка декларативного ООП в минимально необходимом виде

неа, нету

В rust так: let data = try!(get_data());

Да, вот так на каждый вызов и нужно писать try! или unwrap (типа, ошибки не будет, зуб даю), потому что в нетривиальных библиотеках практически каждая функция потенциально может привести к какой-нибудь ошибке. Это даже в Rust FAQ закреплено: What's the deal with unwrap() everywhere?

Вот зря вы так. Потому что ООП это не про классы и конструкторы и наследование, а про ооп проектирование. я выше по треду упоминал книжку Вирта Гуткнехта «Разработка операционной системы и компилятора. Проект Оберон», так там можно наглядно прямо в листингах посмотреть как создавалась полностью ооп система через типы и механизм расширения типа, что в Го как раз реализовано в полном объеме.

куцый недоязычок

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

можно сколько угодно говорить что 'ооп это не про то, а про другое', и вообще что ООП это про посылку сообщений КЕЙ СМАЛТОЛК АНОНIМУС, только по факту ООП в Go в общепринятом понимании от этого не появится, следовательно следует считать что его там нет

Да-да, мы уже поняли, что надо каждую строчку кода оборачивать в 10 условий на каждом уровне. Настоящий каноничный программист 1 час проектирует программу и 9 часов пишет обработку условий.

ну так в го штучку для приема сообщений определенного типа завезли под названеим интрефейсы (если смотреть на этот вопрос макисмально шроко в духе АНОНIМУСА).

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

ну так в го штучку для приема сообщений определенного типа завезли под названеим интрефейсы (если смотреть на этот вопрос макисмально шроко в духе АНОНIМУСА).

Можно в духе анонiмуса обмазаться говном и няшить друг друга в анус, но зачем?

В топку все эти теоретико-блудствования.

Почитал тутор, попробую что-нибудь написать:)
Интересно когда в него пропихнут классы и исключения, то как изменится кукарек тру готухов?
Почитав код некоторых проектов просто диву даешься как все похоже на пхп4, просто какая-то инфернальная лапша, а ведь так уже никто не пишет.

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

Я выше описал случай. На лоре что-то сломалось в базе — лор тебе выдаёт страницу ошибки, а не выбрасывает кусок страницы который не смог достать.

Интересно, сколько комментаторов треда реально пишут код?

Еще интереснее сколько из них пишут код на Go. Именно пишут, а не «изучают фичу» в свободное от ПыхПыха время))

ООП это религия и маркетинг

в отличии от абстрактных типов данных и многого другого.

тот же Алан Кей «когда я придумал ООП я подразумевал вовсе не С++»

короче приговор для единых иерархий «ООП не может в многосортные алгебры»

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

моде на ооп в том числе предшествовала такая же в части маркетинга и евангелизма мода на структурное программирование - но улыбка истории на тот момент околокомпьютинг был не так массов как на переломе 90ых - и знаменитая домохозяйка стоящая в очереди за вынь95 ибо увидела рекламу и она её убедила ещё не настало.

зы. ведь наследование как метод повторного использования принесло больше убытков чем прибыли.

а чего сайтец помер, не в курсе? Последние данные за Q4/14.

Можно и самим повозиться, у github есть api для запросов по подобной статистики.

ООП это религия и маркетинг

каждый видит то что хочет, религиозный человек увидит религию, маркетолог - маркетинг. Я хочу увидеть то, что видит инженер

каждый видит то что хочет, религиозный человек увидит религию, маркетолог - маркетинг. Я хочу увидеть то, что видит инженер

Я инженер-программист, структурный способ написания программ меня вполне удовлетворяет. Я имею ввиду чистый Си, если кто недопёр.

На самом деле язык программирования — это просто инструмент. Структурная парадигма и ООП парадигмы — это две РАВНОПРАВНЫЕ, и непохожие способы написания программ. Тот, кто говорит, что раз в языке нет ООП, значит он ущербен. Это ложь!

Разрабочики Go должны делать, либо структурный язык, либо ООП язык. Не надо скрещивать ужа с ежом. Иначе на выходе получится монстр, типа Си++. Когда разработчики Java выкинули все не ООП возможности из своего языка. Они сделали правильно! Стремление усидеть на двух стульях ошибочно.