Так вас никто и не заставляет. Если вам комфортно с С++, ваши задачи, временные рамки, коллеги и условия позволяют спокойно его использовать — в чём проблема?
… не хочу изучать все эти Go, Rust, D и ещё полтора десятка… Меня устраивает язык, которым я сейчас пользуюсь 95% времени, потому что считаю его лучшим из существующих на данный момент.
Отсюда и конфликт в дискуссиях. Я, к примеру, писал долгое время на С++, и уже 2.5 года пишу на Go, поэтому могу объективно сравнить оба языка. Вы же, из этих двух языках, на практике знаете лишь один, но считаете его лучше. Это необъективно. Любая ваша аргументация поэтому обречена быть чисто теоретической, а споры бессмысленными.
Ну как можно доказывать, что инструмент А, лучше инструмента Б, если вы никогда не держали в руке Б?
Чем больше библиотек, тем проще найти нужную и прикрутить в своё приложение вместо того, чтобы тратить время на имплементацию велосипеда, который уже писали тысячи человек до того… на других языках. Я хочу писать уникальную функциональность, а не очередную обёртку над threading API / библиотку для работы с UTF-8 строками / ещё какую-то фигню, которая сжирает кучу времени и без которой нельзя нормально реализовать высокоуровневую логику
Кстати, насчет «найти и прикрутить библиотеку» — в С++ этот процесс занимает в лучшем случае десятки минут (и то, если уже раньше с этой библиотекой работал) — найти, скачать, собрать, установить, прописать нужные пути импортов и линкера, разобраться в документации (которая у каждой либы по своему сделана), добавить код. И это редко работает гладко, обычно это возня на целый вечер.
В Go простота этого процесса доведена до предела и занимает секунды: одна команда «go get url-проекта» и одна строчка «import url-проекта» в коде. При этом все существующие библиотеки ищутся централизованно через godoc.org и там же всегда доступна стандартная форма документации, которая есть у подавляющего большинства библиотек в Go.
И если в С++ задача «попробовать 5 разных библиотек» занимала несколько дней, то в Go занимает несколько минут.
И так во многих других аспектах.
Ирония в том, что вы вроде бы понимаете, что хотите «писать уникальную функциональность», а не тратить время на возню с библиотеками и обертками. Но это именно то, на что в С++ уходит чересчур много времени.
И, да, UTF8, фантастическая конкурентность (threading API это жалкое подобие) и 90% «еще какой-то фигни», наличием библиотек для которых вы хвалитесь в С++ — в Go идёт из коробки, и очень хорошо продуманы. По факту, то, что есть в стандартной библиотеке Go достаточно для 80% современного системных/серверных софта.
Вобщем, мой поинт в том, что только поработав, и сравнив на личном опыте оба языка, вы сможете объективно их оценивать. Не раньше.
Более того, я надеюсь, что эти языки не взлетят и тихо загнутся.
Нет, «проблема в программистах» может быть в случае, когда у вас нет выбора языка. Если вы работаете в команде, где вам ставят жесткие условия на чём писать, или вы студент, которому нужно делать лабораторную именно на этом языке — тогда да, ваше утверждение справедливо.
Но если вы архитектор системы, если вы имеете возможность выбирать, какими инструментами и языками пользоваться, то у вас нет никакого оправдание для того, чтобы не знать и не понимать плюсы и минусы других, мейнстримовых и не только, языков. Аргумент «я потратил 7 лет, чтобы добиться приемлимой продуктивности на С++ и дело в программистах» уже не работает.
Поэтому дело именно в языке. «Добавочная сложность», которую привносит С++ в разработку для вас не кажется «сложностью», просто потому что вы к ней привыкли. В других языках, с которыми вы работали дела обстояли не намного лучше, поэтому это для вас некий baseline, это «норма». Но есть другие языки, которые вы не знаете (и, наверняка, не хотите по ряду вполне резонных причин), для которых эта «норма» давным давно уже неактуальна, в них уже своя норма, и, ценой компромиссов, «добавочная сложность» этих языков намного меньше.
И именно поэтому для многих людей, которые имеют возможность сравнивать, С++ уже однозначно является «переусложненным языком», причем сложность которого себя не окупает. А такие языки, как Go эти компромиссы ещё более уменьшают — настолько, что ниша С++ становится совсем уже узкой, да и ту Rust отбирает.
Извините, если где задел — я лишь пытаюсь подобрать правильные слова, чтобы помочь вам понять, почему столько людей (и я не только про Хабр, а про тех же авторов Go и Google) считают С++ «неоправданно сложным языком», а вы с этим не согласны.
В нем вопрос в том, насколько часто выполняется эта самая «синяя» фаза.
Насколько я понимаю, её частота зависит от того, сколько памяти аллоцирует программа. До Go 1.5 эту частоту можно было тюнить с помощью переменной GOGC, которая, по сути, выставляла порог (в процентах), когда уже пора запускать GC. Соответственно, для разных программ эта частота может быть очень разной.
Собственно, проблема с паузами релевантна только для высоконагруженных систем, которые лопатят гигабайты постоянно обновляемых данных в памяти (как в недавнем примере Qihoo 360). Для остальных случаев частота и продолжительность пауз нынешнего GC настолько низки, что абсолютно незаметны.
А по поводу материалов по предыдущим реализациям GC, надо искать в golang-nuts, были какие-то документы хорошие.
SOAP нынче стоит в одном ряду со словами «dead», «masocоstic» и «zombie», поэтому в стандартной библиотеке, конечно же его нет.
Посмотрите вот, какие-то пакеты есть, но более детально не подскажу: godoc.org/?q=soap
Не забывайте, что это перевод блогпоста, который «на коленке» записывает блоггер по ходу выступления докладчика.
Какая метрика используется для измерения?
Полагаю, что стандартный runtime.Memstats, в котором хранятся данные про паузы 256 последних срабатываний GC. Percentile или mean — не знаю, но, полагаю, что раз там была прямая корелляция, то mean там репрезентативен.
Не все так однозначно, господа.
Никто такого и не говорит. Но ваши рассуждения и вправду, гипотетические и неверные. 25% будут отбираться только для фазы GC, а не на время всей работы программы. Пересчитывайте :)
Такие вещи надо, как минимум, обосновывать. А еще лучше доказывать.
Есть вещи, которые нельзя формально доказать — что некоторые хабражители успешно используют в качестве аргумента («не смог доказать — значит это не так»).
Если бы Вам и вправду было интересно обоснование пользы простоты языков, Вы бы точно не пропустили сотни статей и десятки докладов на эту тему.
Я вас правильно понимаю — вы засовываете в «один процесс» C#, Java и V8, сознательно создавая, по вашему же утверждению, «адскую хрень» и потом заявляете, что проблема в GC?
Я достаточно давно работаю с С++, и никогда не имел проблем с С++
Но их имели программисты всего мира, включая программистов Google. Будь С++ таким, как вы его хотите видеть, не появился бы ни Go, ни Rust, все бы продолжали писать на С++, не сомневайтесь.
The duration of a blink is on average 100-150 milliseconds according to UCL researcher[3] and between 100-400ms according to the Harvard Database of Useful Biological Numbers
языки без GC — дружелюбны и просты в использовании, языки на GC — это, я извинюсь, п@#$ец на выезде
По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»? Извините, я тут даже не знаю тогда, с чего начать, и стоит ли вообще.
Не очень понял, каким образом «зоопарк» языков соотносится с вопросом оценки необходимости GC для каждого конкретного случая.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет. Обычно, они склоняются к какой-то одной позиции, упрощая всё до «GC — плохо» или «ручное управление памятью — зло».
На моем опыте, тут главная сложность именно в том, чтобы отличить, где важно отсутствие пауз, а где нет. Большинство сторонников языков без GC, занимают очень однобокую позицию, демонизируя GC и не понимая реалий компромиссов в разработке на языках с GC и без.
Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?
Ну там резолюция в секундах. На следующем графике видно, что на 0.5Гб куче около 2мс. Но если есть возможность уменьшить — почему бы и нет. Есть области, где и 2мс — много.
Есть реальность — Erlang-у уже достаточно лет, чтобы индустрия могла оценить его плюсы и минусы. Как по вашему, в чём причина того, что мейнстрим выбрал C++/Java вместо Erlang?
Это ваш взгляд. В Google уже 3+ млн строк кода на Go, включая многие ключевые сервисы.
Go очень сильно берет низким порогом входа, это правда. Я, кстати, считаю это одним из минусов Эрланга — если бы освоить эрланг у меня заняло пару вечеров, как и Go, я бы конечно так или иначе попробовал Эрланг где-нибудь в pet projects. А читать кучу книг и тратить месяцы, просто чтобы узнать — хорошая технология или нет — я просто не могу. И это не оправдание, это реалии — интересных технологий пруд пруди, и время входа тут очень сильное конкурентное преимущество (но не единственное, конечно же).
Фраза эта да, кривовато звучит. Думаю, на деле он хотел сказать, что они хотели попробовать для этого проекта Go, вместо Ruby (как я понял, это их основной стек был), потому что нужна была большая нагрузка.
А по поводу обожание Эрланга — Go не собирается никуда добираться. Он уже и сейчас дает людям возможность быстро получать качественный результат, с которым легко и приятно работать. Это единственное, что важно в конечном итоге.
Отсюда и конфликт в дискуссиях. Я, к примеру, писал долгое время на С++, и уже 2.5 года пишу на Go, поэтому могу объективно сравнить оба языка. Вы же, из этих двух языках, на практике знаете лишь один, но считаете его лучше. Это необъективно. Любая ваша аргументация поэтому обречена быть чисто теоретической, а споры бессмысленными.
Ну как можно доказывать, что инструмент А, лучше инструмента Б, если вы никогда не держали в руке Б?
Кстати, насчет «найти и прикрутить библиотеку» — в С++ этот процесс занимает в лучшем случае десятки минут (и то, если уже раньше с этой библиотекой работал) — найти, скачать, собрать, установить, прописать нужные пути импортов и линкера, разобраться в документации (которая у каждой либы по своему сделана), добавить код. И это редко работает гладко, обычно это возня на целый вечер.
В Go простота этого процесса доведена до предела и занимает секунды: одна команда «go get url-проекта» и одна строчка «import url-проекта» в коде. При этом все существующие библиотеки ищутся централизованно через godoc.org и там же всегда доступна стандартная форма документации, которая есть у подавляющего большинства библиотек в Go.
И если в С++ задача «попробовать 5 разных библиотек» занимала несколько дней, то в Go занимает несколько минут.
И так во многих других аспектах.
Ирония в том, что вы вроде бы понимаете, что хотите «писать уникальную функциональность», а не тратить время на возню с библиотеками и обертками. Но это именно то, на что в С++ уходит чересчур много времени.
И, да, UTF8, фантастическая конкурентность (threading API это жалкое подобие) и 90% «еще какой-то фигни», наличием библиотек для которых вы хвалитесь в С++ — в Go идёт из коробки, и очень хорошо продуманы. По факту, то, что есть в стандартной библиотеке Go достаточно для 80% современного системных/серверных софта.
Вобщем, мой поинт в том, что только поработав, и сравнив на личном опыте оба языка, вы сможете объективно их оценивать. Не раньше.
Ну тут без комментариев )
Но если вы архитектор системы, если вы имеете возможность выбирать, какими инструментами и языками пользоваться, то у вас нет никакого оправдание для того, чтобы не знать и не понимать плюсы и минусы других, мейнстримовых и не только, языков. Аргумент «я потратил 7 лет, чтобы добиться приемлимой продуктивности на С++ и дело в программистах» уже не работает.
Поэтому дело именно в языке. «Добавочная сложность», которую привносит С++ в разработку для вас не кажется «сложностью», просто потому что вы к ней привыкли. В других языках, с которыми вы работали дела обстояли не намного лучше, поэтому это для вас некий baseline, это «норма». Но есть другие языки, которые вы не знаете (и, наверняка, не хотите по ряду вполне резонных причин), для которых эта «норма» давным давно уже неактуальна, в них уже своя норма, и, ценой компромиссов, «добавочная сложность» этих языков намного меньше.
И именно поэтому для многих людей, которые имеют возможность сравнивать, С++ уже однозначно является «переусложненным языком», причем сложность которого себя не окупает. А такие языки, как Go эти компромиссы ещё более уменьшают — настолько, что ниша С++ становится совсем уже узкой, да и ту Rust отбирает.
Извините, если где задел — я лишь пытаюсь подобрать правильные слова, чтобы помочь вам понять, почему столько людей (и я не только про Хабр, а про тех же авторов Go и Google) считают С++ «неоправданно сложным языком», а вы с этим не согласны.
Насколько я понимаю, её частота зависит от того, сколько памяти аллоцирует программа. До Go 1.5 эту частоту можно было тюнить с помощью переменной GOGC, которая, по сути, выставляла порог (в процентах), когда уже пора запускать GC. Соответственно, для разных программ эта частота может быть очень разной.
Собственно, проблема с паузами релевантна только для высоконагруженных систем, которые лопатят гигабайты постоянно обновляемых данных в памяти (как в недавнем примере Qihoo 360). Для остальных случаев частота и продолжительность пауз нынешнего GC настолько низки, что абсолютно незаметны.
А по поводу материалов по предыдущим реализациям GC, надо искать в golang-nuts, были какие-то документы хорошие.
Посмотрите вот, какие-то пакеты есть, но более детально не подскажу: godoc.org/?q=soap
Вот еще статья на тему: taoofmac.com/space/blog/2014/05/11/1121
Полагаю, что стандартный runtime.Memstats, в котором хранятся данные про паузы 256 последних срабатываний GC. Percentile или mean — не знаю, но, полагаю, что раз там была прямая корелляция, то mean там репрезентативен.
Никто такого и не говорит. Но ваши рассуждения и вправду, гипотетические и неверные. 25% будут отбираться только для фазы GC, а не на время всей работы программы. Пересчитывайте :)
Есть вещи, которые нельзя формально доказать — что некоторые хабражители успешно используют в качестве аргумента («не смог доказать — значит это не так»).
Если бы Вам и вправду было интересно обоснование пользы простоты языков, Вы бы точно не пропустили сотни статей и десятки докладов на эту тему.
Тут уже было
Теперь ещё и rust.
Но их имели программисты всего мира, включая программистов Google. Будь С++ таким, как вы его хотите видеть, не появился бы ни Go, ни Rust, все бы продолжали писать на С++, не сомневайтесь.
Вики говорит другое:
По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»? Извините, я тут даже не знаю тогда, с чего начать, и стоит ли вообще.
Не очень понял, каким образом «зоопарк» языков соотносится с вопросом оценки необходимости GC для каждого конкретного случая.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет. Обычно, они склоняются к какой-то одной позиции, упрощая всё до «GC — плохо» или «ручное управление памятью — зло».
Да, в Google вообще недалекие люди работают, наверное просто не знают про Rust )
Ну там резолюция в секундах. На следующем графике видно, что на 0.5Гб куче около 2мс. Но если есть возможность уменьшить — почему бы и нет. Есть области, где и 2мс — много.
Go очень сильно берет низким порогом входа, это правда. Я, кстати, считаю это одним из минусов Эрланга — если бы освоить эрланг у меня заняло пару вечеров, как и Go, я бы конечно так или иначе попробовал Эрланг где-нибудь в pet projects. А читать кучу книг и тратить месяцы, просто чтобы узнать — хорошая технология или нет — я просто не могу. И это не оправдание, это реалии — интересных технологий пруд пруди, и время входа тут очень сильное конкурентное преимущество (но не единственное, конечно же).
А по поводу обожание Эрланга — Go не собирается никуда добираться. Он уже и сейчас дает людям возможность быстро получать качественный результат, с которым легко и приятно работать. Это единственное, что важно в конечном итоге.