Здравствуйте, Артём, Вы писали:

Аё>Тоже мне достижение
Аё>TLS SSH encryption

Здравствуйте, DiPaolo, Вы писали:

DP>Темчик, ты бы вот сам в плюсах взвыл бы.
Сях же

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, DiPaolo, Вы писали:

DP>>Темчик, ты бы вот сам в плюсах взвыл бы.
CC>Сях же

Твою ж мать Просто я в этой теме уже там много писал ему про плюсы, что теперь не могу переключиться

Аё>>>И не надо втирать, что вот ваша-то программа на плюсах — точно-точно без багов.

S>>А это кто-то утверждает?
Аё>DiPaolo

Вообще ничего подобного не говорил. Приведи пример со ссылкой.

Артём, вот уже не первый раз замечаю, что ты отвечаешь на небольшую часть аргументов, а большущие такие весомые аргументы скипаешь. Вот тебе внизу аргументы, которые ты скипнул, зацепившись за что-то другое удобное тебе. Ты послушай оппонентов. В противном случае выходит, что тебе лишь бы обхаять. Мне лично уже наскучивает. Это не дискуссия получается, а борьба с ветряными мельницами. Поначалу было интересно, но уже нет. С тобой элементарно неинретерсно разговаривать. Твоя позиция предельно ясна. И вытащить тебя в русло конструктивной дискуссии не выходит. Ты даже на вопрос, почему стоит использовать электрон а не флаттер (вопрос без подвоха был абсолютно), съехал на тему, что плюсы при этом на бэке точно не нужны

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

Что вот ты думаешь про это?

Аё>>Ну сделать веб сервис отдельным процессом на Go например. Или на Node.

аргумент раз
DP>И как это получать из плюсовой коры? То есть делать отдельно прослойку для в-принципе простого функционала? Но при этом сделать еще оверхед на прокачку данных между корой и веб-сервером??? Смысла нет. Может еще кубернетис туда втащить??? Еще раз: основная цель — промолотить как можно больше данных в риал-тайме. Ну грубо говоря — обработать пару-тройку мультиплексов (порядка 40-60 ТВ каналов) на одном устройстве одновременно. А кора завязана на ряд плюсовых либ. бода тут вообще из пушки по воробьям.

два
DP>И кода для работы со всем этим на Си/плюсах гораздо больше, чем на го. И они уже давно отточены. На них можно положиться в плане качества, и понимаешь, что от них ждать по скорости.

вот такой не про сам язык аргумент
DP>Ты еще не учитываешь такой фактор, как имеющиеся компетенции разработчиков. Когда страхуемся проект, ты не можешь просто взять и нанять нового человека на Го, чтобы он сделал сервис. А чем он потом будет заниматься? В итоге дешевле именно так. Потому что в продуктовых компаниях обычно плюс-минус устоявшийся стек и набор разработчиков под него. К тому же, есть принятые стандарты в индустрии и 3rd party libraries, который сплошь и рядом на Си и плюсах + SIMD. Найти в области обработки видео (речь про низкоуровневые вещи, а не онлайн-кинотеатр) разработчика на Го — та еще задача. И занять его потом работой — тоже.

вот тут про Го, почему он лучше плюсов
DP>Артем, Го такой крутой не потому что он (подставь тут свои плюсы языка), а в первую очередь из-за инфраструктуры для веб-разработки. Кубернетис и куча всего остального в плане инфраструктуры использует Го. А это значит, что твой разработчик сервиса легко пофиксит или допилит какой-то ДевОпсовский сервис при необходимости. Ну и не надо забывать про маркетинговый аспект. Он тоже играет роль. Гугл распиарил Го. Многие просто думают, что Го крутой, "патамушта Гугол".

