Ребят, ну если вы тут пытаетесь доказать, что разработка многопоточных архитектур на C++/boost — это легко, просто и надежно, без надобности нарабатывать 5+ лет опыта и читать талмуды, то что-то вы важное упускаете.
Я писал многопоточный софт на boost и писал на Go — и это просто небо и земля. Пробовать обе технологии, или привязаться лишь к одной и её пропагандировать — это уже ваш выбор.
А вообще, автор статьи, конечно, тупил много ) Но в этом и прелесть статьи, по-моему, что автор не стыдится своих ошибок, и описывает шаг за шагом. Желание написать своё решение, а не искать готовые, видимо было вызвано по той же причине, по которой он не захотел использовать готовые инструменты (не языка, а технологии, описанные в статье).
А вы вправду не понимаете, почему народ в своё время массово стал переходить с C++/Java на Ruby/Python и прочие решения, даже в ущерб производительности?
Есть термин goroutine, в русскоязычном сообществе используется «горутина», и в данном случая я просто следую оригиналу — где автор пишет «Go routine» вместо «goroutine» (что выглядит как некая игра слов), я перевожу как «Go рутина» соответственно.
«Go-процедура» — это совсем промт-стайл будет ) Тогда уже «горутина» будет удачнее, имхо.
А, да? Нет, операторы я не хотел учитывать, конечно же.
Вообще, уже понял, что было ошибкой считать «побольше языков». Изначально хотел сравнить только группу из 4-5 императивных языков, которые я рассматриваю, как универсальные кроссплатформенные языки для серверного софта — C++, Go, Python, Java, Ruby, но потом решил, что появится масса вопросов «А где язык X?» и решил добавить и остальные, тем более, что это было относительно просто.
Спасибо за критику по делу. Статья, конечно, популистская и холивары после тех графиков были неминуемы :) Но вообще, это ответ на комментарии из других статей, где меня доставали вопросами «а как ты докажешь, что Go проще C++». Впрочем, те же люди здесь сейчас вообще любое утверждение сводят к «а докажи? раз нет формального способа доказать 100% — значит ложь».
— Выбирать нужно то, что подойдёт для решения твоей задачи.
Это вы это понимаете, и я понимаю. Но реальность такова, что мне приходится сейчас увольняться из компании, потому что тим-лиды у нас ничего кроме С++ не знают, и знать не хотят, и пишут на нем всё — вопрос «выбора подходящего инструмента» там даже не стоит. Страдает продукт, страдает компания, страдают все. И судя, по комментариям, таких людей «одного языка» много.
Так что, даже если хотя бы один человек из-за таких популистских статей, решит взглянуть на Go и расширит круг своих познаний — я уже буду считать, что цель достигнута. Хотя, надоело конечно уже, план выполнен ))
Всё, я устал писать одинаковые комменты ) Признаю это как свой фейл.
Речь не в том, «сколько keyword-ов учить», а в том, что это кое-как коррелирует со сложностью языка, и это легко подсчитать, поэтому годится как одну из методик. Аргументы про «просто случайное распределение» я выслушал, понял, и не согласен.
Нет-нет, я пытаюсь этими графиками попробовать дать ответ на вопрос «А докажи, что Go проще C++ или Java?» людям, которые не пробовали Go, и считают все утверждения о простоте — выдумкой. То, сколько и кто и как едет — это уже тем отдельного холивара :)
Вот мы и пришли к тому, что в Go, фактически, два механизма обработки ошибок — error и panic. Выводы из этого занятны, но, в общем случае, сводятся к тому, что обработка ошибок в Go концептуально не отличается от аналогичной в других языках с поддержкой exceptions.
Спеку языка не читай, делай желаемые для себя выводы :) Ок.
Google — это авангард разработки ПО, они рождают новые технологии и языки, сталкиваются с проблемами и масштабами, с которыми другие столкнутся через 10 лет. Поэтому да, те, кому хватает для всех своих задач Perl-а и «всего за 3 часика написать деплой скрипт на баше» — те, конечно, будут считать точку зрения Google на проблематику разработки странной.
Я не знаю, откуда вы взяли, что я считаю «оценку количества keyword-ов» универсиальной теорией расчет сложности языков, применимую ко всем языкам, но я несколько раз это явно дал понять — единственный реальный метод _оценить_ сложность я вижу в совокупности нескольких оценочных методик, и проследить корелляцию.
И столько же раз написал, что да, прекрасно понимаю, насколько примитивной и грубой оценкой является первая методика, но при этом я, да, считаю что она не лишена оснований для группы императивных языков. Вы же не будете мне доказывать, что количество ключевых слов в C++ чисто случайно больше, чем в Go, и чисто случайно Go субъективно называется более простым?
Но если вы хотите гнуть свою линию «нет брейнфака — никакой взаимосвязи быть не может» — продолжайте, но мне странны такие доводы от логически мыслящих людей.
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
Ну, нет, я вообще хотел в список включить только 3-4 схожих по охвату и подходам языка. Вот, согласитесь, сложность Go vs С++ неспроста кореллирует с количеством ключевых слов в Go и C++ :)
Ставлю на Эмпирику.
С эмпирикой всё понятно, но её не докажешь, аргументы «я чувствую это по своему опыту» не работают.
Я писал многопоточный софт на boost и писал на Go — и это просто небо и земля. Пробовать обе технологии, или привязаться лишь к одной и её пропагандировать — это уже ваш выбор.
Если ребята написали этот пул с третьей попытке на Go, угадайте, как бы выглядело их «не пыхтеть» на C++/boost.
«Go-процедура» — это совсем промт-стайл будет ) Тогда уже «горутина» будет удачнее, имхо.
Вообще, уже понял, что было ошибкой считать «побольше языков». Изначально хотел сравнить только группу из 4-5 императивных языков, которые я рассматриваю, как универсальные кроссплатформенные языки для серверного софта — C++, Go, Python, Java, Ruby, но потом решил, что появится масса вопросов «А где язык X?» и решил добавить и остальные, тем более, что это было относительно просто.
Это вы это понимаете, и я понимаю. Но реальность такова, что мне приходится сейчас увольняться из компании, потому что тим-лиды у нас ничего кроме С++ не знают, и знать не хотят, и пишут на нем всё — вопрос «выбора подходящего инструмента» там даже не стоит. Страдает продукт, страдает компания, страдают все. И судя, по комментариям, таких людей «одного языка» много.
Так что, даже если хотя бы один человек из-за таких популистских статей, решит взглянуть на Go и расширит круг своих познаний — я уже буду считать, что цель достигнута. Хотя, надоело конечно уже, план выполнен ))
Речь не в том, «сколько keyword-ов учить», а в том, что это кое-как коррелирует со сложностью языка, и это легко подсчитать, поэтому годится как одну из методик. Аргументы про «просто случайное распределение» я выслушал, понял, и не согласен.
Спеку языка не читай, делай желаемые для себя выводы :) Ок.
И столько же раз написал, что да, прекрасно понимаю, насколько примитивной и грубой оценкой является первая методика, но при этом я, да, считаю что она не лишена оснований для группы императивных языков. Вы же не будете мне доказывать, что количество ключевых слов в C++ чисто случайно больше, чем в Go, и чисто случайно Go субъективно называется более простым?
Но если вы хотите гнуть свою линию «нет брейнфака — никакой взаимосвязи быть не может» — продолжайте, но мне странны такие доводы от логически мыслящих людей.
Ну, нет, я вообще хотел в список включить только 3-4 схожих по охвату и подходам языка. Вот, согласитесь, сложность Go vs С++ неспроста кореллирует с количеством ключевых слов в Go и C++ :)
С эмпирикой всё понятно, но её не докажешь, аргументы «я чувствую это по своему опыту» не работают.
Про большие и сложные проекты — посмотрите на Docker, достаточно большой.