Здравствуйте, lpd, Вы писали:
lpd>Скорее всего, отсутствие сборки мусора — одна из основных причин, почему из бэкенда и вытеснили С++. Никто не хочет в большой программе при добавлении каждого нового указателя думать, а не получится ли кольцевая сылка. Зачем это?
Ручное управление памятью -- это не большая проблема, иначе хайпа вокруг Rust-а не было бы.
Гораздо страшнее, что C++ никак не защищает разработчика от ошибок. Ни во время компиляции (например, не все компиляторы будут ругаться на возврат ссылки/указателя на локальный объект), ни, что важнее, во время работы. Из-за чего расстрел памяти, двойное ее освобождение или обращение по "повисшему" указателю может возыметь отложенные последствия в совсем другой части программы. Что делает поиск таких ошибок тяжелым занятием с непредсказуемыми сроками и затратами.
Безопасные языки с GC же полностью освобождают разработчика от подобных забот. Это же пытается делать и Rust, но сильно по-другому, нежели языки с GC.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>Скорее всего, отсутствие сборки мусора — одна из основных причин, почему из бэкенда и вытеснили С++. Никто не хочет в большой программе при добавлении каждого нового указателя думать, а не получится ли кольцевая сылка. Зачем это?
S>Ручное управление памятью -- это не большая проблема, иначе хайпа вокруг Rust-а не было бы.
Начинающие программисты считают, что чем сложней язык, тем они круче, раз на нем пишут. Поэтому очень сомневаюсь, что Rust реально будет распространен.
S>Безопасные языки с GC же полностью освобождают разработчика от подобных забот. Это же пытается делать и Rust, но сильно по-другому, нежели языки с GC.
Ну вот поэтому GC и популярен. Причем не у горстки энтузиастов, а ява реально упрощает жизнь на практике. А С++ уже давно уступил бэкенд, и не предвидится там, судя по направлению новых фич.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>Но на основании этих примеров делать заявление
Скажем прямо, мое утверждение обосновано, я понимаю о чем говорю, но вот, что тебя заставляет рассуждать о том, о чем ты вообще не понимаешь — загадка.
S>почему стоимость владения на С++ оказалась меньше чем у Python
Потому, что стоимость 700 серверов + стоимость их эксплуатации + команда DevOps для их обслуживания будет выше аналогичных расходов для 40 серверов.
Здравствуйте, lpd, Вы писали:
SVZ>>Короче, С++ требует более вдумчивого проектирования. Ява с Шарпом прощают больше
lpd>Ну так это недостаток С++, который и ограничивает его область применения. Скорее всего, отсутствие сборки мусора — одна из основных причин, почему из бэкенда и вытеснили С++.
Во-первых, из бэкенда С++ никто не вытеснял. Бэкенд — он разный бывает.
Есть большая ниша, где код педалить надо побыстрее, рабочая сила нужна подешевше, условия меняются, деплоить надо поскорее... а время отклика упирается во время чтения данных из СУБД.
Там рулят ява с шарпом.
lpd>Никто не хочет в большой программе при добавлении каждого нового указателя думать, а не получится ли кольцевая сылка. Зачем это?
Тут ключевое: "никто не хочет думать" При правильно выбранной архитектуре думать не надо, делаешь по образу и подобию.
lpd>Я не особенно опытный архитектор, но как-то писал сервер для мобильных клиентов на С++, и круговые ссылки там были(умные указатели, естественно, не использовал).
Круговые ссылки ессно нужны, иначе как ты получишь доступ от дочернего объекта к родителю.
Но они не должны влиять на время жизни объектов.
lpd>Язык должен позволять выразить любую архитектуру, причем простым и удобным образом. А не требовать от разработчиков соблюдать какие-то искуственные правила, усложняя их жизнь разнообразием видов weak/shared/unique поинтеров.
Ну вообще-то не должен.
В каждом языке есть свои плюсы и минусы. Универсального всемогутора не получится. D был неплохой кандидат, но чегой-то не взлетает.
В Яве мне нравилась иммутабельность объектов и атомарность присваивания ссылок. Для многопоточного кода — просто супер.
Но зато хрен ты сделаешь cache-friendly данные. Для Явы/шарпа это будет жутким извратом, зато на С/С++ получается естественным образом.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, lpd, Вы писали:
S>>Ручное управление памятью -- это не большая проблема, иначе хайпа вокруг Rust-а не было бы. lpd>Начинающие программисты считают, что чем сложней язык, тем они круче, раз на нем пишут. Поэтому очень сомневаюсь, что Rust реально будет распространен.
Суть не в том, какие перспективы у Rust-а. Суть в том, что если ручное управление памятью сопровождается жестким контролем за действиями пользователя (путь даже на уровне контроля за выходами за пределы массивов в run-time), то прикладная разработка сильно упрощается. Не смотря на ручное управлению памятью. Это было видно в свое время на примере Pascal/ObjectPascal/Delphi.
lpd>А С++ уже давно уступил бэкенд, и не предвидится там, судя по направлению новых фич.
Тут есть вопрос в том, а должен ли был C++ использоваться вообще на бэкенде или он там волею случая оказался?
Плюс особой пикантности ситуации добавляет то, что в том же бэкенде Java при увеличении нагрузки заменяют на C++.
Здравствуйте, Denis Ivlev, Вы писали:
S>>Но на основании этих примеров делать заявление
DI>Скажем прямо, мое утверждение обосновано, я понимаю о чем говорю
То, что у вас завышенное самомнение и отсутствие саморефлексии на тему того, насколько соответствуют ваши предположения о собеседниках реальности, не делает вас правым. Как и не является доказательством заявление "я понимаю о чем говорю".
Что касается вашего наброса о том, откуда предположения о соотношении себестоимости эксплуатации 700 серверов против оной у 40, то это для вас домашнее задание на уровне школьной арифметики начальных классов.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>Во-первых, из бэкенда С++ никто не вытеснял. Бэкенд — он разный бывает.
Разный бэкенд? Ну может <10% на C++, больше не видел.
SVZ>Есть большая ниша, где код педалить надо побыстрее, рабочая сила нужна подешевше, условия меняются, деплоить надо поскорее... а время отклика упирается во время чтения данных из СУБД. SVZ>Там рулят ява с шарпом.
Ну о том и речь. А С++ сейчас в основном только в десктоп-софте, иначе никаких гигагерцев и гигабайтов не хватит.
lpd>>Никто не хочет в большой программе при добавлении каждого нового указателя думать, а не получится ли кольцевая сылка. Зачем это?
SVZ>Тут ключевое: "никто не хочет думать" При правильно выбранной архитектуре думать не надо, делаешь по образу и подобию.
Для "правильности" архитектуры критериев много. Ты зачем-то добавляешь требования умных указателей(отсутствие круговых ссылок), хотя оно вполне может противоречить более важным критериям архитектуры в некоторых случаях.
lpd>>Я не особенно опытный архитектор, но как-то писал сервер для мобильных клиентов на С++, и круговые ссылки там были(умные указатели, естественно, не использовал).
SVZ>Круговые ссылки ессно нужны, иначе как ты получишь доступ от дочернего объекта к родителю. SVZ>Но они не должны влиять на время жизни объектов.
Не понял. С умными указателями зависимость между круговыми ссылками и временем жизни объектов прямая. А ссылается на В, В обратно ссылается на А. У обоих счетчик ссылок будет =1, если не использовать weak_ptr. Я что-то упустил?
lpd>>Язык должен позволять выразить любую архитектуру, причем простым и удобным образом. А не требовать от разработчиков соблюдать какие-то искуственные правила, усложняя их жизнь разнообразием видов weak/shared/unique поинтеров.
SVZ>Ну вообще-то не должен.
Тут мы приходим к объективным требованиям и предпочтениям. Сложности в софте обычно достаточно и без умных указателей, поэтому лишняя головная боль не нужна.
SVZ>В каждом языке есть свои плюсы и минусы. Универсального всемогутора не получится. D был неплохой кандидат, но чегой-то не взлетает.
Не все, а бэкенд и десктоп можно было бы писать на одном и том же — не вижу сложностей кроме легаси.
SVZ>В Яве мне нравилась иммутабельность объектов и атомарность присваивания ссылок. Для многопоточного кода — просто супер. SVZ>Но зато хрен ты сделаешь cache-friendly данные. Для Явы/шарпа это будет жутким извратом, зато на С/С++ получается естественным образом.
Яву лично я не люблю даже не из-за скорости, а из-за самого наличия JVM и промежуточного представления кода. Но это вопрос вкуса.
А размещение данных в памяти считаю элементарной необходимой для любого языка общего назначения вещью, которую в яве и c# убрали без серьезных причин, обосновывая байт-код ненужной на практике портабельностью.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>То, что у вас завышенное самомнение и отсутствие саморефлексии на тему того, насколько соответствуют ваши предположения о собеседниках реальности, не делает вас правым. Как и не является доказательством заявление "я понимаю о чем говорю".
Рефлексии у меня на двоих и утверждения я делаю только о том, что мне хорошо знакомо и если неправ, признаю неправоту, но для этого нужны аргументы с чем, у среднестатистического рсдн-овца как-то не очень.
А вот как с рефлексией у тебя? Вот эта бредятина про 700 серверов против 40, она откуда высосана?
S>Что касается вашего наброса о том, откуда предположения о соотношении себестоимости эксплуатации 700 серверов против оной у 40, то это для вас домашнее задание на уровне школьной арифметики начальных классов.
Демагогия, такая демагогия. Сначала докажи свое утверждение, а потом предлагай заняться арифметикой.
Здравствуйте, Denis Ivlev, Вы писали:
DI>Рефлексии у меня на двоих и утверждения я делаю
В этом-то и проблема.
DI>Вот эта бредятина про 700 серверов против 40, она откуда высосана?
Во-первых, из самого факта переписывания части инфраструктуры Instagram-а с Python на C++ и сопутствующей этому информации. Во-вторых, из некоторого представления о том как тратятся деньги в ИТ-ных компаниях. В-третьих, из каких-то остаточных знаний из школьного курса математики, которые позволяют сделать простое умножение и сложение с последующим сравнением.
Хотя сомневаюсь, что вас это убедит. Так что не буду даже и пытаться.
Здравствуйте, so5team, Вы писали:
DI>>Рефлексии у меня на двоих и утверждения я делаю
S>В этом-то и проблема.
Ты уж определись, мне рефлексировать или нет?
DI>>Вот эта бредятина про 700 серверов против 40, она откуда высосана?
S>Во-первых, из самого факта переписывания части инфраструктуры Instagram-а с Python на C++ и сопутствующей этому информации.
То есть ты где-то услышал звон? Ну дай ссылку почитать, что там на самом деле произошло. Так-то и мы в вконтактике в свое время транслятор из пхп в плюсы сделали, что вообще никак не значит, что там пишут на плюсах.
S>Во-вторых, из некоторого представления о том как тратятся деньги в ИТ-ных компаниях.
У тебя представления, а у меня знания — это сильно разное.
S>В-третьих, из каких-то остаточных знаний из школьного курса математики, которые позволяют сделать простое умножение и сложение с последующим сравнением.
То есть тезис полностью высосан и ты совершенно не в курсе о чем ты говоришь.
S>Хотя сомневаюсь, что вас это убедит. Так что не буду даже и пытаться.
Это? Не убедит конечно, зачем мне слушать фантазии, если я в этом бизнесе давно и знаю как оно?
Здравствуйте, lpd, Вы писали:
lpd>А размещение данных в памяти считаю элементарной необходимой для любого языка общего назначения вещью, которую в яве и c# убрали без серьезных причин
Здравствуйте, Denis Ivlev, Вы писали:
DI>То есть ты где-то услышал звон?
Об этом факте сами разрабы писали: https://instagram-engineering.com/c-futures-at-instagram-9628ff634f49
Остальное было разбросано по интернету в обсуждениях на разных ресурсах.
DI>Так-то и мы в вконтактике в свое время транслятор из пхп в плюсы сделали, что вообще никак не значит, что там пишут на плюсах.
Мне сложно понять, как "сделать что-нибудь на плюсах" не означает, что "на плюсах пишут". Но у вас какое-то свое представление о логике.
DI>У тебя представления, а у меня знания — это сильно разное.
И вы говорите, говорите.
S>>В-третьих, из каких-то остаточных знаний из школьного курса математики, которые позволяют сделать простое умножение и сложение с последующим сравнением.
DI>То есть тезис полностью высосан и ты совершенно не в курсе о чем ты говоришь. DI>Это? Не убедит конечно, зачем мне слушать фантазии, если я в этом бизнесе давно и знаю как оно?
Ну расскажите мне о закупочной стоимости партии в 700 серверов и 40. И о стоимости аренды площадей для их размещения. О стоимости сетевой инфраструктуры для их эксплуатации (и не только сетевой). О расходах на электроэнергию. Об амортизации, ремонтах и пр.
Даже не будем касаться покупки лицензий на софт для всего этого хозяйства и о зарплатах людей, которые все это будут обслуживать.
Да и вообще, не пора ли вам просто взять и объявить длину в сантиметрах? Вы ведь давно уверены, что здесь вам конкурентов просто нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, lpd, Вы писали:
lpd>>А размещение данных в памяти считаю элементарной необходимой для любого языка общего назначения вещью, которую в яве и c# убрали без серьезных причин
НС>Что именно убрали из C#?
Убрали прямое соответствие между кодом/данными и содержимым памяти. По крайней мере, для структур и классов.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
SVZ>>Во-первых, из бэкенда С++ никто не вытеснял. Бэкенд — он разный бывает.
lpd>Разный бэкенд? Ну может <10% на C++, больше не видел.
Для веба, когда надо строки из субд в сокет переложить, хватит и манагед языков.
Для VoIP'а, для числодробилок, для нетривиальной обработки под нагрузкой используют С/С++.
Ибо когда на одном выравнивании данных можно прибавить производительности в пару порядков, уже начинаешь задумываться
lpd>>>Никто не хочет в большой программе при добавлении каждого нового указателя думать, а не получится ли кольцевая сылка. Зачем это?
SVZ>>Тут ключевое: "никто не хочет думать" При правильно выбранной архитектуре думать не надо, делаешь по образу и подобию.
lpd>Для "правильности" архитектуры критериев много. Ты зачем-то добавляешь требования умных указателей(отсутствие круговых ссылок), хотя оно вполне может противоречить более важным критериям архитектуры в некоторых случаях.
Я добавляю???
Вот это поворот!
А что, для избежания круговых ссылок, кроме shared+weak pointer'ов, способов не существует?
Я уже ранее писал, что проблема возникает из-за передачи владения объектом. Ограничь владение объектом, задай графу связей направленность и проблема уходит.
SVZ>>Круговые ссылки ессно нужны, иначе как ты получишь доступ от дочернего объекта к родителю. SVZ>>Но они не должны влиять на время жизни объектов.
lpd>Не понял. С умными указателями зависимость между круговыми ссылками и временем жизни объектов прямая. А ссылается на В, В обратно ссылается на А. У обоих счетчик ссылок будет =1, если не использовать weak_ptr. Я что-то упустил?
Написал выше.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>Для веба, когда надо строки из субд в сокет переложить, хватит и манагед языков. SVZ>Для VoIP'а, для числодробилок, для нетривиальной обработки под нагрузкой используют С/С++. SVZ>Ибо когда на одном выравнивании данных можно прибавить производительности в пару порядков, уже начинаешь задумываться
Я не фанатик С++ — хотите чтобы это был нишевой язык для быстрых вычислений — ваше дело.
Просто я не люблю JVM с байт кодом, и думаю что для всякого бэкенда обычный язык вроде C++98+GC(или D) подошел бы лучше.
SVZ>Я уже ранее писал, что проблема возникает из-за передачи владения объектом. Ограничь владение объектом, задай графу связей направленность и проблема уходит.
Ограничь владение объектом что значит и задать графу связей направленность — не то же самое, что убрать круговые ссылки? Вместо [A->B;B->A] только [A->B]?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
из самого факта переписывания части инфраструктуры Instagram-а с Python на C++
DI>>Так-то и мы в вконтактике в свое время транслятор из пхп в плюсы сделали, что вообще никак не значит, что там пишут на плюсах.
S>Мне сложно понять, как "сделать что-нибудь на плюсах" не означает, что "на плюсах пишут". Но у вас какое-то свое представление о логике.
Ты пишешь на плюсах, плюсы компилируются в ассемблер. Следует ли из этого, что ты пишешь на ассемблере?
DI>>То есть тезис полностью высосан и ты совершенно не в курсе о чем ты говоришь.
S>Ну расскажите мне о закупочной стоимости партии в 700 серверов и 40. И о стоимости аренды площадей для их размещения. О стоимости сетевой инфраструктуры для их эксплуатации (и не только сетевой). О расходах на электроэнергию. Об амортизации, ремонтах и пр.
Сначала тезис 700 против 40 надо доказать. Без доказательств господин демагог получает ссаную тряпку.
S>Да и вообще, не пора ли вам просто взять и объявить длину в сантиметрах? Вы ведь давно уверены, что здесь вам конкурентов просто нет.
Ну фрилансер из провинции, у которого нет денег на нормальный ноут точно не конкурент.
DI>из самого факта переписывания части инфраструктуры Instagram-а с Python на C++
Там все именно про это. А в заключении английским по белому написано:
We were able to increase the peak CPU utilization of the Suggested User service from 10–15% to 90% per instance. This enabled us to reduce the number of instances of the Suggested Users service from 720 to 38.
Не умеете работать с источниками, не надо. Не учить же того, кто "в этом бизнесе давно и знаю как оно", в самом-то деле.
S>>Мне сложно понять, как "сделать что-нибудь на плюсах" не означает, что "на плюсах пишут". Но у вас какое-то свое представление о логике.
DI>Ты пишешь на плюсах, плюсы компилируются в ассемблер.
Во-первых, нет.
DI>Следует ли из этого, что ты пишешь на ассемблере?
Во-вторых, из ложных предположений проистекают ложные выводы.
DI>Сначала тезис 700 против 40 надо доказать.
Научитесь работать с источниками.
DI>Ну фрилансер из провинции, у которого нет денег на нормальный ноут точно не конкурент.
О, да вы плюс ко всему еще и столичная штучка. Тогда вам может быть не ведомо, что в век глобализации без разницы, где разработан софт и где он используется.