и еще почему Го хорош и что он также может стать не у дел
DP>В Го изначально было заложено меньше возможностей, более узкая специализация — создавать веб-сервисы (в первую очередь) быстро и безопасно, с низким порогом входа, но при этом, чтобы это достаточно быстро работало. Но при этом приходится чем-то жертвовать. Го не такой гибкий, не все на нем можно сделать. Это цена, которую платят за выполнение функций, которые ставились перед языком. И вот уже к версии 1.19 уже втащили генерики. Подождем еще пару-тройку-пяток лет и в версия эдак 3 будет такой же монструозной, как и плюсы. А еще может будет несколько ответвлений, какой-нить Go++ и т.д. И вот я вижу как ты через 10 лет хуесо накидываешь на Го++, какой он гавно, а вот <новый_модный> — это тру и надо пользовать его.

Здравствуйте, DiPaolo, Вы писали:

DP>Твоя позиция предельно ясна. И вытащить тебя в русло конструктивной дискуссии не выходит.

В первый раз с Тёмчиком спорить пытаетесь?

S>В первый раз с Тёмчиком спорить пытаетесь?

Когда более двух ответов ему в одной теме — да

До этого я в основном его читал: про лансер, пляж, пышногрудых девиц, лучшие субурбии Автралии и прочее В них, кстати, он тоже отличается непонятной упоротостью

Здравствуйте, DiPaolo, Вы писали:

Очень много написано. Все поскипал, извини.
Да, на C и на C++ есть готовые, обкатанные годами библиотеки. Зато Go лучше подходит для микросервиса (хотя у тебя там BFF, ну да ладно).
Ну так почему бы не взять хорошее оттуда и оттуда. Это не вопрос, а утверждение. К тому же, всемогутор- это антипаттерн (это безотносительно, на чем писали), т.е. весьма красноречиво говорит о невысоком техническом уровне команды.

Интеграция C в Go: https://pkg.go.dev/cmd/cgo

Здравствуйте, CreatorCray, Вы писали:

Аё>>Ну так и на C++ точно так же насрать. Рендерингом занимается не он.
CC>А вот тут ты как раз не прав

Еще раз, для непонятливых- что C++ код, что JS код, отправляют в GPU шейдер и она там, в GPU, исполняется.
Поэтому насрать на C++

Здравствуйте, DiPaolo, Вы писали:

Аё>>>>И не надо втирать, что вот ваша-то программа на плюсах — точно-точно без багов.

S>>>А это кто-то утверждает?
Аё>>DiPaolo

DP>Вообще ничего подобного не говорил. Приведи пример со ссылкой.

DP> Конечно мы это предусмотрели и сделали так, чтобы ничего не падало. Не надо думать, что в Го ничего не может упасть. Да, можно все обмазать всякими докерами, кибернетисами. Но это сразу отъест кучу ресурсов. А еще раз: в той системе важна была риал-таймовая пропускная способность. Каждый мегабайт был на счету.

http://rsdn.org/forum/job/8339660?tree=tree

Автор: DiPaolo
Дата: 20.08.22

Это такая особенность C++, что оно может портить память и течь. И если в C оно хотя бы простое, как кирпич- в C++ дизайн языка провоцирует запутывать логику. UB утыканы конструкторы, деструкторы и exceptions. Перегрузка операторов- приколько использовать, но весьма эфыективно запутывает, когда "что то пошло не так".

Здравствуйте, Артём, Вы писали:

Аё>Это такая особенность C++, что оно может портить память и течь. И если в C оно хотя бы простое, как кирпич- в C++ дизайн языка провоцирует запутывать логику. UB утыканы конструкторы, деструкторы и exceptions. Перегрузка операторов- приколько использовать, но весьма эфыективно запутывает, когда "что то пошло не так".

Признайся, что ты просто не осилил плюсы.

ЗЫ Вообще, я в реале однажды видел одного такого хейтера плюсов, с практически такой же аргументацией. Он писал на чистой сишечке. Это был 60ти-летний дед. Ну как дед, крепкий тащем-то мужик, на охоту любил ездить на своем ланцерена своей ниве , муай-тай, наверное, опять же. Правда, на код, который он и его бабы писали, без слез смотреть было нельзя. Обнять и плакать. А "его бабы" — это потому, что у него в отделе одни бабы работали, парни там не задерживались, потому что у парней имелось своё мнение, а он такого не терпел.

Здравствуйте, DiPaolo, Вы писали:

DP>Твою ж мать Просто я в этой теме уже там много писал ему про плюсы, что теперь не могу переключиться
Артёмка он такой, да!

M>ЗЫ Вообще, я в реале однажды видел одного такого хейтера плюсов, с практически такой же аргументацией. Он писал на чистой сишечке. Это был 60ти-летний дед.

Молодец дед. На таких зачастую и держатся всякие ценные вещи. Может четко сказать "нет" увеличению сложности там, где оно не требуется. Читать и поддерживать чистый (если он в самом деле чистый) Си весьма удобно — особенно с текучкой кадров. Чем проще написано, тем проще поддерживать.

У С++, как уже верно заметили, ниша для написания новых продуктов довольно узкая. Там, где совсем низкоуровневые вещи (как тут уже приводили куски ffmpeg'а), С++ не особо и нужен, хватает чистого С. А там, где нужно высокоуровневую логику, есть и соответствующие высокоуровневые языки.
С++ в итоге ни нашим, ни вашим. Сложный (сложнее С), многобуквенный (не Java, но все же), требующий некоторых ухищрений для ускорения компиляции и т.п.. Если б не мегатонны уже написанного добра, С++ последовал бы вслед за многими другими артефактами прошлого.

Здравствуйте, SkyDance, Вы писали:

SD>Молодец дед. На таких зачастую и держатся всякие ценные вещи.

До тех пор пока дед не станет на лыжи (или не помрет). Зачастую после таких авторитарных товарищей все рассыпается, т.к.:

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

— за оставленный в наследство код никто не хочет брать ответственность.

SD>Может четко сказать "нет" увеличению сложности там, где оно не требуется.

Как будто это специфично только для C++. На других языках, надо полагать, накрутить искусственной сложности на ровном месте никак нельзя. Да, да, верим, верим, безусловно верим.

lavrov.jpg

SD>Читать и поддерживать чистый (если он в самом деле чистый) Си весьма удобно — особенно с текучкой кадров. Чем проще написано, тем проще поддерживать.

Тут следовало бы вставить сразу несколько характерных картинок с Лавровым, но достаточно указать, что на самом деле должно быть два условия:

— должен быть чистый код на Си;

— этого кода должно быть немного.

А, поскольку что-то более менее серьезное на Си требует просто дохренища кода, то и приходим к актуальной реальности.

SD>Там, где совсем низкоуровневые вещи (как тут уже приводили куски ffmpeg'а), С++ не особо и нужен, хватает чистого С.

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

Чтобы не быть голословным. Берем отлично написанный и проверенный годами в продакшене C-шный код.

Смотрим раз: https://github.com/greenplum-db/gpdb/blob/02f2a3f39abefa8f7cb24c392d59d0d7be8b8495/src/backend/cdb/motion/ic_udpifc.c#L116-L133

#define MAX_TRY (11)
int
            timeoutArray[] =
{
    1,
    1,
    2,
    4,
    8,
    16,
    32,
    64,
    128,
    256,
    512,
    512                            /* MAX_TRY */
};
#define TIMEOUT(try) ((try) < MAX_TRY ? (timeoutArray[(try)]) : (timeoutArray[MAX_TRY]))

А что будет, если кто-то увеличит MAX_TRY, но не изменит timeoutArray?

Смотрим два: https://github.com/greenplum-db/gpdb/blob/02f2a3f39abefa8f7cb24c392d59d0d7be8b8495/src/backend/cdb/motion/ic_udpifc.c#L889-L914

snprintf(tmpbuf, 32, "%d." UINT64_FORMAT "txt", MyProcPid, getCurrentTime());

А что это у нас за UINT64_FORMAT? А что, если мы вместо него напишем просто "%ld"?

FILE       *ofile = fopen(tmpbuf, "w+");

А почему проверки возвращенного значения для fopen нет?

    pthread_mutex_lock(&trans_proto_stats.lock);
    while (trans_proto_stats.head)
    {
....
    }

    trans_proto_stats.tail = NULL;

    pthread_mutex_unlock(&trans_proto_stats.lock);

А что, если у нас со временем внутри while какой-то return появится?

И, если этот return появится, то кто будет закрывать ofile?

Смотрим три: https://github.com/greenplum-db/gpdb/blob/02f2a3f39abefa8f7cb24c392d59d0d7be8b8495/src/backend/cdb/motion/ic_udpifc.c#L1626-L1636
https://github.com/greenplum-db/gpdb/blob/02f2a3f39abefa8f7cb24c392d59d0d7be8b8495/src/backend/cdb/motion/ic_udpifc.c#L1696-L1699
https://github.com/greenplum-db/gpdb/blob/02f2a3f39abefa8f7cb24c392d59d0d7be8b8495/src/backend/cdb/motion/ic_udpifc.c#L1767-L1770

Выделение и освобождение памяти выполняется по-разному в зависимости от условия.
Сделать отдельную вспомогательную функцию, которая бы выполняла if(ht->ctx) и делала бы выбор в пользу pfree или free не получилось. Нужно все вручную делать там, где требуется освободить память. И, конечно же, никто не забудет:

a) освободить память вообще;
b) сделать это должным образом с учетом ht->ctx.

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

SD>С++ в итоге ни нашим, ни вашим. Сложный (сложнее С)

Понятно.

Здравствуйте, SkyDance, Вы писали:

SD>Читать и поддерживать чистый (если он в самом деле чистый) Си весьма удобно — особенно с текучкой кадров. Чем проще написано, тем проще поддерживать.
ЛОЛ!
Ты похоже давно не видел какие вырвиглазные макаронные монстры пишут "текучие кадры" на чистом С.

CC>Ты похоже давно не видел какие вырвиглазные макаронные монстры пишут "текучие кадры" на чистом С.

Теперь представь, что эти же кадры сделают из С++
Я видел. На С макароны хотя бы не слипшиеся.

Здравствуйте, SkyDance, Вы писали:

SD>Теперь представь, что эти же кадры сделают из С++
Такие кадры будут писать на С++ как на С, причём буквально.
Так что один фиг.
Но в плюсах их попроще огородить заборчиком.

Здравствуйте, SkyDance, Вы писали:

SD>Теперь представь, что эти же кадры сделают из С++

Ну т.е. проблема вовсе не в языке.

Здравствуйте, Артём, Вы писали:

Аё>Это такая особенность C++, что оно может портить память и течь.

Всё, где в C++ течёт и портит память, унаследовано от C и возникает в коде в стиле C.

Аё> И если в C оно хотя бы простое, как кирпич- в C++ дизайн языка провоцирует запутывать логику.

Ну да, конечно, лучше терпеть всякие set_rp_trr_pkt_rate() вместо простого p->set_rate().
Лучше делать отдельную функцию инициализации (которую половина забудет вызвать, а ревьюеры наплюют) вместо дефолтного значения прямо при объявлении переменной в C++11.
Лучше следить, на какой из 50 веток return надо освобождать какие структуры (и при каждом добавлении забывать это проапдейтить на половине из таких веток), чем положиться на RAII.
Ибо C forevah, а C++ — монстр из ада.

Аё> UB утыканы конструкторы, деструкторы и exceptions.

И конечно, лучше забыть что-то инициализировать или очистить (создав в C множество таких же UB), чем пользоваться C++, где хотя бы можно форсировать политику адекватного управления.

Аё> Перегрузка операторов- приколько использовать, но весьма эфыективно запутывает, когда "что то пошло не так".

Так а кто от тебя требует что-то перегружать?

Здравствуйте, netch80, Вы писали:

Аё>> Перегрузка операторов- приколько использовать, но весьма эфыективно запутывает, когда "что то пошло не так".

N>Так а кто от тебя требует что-то перегружать?

С этим-то как раз все понятно: есть в Интернетах масса людей, которые убеждены, что если ты не используешь сразу все фичи C++, то это у тебя уже и не C++вовсе.

Возможно, отчасти это навеяно тем, что новички в языке часто стремятся задействовать в коде все, что успели выучить. Что, в общем-то, обычное дело для неофитов безотносительно языка программирования. Просто в C++ из-за обилия возможностей, это страшнее, чем в какой-нибудь условной Java.