Организованное программирование

Друзья, привет. Это подкаст Организованное программирование. С вами его ведущий Кирилл Мокевнин. Сегодня у меня в гостях Дмитрий Свериткин, с которым мы поговорим про C++. Давно не говорили про языки. Вот, наконец-то, значит, дошли сразу взяли по хардкору. Дима работает в инженером-программистом в Amazon Webсвиes. Сейчас он немножко про себя расскажет. И вообще много в Твиттере пишет. В общем-то, я через через Twitter, наверное, больше тебя и увидел и узнал, но при этом я вижу, что как бы история про C++, она и про Раст в последнее время, да, она очень-очень много крутится вокруг того, что ты делаешь. И поэтому мы здесь с тобой, собственно, собрались.

Плюс я знаю, что ты написал книжку, о чём ты мне буквально недавно сказал. Пару слов про себя, Дим. Привет. Да, привет, Кирилл. Привет всем. остальным, кто будет слушать или не слушать. Аэ, да, я простой обычный программист, э, в Amazon Webсервис, конкретно в Клаудфронте. работаю над такими замечательными фичами, которые называются одна из Cloud front lambda attach и вторая - это Cloudfront Functions, то есть это всякие customization pointты над CDкой, что-то сделать с вашими реквестами и респонсами до того, как они попадут в кэш или после того, как мы их отдадим из кэша. То есть очень просто. Но с одной стороны для пользователя всё очень просто, для меня там огромная головная боль. Ну да ладно. Вот, да, написал книжку там совершенно случайно за 5 лет ээ с кучей всяких заметок про неопределённое поведение Все-П. Ну, в итоге книжка оформилась, издатель пришёл, постучал в личку: "А давай сделаем книжку. А давайте сделаем книжку". Вот книжка тебе написалась. Сразу, кстати, быстрый вопрос. На книжке деньги можно заработать? Я не видел ещё ничего. Возможно, можно, возможно, нет. Я я не чувствую, что можно ней заработать. Ну, как я непосредственно она послужила там одним из шагов к получению Global Talent визы. Ну, так случайно. То есть нецеленаправленно она писала, чтобы получить Global Talн визу, а, ну, просто вот по совокупности факторов добавила. Ну, кстати, да, что считаю, что уже заработало. Да, да. Если хотите получить О1 или вот такие вот штуки для переезда в Британию, то, пожалуйста, напишите свою книжку. Кстати, многие думают, что это какая-то невероятная вещь и надо быть там самым гениальным человеком на свете. Это на самом деле не так. Вот книжки вполне можно писать. Главное желание. Дим, давай. Да, у нас тема большая, серьёзная. Плюсы. Такой язык, скажем, наверное, не для всех. И с моей точки зрения, как веб-программиста такого типичного в этом смысле, а тема покрытая мраком. То есть, знаешь, есть такой флёр сложности языка, решение каких-то сверхзадач, что какие-то сверхлюди и вообще обычный человек, ты там писал на PHP, а завтра на Pthне, это реальная история, да? Или там Java, например, или Sharp, а котлин, ну и так далее. Там можно перечислять бесконечно, даже Хаскиль, но C++ у меня ощущение, что так не работает. У меня почему-то всегда складывалось впечатление, что плюсы - это, как правило, мало того, что он сам по себе сложный, он ещё, как правило, используется в таких областях, где тебе ещё и надо знать много мм контекста помимо плюсов, там, начиная где-то от операционок, заканчивая гейдеф - это там физика, всё, что угодно. Так это или не так? То есть давай про область применения поговорим. Ну да, с одной стороны всё так, с другой стороны C++ - это действительно очень-очень большой и старый уже язык. Сколько ему? Почти 40 лет. Через, вроде, через год будет 40 лет, да? И он порос множеством слоёв. И если вдруг очень глубоко в них не закапываться, то а ограничится какой-то его конкретной частью. Ну, это каждый может это освоить, да, там с с каком-то уровнем уверенности, да. Как страуструп и компания всех агитирующая за последние безопасные подходы к C++, говорят: "Ну вы просто используйте всё STL, используйте умные указатели, всё будет хорошо, вам ничего не нужно будет". Ну и действительно у вас не будет почти большинства проблем, за исключением у вас не будет производительности, но проблем не будет. А, да. А, ну а так-то, да, как бы абы кто в C++, ну, бывает, приходят люди просто поинтерес. Вот, например, я как вообще в него пришёл совершенно случайно. Ну, как случайно. Мне в девятом классе вообще показали программирование, показали его на примере Паскаля ABC. Да, Паскаль ABC - это замечательное ответвление Паскаля, которое было сделано, а, в на Мехмате Южного федерального университета. А, Станислав Станиславович Михалкович, привет. А он, кстати, был у меня преподавателем, он же автор этого самого языка Паскаль ABC, а потом он эволюционировал в pascalabc.net. Ну, в общем, я начинал с Паскаля ABC и участвовал в олимпиадах, да. А в Паскале ABC, как и в обычном Паскале, не было такой базовой функции, как сортировка. И ты, участвуя на олимпиадах, очень часто должен был что-то сортировать, правильно? И писать каждый раз по памяти сортировку. Причём нужно правильно писать сортировку, да? Быстрая сортировка имеет огромное, ну, быстрая сортировка, написанная неправильно, имеет огромное количество чкейсов, на которых она деградирует до квадратичной сложности. Соответственно, ты провалишь э какие-то тесты на олимпиаде, да? А вот а C++ такой замечательный язык, имел стандартную библиотеку, и там была сортировка. Поэтому участники, а, кто писал на C++ или на Джаве, имели преимущество над теми, кто писал на Паскале. И я считал, что это как-то нехорошо и надо воспользоваться этим же самым преимуществом и выучить C++. Итак, где-то в десятом- одиннадцатом классе, то есть первый год, когда я участвовал, я вот старательно пытался на Паскале побеждать, не получалось. На, надо менять тактику, надо изучить C++. Ну вот где-то в конце десятого класса и одиннадцатого, да, я начал учить C++. То есть в универ я уже пришёл с каким-то знанием C++, что цикл, ну, цикл могу написать, там, прочитать, записать что-то, файл и так далее. Вот. Ну и там дальше продолжал участвовать уже в этих олимпиадах ээ от института командами и углублять свои познания в C++ и думал, что вот всё, я всё знаю, я уже всё понял. В самый простой язык так быстро всё пишется и ещё и никаких проблем не не бывает. То есть у меня там никогда сикфолтов не было. Ну я пользовался стандартной библиотекой там. Ну и плюс а олимпиадные задачи, они довольно узко узкие, что ну у тебя нет большого простора там раскидать на кучу компоненты перед ни передавать между ними ссылки на что-то. У тебя всё понятно. Вот тебя массив, сделай с ним что-то, вот тебе ещё что-то, вот тебя граф, сделай с ним что-то. Ну какие у тебя там висячие ссылки возникнут? Да никаких. Ну максимум там индекс ошибёшься, ну мусор напечатаешь, ты же всё равно отдебажишь, всё будет хорошо. Вот так и жил с этим. А потом в конце третьего курса пошёл работать в институт радиосвязи и писать на C++ и, ну, с с кт с кютом, да. Ну, и тоже всё думается здорово, отличный язык, никаких проблем. Тже замечательный фреймворк для написания графических приложений. Плюс огромное количество дополнительных встроенных библиотек, там для сети, для рисования чего-то. Что там ещё было? Много чего. Плюс, а, плюс ещё более богатая стандартная библиотека тогда была. Это какой год был? 2000 семнадцатый. Нет, шестнадцатый семнадцатый, да? А, то есть был богаче, чем стандартная библиотека C++, но уже всё равно стандартная библиотека C++ догоняла и предлагала более лучшие варианты. Но проблема была в компиляторах. Никто не мог обновиться, обновить компиляторы без больших проблем. Вот. Ну, всё отлично, как бы очень много людей вокруг тоже пишут на C++, вроде бы как бы не не гении, но у них всё получается, никаких проблем. А потом я познакомился с неопределённым поведением, да, в процессе переноса. А, то есть у меня была одна из задач- это перенести код для управления антенной решёткой с Windows на Astra Linux. Ну, под виндой там Visual Studia Compйiler, под Astra Linux GCC был пятый или шестой. Ну вот в процессе переноса сразу же столкнулся с удивительной вещью, что обычный цикл чтения коэффициентов калибровки из файлика, там комплексные числа, действительно мнимая часть, действительно часть такой вот просто списочек файлике, оно тупым сканнефом читалось в while снеф равно 2 и два числа читает, оно зацикливается. Вот под виндой работало, а там зацикливается. Почему? Ну, извините, там то ли баг в компиляторе был, то ли ещё что-то, я уже не помню, но он в бесконечный цикл превращалсь. Ну вот я начал это копать и открыл для себя очень много нового, стал ужасаться и понимать, что а это не просто так. То есть есть ещё не только вот светлый мир C++ современного и очень безопасного вокруг ST с там с тремя умными указателями Un shed и VIК и плюс некоторые стандартные библиотеки стандартные контейнеры. Ну, а ещё есть всякое безумие, когда ты начинаешь работать с сырой памятью, когда тебе нужно писать байтики в регистре какой-то платы, и тут начинаются всякие весёлые весёлости. Ну да. Ну весёлости какого уровня? Я пытаюсь понять, это относится к чему? К тому, как создан язык или просто к тому, как аппаратура работает и что это поведение просто и к тому, и к другому. То есть, да, и как работает аппаратура, это тоже не тривиально. Ну и плюс сам язык, в нём огромное количество слоёв, которые остались с чистого си, где вот у тебя неявное приведение типов во все стороны, где у тебя переполнение целых приводит к неопределённому поведению. Ну потому что си старый язык под разные платформы. Ту комплемент код для целых чисел вам стандартизировали только в двадцатом году, а до этого мог быть могло быть что угодно. А почему вы считаете, что у вас там должна быть бинарная система, а не третичная, да? И ещё плюс как как оборудование должно отреагировать на переполнение целых чисел. Поэтому вот, пожалуйста, вам неопределённое поведение, а с неопределённым поведением потом компилятор говорит, ну, разработчик компилятор говорит: "О'кей, при определённом поведении не бывает, значит, мы можем делать что угодно, в том числе пытаться оптимизировать код, предполагая, что это неопределённого поведения не бывает". И начинаются проблемы, что ты там не можешь напрямую 22 знаковых числа просто так взять и перемножить и записать в регистр, ожидая, что там получится, проверив его, допустим, на переполнение, если не переполненность, то записать в в регистр, иначе сделать что-то другое. Ну, ты не можешь так сделать, потому что два положительных числа не могут при перемножении дать отрицательное. Правильно же? Они, конечно, в аппаратуре могут дать, а в математике не могут. Значит, компилятор может выкинуть любые проверки сорта а у B меньше нуля. А ты написал такую промерку и считаешь, что не запи не записываешь отрицательные числа в регистры платы. Ну да. Вот тут я хочу уточнить. В регистре платы просто ты когда мне это рассказываешь, опять же, я могу что-то не понимать, потому что это не моя тема, да, но всё-таки у меня возникает какой-то вопросик дополнительный. Если бы ты не сказал, что ты про C++ говоришь, я бы подумал, что ты говоришь просмблер, потому что это довольно близко, да, это всё довольно близко. Ну, как бы C++ - это нативно компилируемый язык. Он компилируется в машинный код. Самый, наверное, ближайший к машинному коду - это ассемблер, потому что почти напрямую, один в один транслируются этимоники ассемблера в машинный код. И у очень многих программистов, которые начинают свой путь от C и C++, в голове есть такое неправильное мнение, что C++ отражает то, как работает машина, как работает компьютер, и любая конструкция на C++ однозначно ложится на машинный код. Это не так. И если вы предполагаете это, ну, вас ждёт долгие часы отладки. Почему у вас два положительных числа при пред приножении положили далее отрицательные, а вы это проверяли, но оно всё равно у вас получилось? Это не так. Язык C++ - это и C. Они более абстрактные, к сожалению, и, а, поведение языка C++ и C описываются абстрактными машинами C и C++. Вот то, да, отношение с ассемблером довольно прямое. Ну тогда смотри, возникает вопрос. Вот мы ещё пока не ответили на вопрос в итоге, где он используется. Я тебя всё равно сейчас спрошу про этот вопрос, но у меня всё равно возникает тогда вопрос: смотри, ты такой сразу с боли начал, причём заметь, у тебя ты скорее не отвечал на прямой вопрос, а у тебя так настолько наболело, что хотелось прямо про это сказать. И для меня это некий такой сигнал того, что, ну, не просто так про C++ всегда говорят вот насчёт его поведения, насчёт его сложности, насчёт всего. Раз это так больно, раз так хочется об этом говорить и прямо аж накипело, то зачем? Ну и мы как бы плавно приходим к тому, а где он используется. То есть почему плюсы-то? Основной аргумент за - это перформанс. То есть, ну, действительно, это следующие, ну, если мы пропускаем C, следующий язык по близости к железу позволяет не имеет, ну, как не имеет, на самом деле имеет, не имеет никакого рантайма, э, никаких сборщиков мусоров. Э код напрямую компилируется в, э, нативные машинные инструкции. ты имеешь довольно, несмотря на все вот те безумные вещи, которые я которые вызывают боль, всё равно ты имеешь довольно прямой контроль к тому, что ты хочешь спродуцировать в результате компиляции. А и если нам необходимо писать что-то, что работает непосредственно с железом, с сыры с сырой памятью, ну так вот есть, не знаю, спецификация у железяки, что вот тут у неё такие-то регистры, вот здесь у неё память, если ты запишешь в этот регистр такое-то число, она замигает лампочкой, что-нибудь такое. Ты не можешь это просто так взять и сделать на Питоне, если тебе, конечно, не предоставили библиотеку специальную, да? А вот на C++п+ и на C и на Сэмблере ты, скорее всего можешь это сделать, потому что, ну, непосредственно, ну, если эта железяка, а, подключена к твоей, э, машине, ты знаешь, э порты или что, что там у тебя, куда она подключена, у тебя есть интринтики, чтобы писать конкретные байты. по конкретным адресам. Ты берёшь буквально это пишешь, запускаешь и радуешься. Ты тебе предоставляет операционная система огромное количество возможности там отобразить сырую память этого устройства в твоё адресное пространство, и ты можешь с ней работать как, ну, как с обычным массивом, да? Ты скорее ты можешь то же самое сделать на Питоне, но опять-таки тебе нужен кто-то, тебе нужен какой-то посредник, кто тебе предоставит такой высокоуровневые IP. А вот на C++ня как если ты пишешь на C и на C++, ты имплементируешь такого посредника. То есть получается, у тебя не только речь про перфоманс, потому что здесь ты сейчас акцент не на нём делаешь, да? Да. И сейчас сейчас акцент на доступ к железу, а дальше уже к перфоманс, да. Дада. То есть получается, что в каком-то смысле безальтернативная история. Ну относительно. То есть, если мы берём прямо места, где надо прямо железом управлять, и тебе не хочется работать на ассемблере, вот не знаю, могу так упростить, ты такой: "О, ну плюсы, как бы выход". Правильно, да? Да, плюсы. Си сейчас вот раст там ещё Зик прибегает, ещё какая-то целая гвардия. Мы сейчас обсудим тоже, да, да, чуть по Да, да, да. Если тебе нужно непосредственно писать сырые байты по спецификации в железяку, ну, у тебя выбор очень маленький. Тебе либо на ассемблере, либо ещё мало памяти, нет рантайма, да. Да, нет памяти, нет рантайма. Ну как, в смысле, мало памяти, но нет. Да, да, да. Рантай у C++ есть для эксепшенов, например. Да. Плюс ещё вот операторы New и Delite стандартные, они тоже предоставляются тебе, так сказать, рантайным C++. А ты их можешь, конечно, поменять, подменить на что-то своё, но они тебе предоставлены. Угу. Да. Ну, а второй аспект - это, конечно, производительность. низкоуровневый язык с, а, довольно, а, хорошо оптимизируемыми абстракциями. Плюс опять ручной контроль позволяет писать высоко оптимизированный код. Ну, там трейдинги его любят, например, потому что им нужно как можно быстрее выполнять операции купли-продажи и запросов к биржам. Ба, ну, почему ты можешь написать высокопроизводительный код? Ну, допустим, ты можешь пролоцировать, э, большой буфер памяти и выполнять все операции в ней. Если ты работаешь с каким-нибудь питоном, э, Java или ещё что-то, ну, наверное, можешь тоже можешь сделать и использовать огромное количество ансай операций, чтобы работать с этим буфером. Но обычно, если ты нормальный программист на Питоне или на Джаве, ты, ну, там, объекты какие-то создаёшь, удаляешь, создаёшь, удаляешь, создаёшь там каждый раз а локации, антилокациях. Они, конечно, могут переиспользовать пулы объектов, но это всё от тебя скрыто GVM, компилятором, э, и прочее. В C, C++ от тебя это почти ничего не скрыто. То есть, если в если работать с C, то вообще почти ничего не скрыто. там, за исключением того, как работает молок. Но опять-таки ты всегда можешь пойти посмотреть, как в липси он устроен, и выяснить, что в конечном итоге он вызывает там один из трёх сисколов и радоваться. Так и получается, значит, у нас есть доступ к железу и высокопроизводительные вещи, это трейдинг. А, наверное, сюда игры относятся, да? Где тебе игры тоже относятся, да? У тебя бюджет 16 мисекунд, да? Ну, если же ты хочешь 60 кадров в секунду, да, у тебя бюджет на один кадр 16 мсекунд, ты не можешь себе позволить, а лоцировать и делоцировать огромное количество объектов вот так вот по одному. Поэтому в геймдеве очень популярны все эти подходы с пулами объектов, арены, а локаторы и прочие радости жизни. И они вот пропагандируют то, что надо от ООП отказываться именно поэтому. Ну да, вам надо, вам надо, вы отказываетесь, пожалуйста. О'кей. А ещё какие области, а прямо вот где C++ очень прочный имеет базис. То есть мы понимаем вот всё, что мы сейчас с тобой обсуждаем, почему мы ещё это обсуждаем, я просто хочу для аудитории подчеркнуть, что C++ оттуда вряд ли уйдёт э в ближайшие десятки лет, поэтому с ним всё будет хорошо, даже если туда не идёт много программистов. Да. Угу. А что ещё? А что ещё? Ещё он популярен там, где нет альтернатив ему. Например, если нужно писать всякие кудоядра для работы с GPU. Если прямо их нужно писать на куде, у тебя очень мало альтернатив C++, где либо C либо либо C++, а также там, где он по историческим причинам очень надолго задержался, если там у тебя много legгаси, а в остальном, в принципе, больше и нигде. Пару моментов, когда ты говоришь, что нет альтернатив. Тут, я так правильно ещё понимаю, это компиляторы под какие-то, не знаю, железки или ещё что-то, да? То есть у тебя должна быть реализовано и под C++, скорее всего, исторически просто дофига всего сделали. Какие-нибудь, я не знаю, медицинские системы, ещё что-то. Мы это с тобой не обсуждаем, но ведь 100% есть слой таких вещей. Может быть, и производительность не очень высокая. Так, я могу сказать, я вот у меня было такое некоторое собеседование в одно из Game DEF э- компании. Ну там без больших шансов на пройти, но просто было интересно, потому что, ну, я не игровой разработчик, у меня нету опыта работы с содвижками, но там их принципл вроде бы инженер, но мне говорит, что, ну да, раст, конечно, можно использовать, всё здорово, но вот у нас задача зарелизиться не только под ПК, но ещё и под какую-нибудь PlayStation, а там раз компилятор либо не работает, либо ещё, либо не поддерживает половину нужных нам интринсиков. У нас нет выбора, мы пишем на C++. Вот такой вариант бывает. Ну, плюс у тебя ещё может быть такой якорь из библиотек, который вот только для C++ существуют. Если их API публичный, э, таков, что он поддерживает чистый C, ты можешь его засунуть куда угодно, потому что сили лин лингвафка для лизиков программирования все понимают C так или иначе. Если же API C++ный, а ещё хуже, если он на шаблонах C++сных, ты не можешь засунуть эту библиотеку никуда, кроме как C++. C++. Хотя Swift ещё пытается Swift вроде бы пытается нативно поддерживать C++. Угу, понятно, да? То есть, если у тебя сишная история, то все так или иначе могут это всё использовать и мимикировать. То есть это чисто плюсовое, то это очень огромный объём работы. Это кто-то должен вложиться в такой компилятор, да, чтобы всё это поддерживать, да? Кто-то должен либо вложиться в компилятор, либо вы как команда должны построить прослойку, которая транслирует этот C++ код в C, а дальше навернуть уже ваш язык. Ну, в любом случае, он кси придётся всё приводить. Ну явно или не явно, да? Тогда и последняя область, вот, которую я хотел спросить. А, кстати, ты так интересно называешь. Я всегда QT называл, а ты его по-другому сейчас называл. Как-то да, он считается, правильно? Почему-то я в своей жизни. Вроде бы Кют он называчи, по крайней мере, я так запомнил. Я правильно понимаю, что вот именно эта область, это скорее просто исторически так сложилось, потому что здесь преимущества C++ нулевые. Ну нафига тебе писать и толстые клиенты? Правильно, мы же про них говорим, да? А просто стандартные десктопное приложение. Нафига тебе писать на плюсах, когда у тебя сейчас есть, да, господи, GS, а, который позволяет делать это просто с с полпинка на электрон? А, да. Э, ну да, если мы начинаем имбедить в клиент ещё огромную логику самого приложения, ну, там, почему бы не написать на какие-то игрушку? Я, кстати, делал, когда в универе довольно простенькие игрушки, там типа змейки, крестиков, ноликов и прочего. Ну, можно, конечно, ещё и я искусственный интеллект там в бэкграунде за за прилепить к этому. Ну да. А тут может быть смысл только в том, что вот вот эта бэкграунд-логика, она тяжёлая, её хочется написать на быстром, оптимизированном языке, тогда может имеет смысл напрямую использовать. А так, если это тонкий клиент, ну, большого смысла нету. Разве что, да, мы хотим, не знаю, микросекунды поэкономить. Опять-таки, если это не игра, если этот UI не должен быть ээ максимально отзывчивым и откликаться там меньше чем за э миллисекунду, да, на каждое движение, ну большого смысла использовать ДE я не вижу. Хотя, кстати, я не удивлюсь, если тот же Ну люди, наверное, знают, кто в этом разбирается. Photoshop какой-нибудь на плюсах 100% написан. Да, ведь наверняка. Дада. Да, и вряд ли они съедут на что-то другое. Хотите расти как разработчик не в одиночку, а вместе с сильным сообществом? Тебе интересно, вот такие тяжёлые профессиональные приложения, на чём пишут видео какое-нибудь, обработка? Вот там возможно обработчики видео, не? Ну, конечно же, бэкграунд там всегда на чём-то компилируе C++, Fortrun на C, FFMпек на C, вроде на C с огромным количеством ассемблерных сталок. Они постоянно в Твиттере их, не знаю, кто там семь. У нас был один из разработчиков Пега Дима. Тоже, кстати, Дима рассказывал немножко про это. Да. Ну та он там, кстати, интересно рассказывал про то, что на симпозиумах, когда там кто-то про раз заикается, там на него, как на прокажённого смотрит, что типа такие хардкорные ребята, у них си там всё как надо. Вот им это модно молодёжи не надо. Мне недавно рассказывали, что на очередном метапе, куда приехали довольно высокие люди из комитета, там Герб Сатер и ещё кто-то, вот все обсуждали фичиопасности Раста, но никто не называл Раст. То есть обсуждать можно, называть нельзя. Не, Да, я понял это. Слушай, как же это было в каком-то фильме или сериале? То имя, тот имя, кого нельзя называть, как-то так было, да? Дадада. Вот пишите в комментариях, если помните. Да. А, о'кей. Дадада. Да, точно, точно. Я просто читал этот фанфик Гарри Поттер метода рационального мышления. Они там так общались. А оригинал, кстати, я не читал никогда, поэтому запомнил оттуда. Смотри, мы сейчас немножко про стандарт поговорим и вообще про язык вот про его эволюцию. Но я хочу сначала одну очень маленькую деталь спросить, которая, мне кажется, довольно интересна. Если я не ошибаюсь, сам Строуструп в какой-то момент по какой-то причине, которую, скорее всего, ты знаешь, понял, что надо делать что-то другое лучше, проще, там, как-то ещё, и создал язык ди. Не, это не Страустроп или это не он? Нет страустро сделал, да? Я не помню Александреску, что ли, я не помню, кто, но да, короче, была попытка, и я так понимаю, что она, собственно, была только по той причине, что C++ чем-то не устраивал, и она провалилась в итоге, в конечном итоге. Ты что-нибуд про это знаешь? А я знаю, что была такая, да, попытка, потому что C++ слишком огромен, и, а, развивать его в плане добавления эргономически более интересных фич всё тяжелее и тяжелее становится. А была попытка сделать совсем по-другому. Это вот D. В нём, вроде бы, есть опциональный сборщик мусора, там, э, э, дженерики, как, ну, ближе к джаве и cшаarпу они, ну, то есть не вот не путём мономорфизации, хотя вроде бы такой тоже вариант используется, а с динамическим диспатчем в рантайме. Что ещё там? Синтаксис чуть-чуть более компактный, вроде бы какие-то неявные преобразования повыкидывали. То есть, да, там была попытка выкинуть всё то, что держит C++ и не даёт ему адекватно развиваться и становиться более модным и молодёжным. А, но она провалилась, и я помню, что была фраза: "Зачем нам ещё один C++?" Питон 2 и Питон 3 что-то мне в голову пришёл. Делаем новый язык, выкидываем старое, а потом все страдаем. Это, конечно, так не работает, но интересно что-то оттуда пошло или ди скорее был он собрал в себя лучшие практики на тот момент или знаешь как бывают языки, вот Зик, например, я насколько понимаю, которые наоборот что-то такое показывают все: "О, как классно" или там раз можно вот так, например, да? Не ди не оставил после тебя никакого следа в этом смысле. Я много проди не знаю, но вроде бы он тогда просто собрал наиболее эффективные практики, потому что не то чтобы он в моей жизни всплывает, хотя я помню, я как-то смотрел, изучал инфу по нему, я точно знаю, что иногда вот иногда где-то в комментариях кто-то такой вспоминает и говорит: "А вот в D там было или вот в D сдено". Но я не обычно на это не обращаю внимания, потому что вроде как бы всё, язык умер, потому что действительно затем тебе ещё один C++. Ну, он живой, на нём пишет, не знаю, 100 разработчиков каких-нибудь. Ну, живой компилятор. Хорошо. Ладно, тогда вопрос Ди закрываем. Давай теперь поговорим про стандарт и компиляторы. Начну, наверное, вот с чего такой вопрос. Вот, допустим, мы берём, ему 40 лет, допустим, берём 20 лет назад. Ну, вполне себе. Вот я пример тогда входил в разработку, и тогда был какой-то C++, на котором много чего писали. Прошло 20 лет, сейчас двадцать пятый год. Вот то, как сейчас пишут на C++ и то, как писали тогда на C++ из-за подходов в целом, из-за фич языка, из-за изменённых, не знаю, архитектуры, железа, вообще жизни нашей, это два разных языка или это то же самое? Чуть лучше, чуть удобней, а может чуть хуже, потому что стало сложнее, да? Ну, тут есть два варианта развития событий. Ну, если мы возьмём какую-нибудь современную, в смысле она недавно написанная, кодовая база на C++, есть два варианта исходов. Первое, она написана почти так же, как было 20 лет назад, потому что её писали, ну, старые люди, те же люди, да, те же те же люди. Либо потому что у них всё ещё старый компилятор, они всё ещё не могут э перейти на новый. Там привет, привет моим знакомым из Блумберга. Да. А либо второй альтернативный вариант - это вам доступен последний лol chain, и у вас начинается Дикий Запад. Вы можете писать с использования последних э фич, и никто вас не остановит, кроме здравого смысла. А в целом сегодняшний C++, он больше ориентирован на писателей библиотек и на написание эффективного кода для библиотек и, ну, и выполнение большинства операций. на этапе компиляции. То есть это тоже вот не знаю, ускорило ли движение в эту сторону появления языка ZК или нет, который вот предоставил самые лучшие способы для написания кода в compile time. Просто пиши как в рантайме, да, просто вызывай в compта. Офигенно же, никакой разницы почти нету. Очень много фич, э-э, которые принимаются в стандарт и которые я видел, они тоже ориентированы на то, чтобы улучшить эпириенс при написании кода э на этапе компиляции. И если мы сегодня возьмём самую-самую современную библиотеку на C++, которая, наверное, ещё не написана, которая будет использовать последние версии STL с со всемивсеми конкр и конвал фичами, а также вот там рефлексия, это вообще просто отвал всего. Скорее всего, большинство операций, ну, то есть код, наверное, будет выглядеть так, что мы напишем constlication равно вот это. Оно всё посчитается в compileтайме, будет собираться 2 часа, а потом дальше будет отдавать ответы просто мгновенно. То есть вот вот это будущее C++ похоже. Ну с моей с точки зрения как наблюдателя за развитием и пропозлами, то есть вот похоже вот это будущее, что мы всё проверим, э всё посчитаем на этапе компиляции, напишем одну строчку и дальше у нас всё поедет. Когда ты говоришь ориентирован на разработчиков библиотек, правильно ли я понял, что речь идёт о том, что они как бы понимают, что их язык используется часто для того, чтобы писать какие-то экстеншены для других там языков, для чего-то ещё. И мы типа не не для программистов, на C++ это делаем, а делаем для всех остальных, кто это потом и к себе встраивает. Это ты это имеешь в виду? Скорее, да. Ну, а если посмотреть на многие фичи, которые, ну, скажем, не знаю, есть умный, полоумный указатель, чтобы облегчить интероп си, который очистит твой ресурс, если сишная функция его поменяет. Там там что-то очень страшное. То есть она таргетит конкретную проблему при использовании, а, сишных опишек, которые возвращают результат через мутабельный указатель. чтобы избежать утечки памяти, когда вот этот мута, если мы передали указатель не нулевой и он уже указывал на какой-то ресурс, то если он поменяется, нужно этот ресурс старый уничтожить, правильно? Ну вот конкретно вот, чтобы исправить вот эту проблему в дизайне библиоте, ну дизайне вашего публичного IP с использованием C, вот вам фича из C++. Хорошая фича, яй не пользовался ни разу. Надеюсь, не буду пользоваться. А, ну шутка, конечно. очень много метафункций добавлять. Ну, то есть рефлексия, например, вот отличная, конечно, фича, но она в повседневной жизни человеку почти не нужна. Она хороша для написания. Вот основной пример использования рефлексий, который все приводят постоянно - это написание Джейсон сериалайзера и десериалайзера. Ну, действительно, да, с рефлексией очень хорошо получается. Второй пример - это, наконец-таки, облегчить людям жизнь и, э, позволить делать дебажные принты любых объектов. Ну, с помощью рефлексии напиши код, который будет принтовать все поля твоего объекта. Вот тебе красота как в расте с коробки. А до этого не было? То есть до этого до этого не было. До этого ты должен был каким-то образом изголяться, писать свои страшные макросы. То есть ты какой-нибудь писал макрос а рефлект в нём уже описывал свою структуру, а этот макрос открывался в какой-то код, который дальше предоставляет методы, чтобы выполнить форматированную запись твоего объекта или ещё что-нибудь с ней. Это вот всё такое было. Ну вот сейчас ты как писатель библиотеки, э, ну, не знаю, скажем, есть библиотеки для акторных моделей. Чтобы зарегистрировать свой тип эктора, тебе нужно написать очень много буллерплейта, каких-то дефолтных методов, там поддержать стерилизацию, дерелизацию и прочее, прочее. Всё это сейчас делается, делалось, ну, и будет продолжать делаться макросами и всякими страшными макро объявлениями. Ну вот C++ 26 предоставляет рефлексию. Ты как автор библиотеки для авторов можешь использовать эту рефлексию, чтобы свести всю боль твоего пользователя к использованию одной строчки. Там, скажем, режистр, предоставить функцию registerстр actor. Ну и всё, и она всё сделает. То есть, да, ты можешь написать бесконечно удобную теперь библиотеку. Да, это здорово. Кстати, не могу, знаешь, какую штуку не добавить. Вот как-то был срач под одним из моих видео. Я люблю хорошие срачи на тему того, что кто-то прямо так высказался, что нормальный язык, у него рефлексии вообще нет. Мы там даже где-то у нас обсуждали тоже на эту тему, что вообще-то без рефлексии очень многие вещи сделать нельзя. То есть понятно, что с помощью неё можно дичь творить, но очень многие вещи сделать нельзя. И вот я просто хотел посвятить этот момент, что рефлекси очень важный элемент, который нужен создателям во многом библиотек и стандартные либо и так далее, который позволяет, ну, очень важные вещи делать нормально, и без неё вы охренеете. То есть, если у вас в языке этого нет, вообще-то это страдание. для большого количества задач, начиная от высокоуровневых там типа РМку сделать или контейнер для внедрения зависимости, заканчивая банальным вот принтом объектов, там ещё чем-нибудь в этом духе. Вот я, кстати, подозреваю, что это может ещё помогать всяким инструментам анализаторам, которые с твоим кодом работают и могут всякое разное делать. Действительно, да. Например, если мы хотим трейспоинтов по понавставлять в каждый метод, ну, сейчас ты должен либо макрос везде пихать, а, скажем, с рефлексией ты можешь подать свой класс на вход, и он обернёт все тебе методы в прокси методы с трейспоинтами. Да, почему бы и нет? Это, кстати, то самое, что называется аспектно ориентированное программирование, да? То есть без рефлексии оно у тебя, ну, практически нереально. Есть там всякие декораторы в некоторых языках, но это ладно, мы оставим. А, смотри, что получается. То есть, с одной стороны ты назвал огромное количество фич. И, кстати, интересно и понятно, куда это двигается. С другой стороны, теперь вот вопрос. Ты, допустим, мы пишем, как любой нормальный человек, мы такие хотим взять современный проект, писать современный и так далее. Вот это современно в плюсах, оно реально делает программирование легче, лучше, проще или на самом деле при том, что у тебя строчек меньше, уровень понимания глубины, который должен быть, чтобы всё это делать, он должен быть ещё больше? То есть программирование- это само в итоге легче стало или нет? Вот в этом смысле? То есть если я сейчас буду учить плюсы, я скажу, что, блин, ну вот я писал тут на Зиге, на Расте, на Свифте, может быть, ещё на чём-то, и в принципе на плюсах пишу, и вполне приятный язык или у меня не будет такого ощущения. Ну, смотри, сейчас вот это точно будет такое opinionated, да, мнение совсем совершенно необъективная, чисто моё. Визуально, если ты написал правильный, красивый, замечательный код на на современном C++, он будет понятнее визуально и красивее, там, лаконичнее, проще отследить, что у тебя происходит и прочее. Но в процессе его написания ты будешь немножко страдать. Моя любимая, да, фича - это вот рейнджи. Она любимая, потому что, да, позволяет писать красивый код с вот этот пайпинг результатов обработки последовательностей, э, всякие функторы, всё очень здорово, очень красиво. Я вот когда курс у меня был по C#ARP в магистратуре и не не на четвёртом курсе путаем, там другой был курс магистратуре, но тоже C#ARP, да, мне очень понравился этот линк C#шарпный. Очень красиво было. Непонятно. Но в процессе написания, во-первых, вот вот я даже на каком-то из стримемов показывал, что если мы отключаем лэмки для cod completion by design у тебя нету детерминированного помощника по посказкам, что ты можешь применить или не можешь, потому что именно так, к сожалению, работает перегрузка операторов в C++. Ну вот ты написал контейнер, палка, а что ты дальше с ним можешь сделать? Тебе ни один детерминированный инспектор кода не подскажет, потому что ему нужно будет скомпилировать весь код на C++, перенайти все перегрузки оператора Палка и выплюнуть в тебя. Никто это не будет делать, к сожалению. Поэтому, ну, в процессе написания тебе сложнее. Тебе нужно помнить, что ты можешь применить. Извини, я перед тем, как двигаться дальше, я сейчас пытаюсь понять, что я здесь не понял. То есть, грубо говоря, статический язык, там типы, все дела, и у тебя нету автокомплита, потому что у тебя как-то перегрузка реализовано. Да, потому что ты не знаеть, э, ты не знаешь, какую перегрузку ты вызовешь, пока ты не укажешь два аргумента. У палки два аргумента. Ты написал палку, второй аргумент ты ещё не знаешь. То есть как как выглядят рейджис, комбинаторы? А палка - это специфика ренджа, ты имеешь в виду? Дадада. Да, для синтаксис, для рейдже. Ну там оператор битовая или она же палка, она же пайп оператор. Ты пока два аргумента не укажешь. Компилятор и вообще никто не знает, какая эта палка. Она бинарная или она пайператор, она ещё что-то. Никто не знает. И никто не может тебе это подсказать. Да, тебе можно какую-то ивристику написать, что, ну да, если левая оператор, если левый оперант - это какой-то контейнер. Хотя, во-первых, что такое контейнер C++? В C++ нету просто так ээ простых способов понять, что такое контейнер. Всё, что угодно может быть контейнером, да? Если это контейнер, тогда надо смотреть и предлагать только вот эти перегрузки. Ну, с лмками сейчас действительно всё намного проще. LM понимает, что, да, в контексте, если вот это контейнер, где мы написали палочку, то, скорее всего, там какой-нибудь Mapтрансформ или ещё что-нибудь будет. Без LM я не представляю, как какие-нибудь разработчики Intel ID или вес код плагинов, они могут это сделать. Это, по-моему, невозможно. Но опять-таки я не могу быть уверен. Хорошо. Да, даже о'кей, снимаем эту проблему. Мы мы помним все методы, которые мы можем применить, все комбинаторы. Начинаем их применять. Применили неправильно, получили огроменнейшую ошибку компиляции с инстанциацией шаблонов. Она должна была стать меньше за счёт концептов, но она сталась такой же или сталась или стала меньше, но намного непонятнее, потому что трейс огромный или я неправильно понял? Да, огромный трейс с довольно странными сообщениями, типа Standard Range, ээ, directional range, range. Тебе напишет вот что-нибудь такое: "Ваш range не ovnet. Что это значит?" Ты должен понимать, что это значит. По логике подкаст задумывался как история демистификация C++. Смотрите, на языке можно писать, а мы с тобой таки не на нём можно писать. Его читать даже момне очень вится, но уровень сложности какой-то запредельный. А можно вот при всём при этом так вот тоже небольшой отличённый вопрос. Ощущение, что всё-таки с ходу, если ты прямо не упора, такой C++с, всё, я всё готов ради этого сделать, войти в него сбоку - это прямо не просто сложно, это ещё и очень больно. Не, я понимаю, что можно всё в теории, но ты явно это ради удовольствия не сделаешь, потому что люди многие выбирают язык, сам знаешь, там го я люблю, потому что го вот такой. Я люблю Джаву, потому что она такая котлин, смотри, классный язык, там, там ещё что-то. Мне почему-то кажется, что с плюсами так не работает. Ну либо ты как знаешь, как Виммер или емаксер, чувствуешь просто, что ты выше всех этих колхозников и пишешь на нормальном языке. Это не так работает, мне кажется. Скорее больше вопрос в теме. Я хочу быть Game Dev там разработчиком. Плюсы ладно, выучи сказал, что это Да, это очень зависит от темы. И вот буквально недавние мои попытки попробовать что-то примитивные игрушки написать на Расте, это больно, это намного больнее. И это больнее не потому, что язык, э, скажем, плохой и там неудобные абстракции и прочее, потому что тулинг и время компиляции просто чудовищные, а цикл обратной связи от компилятора чудовищно длинный. И вот разрабатывать простейшую игру с использования самого навороченного из всё ещё развивающихся движков Bви на Расте. Это, я не знаю, нужна какая-то чудовищная машина, наверное. Э мой ноутбук не справляется. Я по по 2 минуты жду, э, как оно перекомпилируется после изменения одной строчки, но это невозможно. на C++, если подходить к этой же самой задаче, писать какие-то простенькие, ну или более сложные игры за счёт более развитой экосистемы, там, устоявшихся подходов, как это делать, ты получишь более, э, приятный экспириенс, да, у тебя поменял одну строчку, перекомпилировал за пару секунд, даже меньше, чем за пару секунд, использовал ход relло и вот у тебя уже логика поменялась, и твой Марио прыгает в другую ро сторону и ты и получаешь удовольствие от этого. На расте это намного сложнее добиться из коробки. Да, это это можно сделать, но нужно очень сильно упороться. А тут такой сразу дилетантский вопрос. Опять же вот Unreal Engine, да, движок, а внутри него ты пишешь, если надо что-то писать, на плюсах, правильно я понимаю? То есть ты внутри него на расте писать не можешь или я вообще неправильно себе понимаю, как это работает? Да, это плюсовый плюсовая библиотека. Ты на в нём можешь писать, если тебе надо, плюсовые экстеншены, но тебе ж никто потенциально не мешает скрестить C++ и раз. То есть ты, опять-таки, строишь небольшую прослоечку на C++ и прикручиваешь Раст. Никто тебе не мешает. Они же могут общаться. Ну да, ребя, ребята на плюсах построить прослоечку. Для них, видимо, это всех такое типа типовая история, потому что всё равно все нами пользуются. Давайте строим мосты. Это, наверное, такой девиз плю плюсовиков. Я просто как-то консалтил ребят, те, кто пишет билинг для Мегафона, и у них система для списывание денег, она была вообще платформенная, на плюсах. И при этом прикладные разработчики, которые логику писали, писали её на ЛОА. То есть они для них как раз сделали эту прослойку. Поэтому для меня такое дожавё очередное, что плюсовики - это чуваки, которые мосты наводят. Вот. Да. Ну, в случае с Unreal Engine, там же есть вот эти блюпринты, которые тоже вот ээ по поближе к народу, чтобы ZerД палочки куда-то стрелочки по подвинул, триггеры расставил и стало хорошо. Опять совершенно дилетантское объяснение. Я просто видел, как это выглядит, никогда не пользовался. Но в целом много разных сложных систем, написанных на C++, э, на Расте, ну, на каком-нибудь на на Дад Джаве даже бы, о чём бы и нет. Они часто предлагают своим конечным пользователям какой-то механизм экстеншенов. И этот механизм экстнов должен быть, а, с одной стороны безопасным, чтобы ты не мог поломать систему, написав что-то неправильно. С другой стороны, простым. Поэтому вам выпячивают какой-нибудь скриптовый язык. Ну вот я работаю сейчас в Клаудфронте над компьютфичами, которых я сказал. Что это? Ну вот есть большой страшный чёрный ящик CDНК. Это огромное количество э хостов. Они кошируют ваши данные. И мы предлагаем вам компьютфичу- это выполнить какие-то операции над вашими реквестами или респонсами и отдать вам. На чём конечный кастомер, конечный пользователь будет писать вот эти экстеншены? На C++. А что это значит, если он будет написан на C++? Он должен быть скомпилирован в нативный код или в в Ну хорошо, рассмотрим вариант с нативным кодом. Допустим, кастоммер пишет код на C++ компилирует нативный код и кидает его нам. Можем ли мы его исполнять или нет? Нет, это же огромная дыра в безопасности, если мы будем его исполнять, там всё, что угодно может быть. Хорошо, скажем, кастомер должен компилировать Websembмly, а мы уже будем исполнять Webсмбли в какой-то виртуальной машине. И так будет побезопаснее. Ну вот уже так лучше. А кастомеры, допустим, не любят писать на C++. Они вот все, не знаю, из веб из веб-мира. Они JavaScript, пожалуйста, пишите на JavaScript, мы примем JavaScript. У нас есть своя специальная для него виртуальная машина. Там полностью изолирована, она на C++ написана или на C или нарасть, вообще неважно. Мы её заизолируем и вот там будем исполнять ваш JavaScript. Всё здорово. Угу. Хорошо. Давай теперь перейдём к компиляторам, потому что уже несколько раз ты говорил про, кстати, несмотря на то, что РАСТ известен, а дикой медленной скоростью компиляции, про C++ ты тоже сейчас на самом деле пару раз обмолвился, что там не всё очень быстро. Плюс всё не очень быстро, да? Стандарты. Плюс ты говорил про проблему апдейта. Ну, в общем, короче, давай поговорим про компиляторы. А, ну сначала про компиляторы и про их скорость. Вообще ничего не мешает программе на C++ компилироваться очень долго и очень быстро, в зависимости от того, как эта программа написана. Если мы используем вот современные последние версии C++ последней фичи делаем всё всёвсвсё conстx и вот всё у нас будет выполняться на этапе компиляции, разумеется, у нас компиляция будет долгой, если мы обьюзим шаблоны, э сделали всё Generic ээ за ненадобностью, ну почему бы нет? Хотим вот возможно в будущем через 5 лет мы будем поддерживать все возможные версии а типов. А давайте сразу писать generic, в смысле плюспусный шаблон. Поэтому, когда он будет компилироваться, оно по по 10 раз будет инстанциироваться с каким-то конкретным типом в разных единицах трансляции. Повторно одно и то же. Мы будем просто тратить время компиляции на это. И будем счастливы, что мы запустили компиляцию и ушли пить кофе э несколько часов, да? То есть так можно написать на на современное C++. Если же мы ставим целью, в том числе оптимизировать время компиляции, мы начинаем приходить к тому, что о'кей, вместо огромного количества единиц трансляций, в которых компилируется одно и то же, давайте использовать, скажем, Unity Build. Соберём всё в одну большую единицу трансляции и там всё будет инстинциировано одно один раз. Всё здорово станет станет быстрее или медленнее, не мы можем проверить и убедиться или нет. Unнибил это довольно быстро можно проверить э собрать. Слушай, можно уточняющие пока, да, далеко не ушли, чтобы я понял, о чём идёт речь. Правильно я понимаю, что речь идёт про то, что самая большая часть времени компиляции уходит на мономорфизацию в Расте, например, да? И в C++ то же самое, да? То есть ты хочешь сказать, что C+ называется инстанция шаблонов. Ну, вообще потом дальше ещё работа линковщика очень много занимает времени, но, но да, мономорфизация - это довольно тяжёло. То есть ты хочешь сказать, что там внутри такое огромное количество обобщённых типов, что просто задолбаешься их все превращать в конкретные имплементации? Да. Да. Если мы если написать так код и если обьюзить стандартную библиотеку, вот там Rangers, который чудовищно Generic, да, можно получить вот один из вариантов без обобщения. Ну, там есть обобщение. Э-э, если это может каждый выполнить это упражнение, наверное, сейчас пойти на открыть Compiler Explorer, а, godbolt.com, вроде бы, и использовать STD-формат или STD print. Не STD print лучше. STD print фичу из C++ 23, вроде бы, и напечатать Hello World 42 и 42 передать параметрам в этот Printl. Оно будет, оно займёт там, не знаю, секунд 20 на то, чтобы скомпилироваться и запуститься, потому что там время компиляции генерится какая-то чудовищная таблица юникодных символов и их свойств, но она генери на этапе компиляции. Она никак не влияет, почти никак не влияет на время исполнения, но время компиляции съедает всё целиком. Капут, конечно. Ну да, да, но это интересно вообще. Возможно, это пофиксят когда-нибудь, но в целом всё равно это забавно. А знаешь, сразу всякие идеи, что можно было в девелопменте там как-то этого не делать, да? Вот эта штука, про которую ты говоришь, это именно оно? Как ты назвал-то? Про Unity Build. Ну не совсем. То есть как традиционно забываем про модули. В C++ есть модули, которые очень редко кто может использовать, потому что поддержка их какая-то странная в компиляторах. А, забываем про модули. До модулей, как было? Раздельная компиляция C++. У тебя есть header файлы, у тебя есть C-файлы, а C++ файлы, неважно. Ты C++ файлы компилируешь по отдельности параллельно и за счёт того, что ты в хедерах предоставил предобъявление, да? И в итоге у тебя может быть огромное количество предкомпилированных скомпилированных единиц трансляцией, полученных из этих C++ файлов. Дальше ты их линкуешь всех вместе. Ты можешь собрать вообще весь свой код в один большой файл. Тебе не нужно вручную это делать. Ты просто берёшь один берёшь, создаёшь один большой файл, который называешь там Unity Build и inclлюдишь в него все свои файлы. У тебя же есть macроc include, да? Ты пишешь include ACPP, BCP, CC CPP, все проинклюдил и компилируешь только вот этот файл, в котором уже всё есть. Погоди, ну зачем это ручками делать? Неужели современные системы сборки сами не генерят всё это? Если у тебя тысячи файлов? Я думаю, что современные системы сборки могут это сгенерировать, но по традиции это делали ручками. То есть я не копал глубоко, есть ли, скажем, в каком-нибудь симейке возможность всё махом собрать в один Unity Build Filed, но всегда можно скрипт написать, да, Glob все CPP файлы и include их в один. Да, да, все, все мы знаем, как выглядят makeфа make-файлы из симейки, если их открыть. Да, да. И это это может помочь вот с временем линковки, со временем мономорфизации, потому что по одному разу там будет всё инклюдиться и инстанциироваться. Э там время препроцессинга, соответственно, тоже уменьшается. А альтернативный вариант - это вы наоборот эксплуатируете параллелизм этой сборки. делать вот эти единицы на трансляции максимально независимые, как можно меньше зацеплений через хедеры, чтобы всё это можно было хорошо распараллелить, там ни в коем случае не помещать полностью описание всего класса в header, использовать forward declaration и прочее, прочее, прочее, чтобы максимально распараллелить сборку. И так можно ускорить. Ну, тоже можно. А потом вы ещё каждый трансляции собираете в динамическую библиотеку, и у вас там ещё пересобирается всё. мгновенно практически. Ага. Ну, в любом случае, получается такая штука, которой, как и всем, наверное, другим все+ приходится управлять, ну, плюс-минус ручками. То есть ты должен об этом думать, ты должен этим заниматься и соответствующим образом организовывать проект и что-то с этим делать. И плюс то, как ты пишешь код тоже на это влияет. Ну, то есть глобально, в общем, может быть так, может быть так, опять всё на тебе, да? Ну, ты как программист должен об этом думать. Это справедливо, наверное. Ну, я не могу сказать про все-таки программирования, да. Ну, для питона, наверное, неважно. Это интерпретированный язык. Ну, максимум у тебя может быть какой-нибудь тайпчек препроцессинг с этого Mypй, да, если тебе сильно хочется. А так ты запустил, а дальше оно динамически подгружает, что ему надо. А, поэтому время обратной связи минимальное. Та же самая проблема для раст существует. Ты должен понимать, что такое единица компиляции в Раст. ВС - это единствен компиляция - этот. Если у тебя в крейте ээ 150 файлов с исходным кодом, в каждой по 5.000 строк, ну, если ты одну поменяешь из них, оно вот всё будет перекомпилировать, потому что это одна единица трансляции, одна единица компиляции. А поэтому вот в Расти любят создавать огромное количество маленьких крейтов и радоваться, что у вас 4.000 зависимостей. Ну да, это помогает ускорить время сборки. Понял. Хорошо. А вот с другой стороны, вот если мы берём опять же Java и говорим про виртуальные машины, да, у тебя там говорят: "Вот у нас тут такой сборщик мусора, мы вот так работаем, сяк работаем, у тебя есть Oraacл, который это делает там, ну, как-то более-менее вот с с моей точки зрения я как-то картинку там более-менее вижу. C++ опять же, видим, потому что я совсем не там, я её не вижу. То есть типа есть один основной компилятор, который делает какая-то организация. То есть можешь вот про это, что вообще из себя этот Нет ээ одного компилятора, конечно, нет. Есть три мажорных, э, всеми любимыми GCC

и как G+. GC - это GN Comiler Collections, там много компиляторов. G++, второй + и МСВЦШшный майкрософтовский. То есть это три мажорных. Есть ещё, конечно же, Apple Clank. Особый мир. А это как кланк, только только от Apple. Что-то там отломанное, как часто бывает. Есть интеtловский компилятор ICC, есть куча старых, ну, конечно, есть всякие Turтубоo C++, наверное, уже умер. Есть борландовский, вроде бы, компилятор C++. Есть C++ Builder, что это как-то он мимо меня прошло, но оно такое существует. А нафига? Ну, ну вот расскажи, потому что интересно, да? То есть зачем так много? Был синий же, да? В чём его сила? Что он простой в плане спецификации? И в этом его сила, чтобы быть переносимым между разными платформами. Каждый вендер под свою платформу пишет компилятор C и все счастливы. C++, ну, по наследству ему достались компиляторы C, которых в C++, ну, C++ обещал нам совместимость C почти почти полную. он нам её гарантирует там на 95% совместим. Соответственно, если мы пишем компилятор на C++, он должен поддерживать C. Вот это всё зоопарк у нас есть. Э куча вендеров на каждую платформу. Если мы хотим поддержать C++, мы должны расширить наш компилятор. Ну вот до стандартизации компиляторы же появились сишные и плюсовые ещё до стандартизации C++. Ну как бы исторически они нам остались. Сейчас я не я не знаю, насколько хорошо развиваются ли вот эти вот минорные компиляторы, но мажорные остались три. Ну, они чем соревнуются: количеством поддержимых платформ, а скоростью, опциями какими-то, потому что там понятно у тебя какая-нибудь граль ВМ там типа мы быстрые там при таких условиях, мы там такие, там понятно, чем они соревнуются, а здесь они чем соревнуются? Ну, количеством поддержанных платформ, разумеется, хотя там как-то не очень сильно они соревнуются, но вот есть MSC, который Windows Target и всё. Да, Кланка и GCC, да, они таргетируют большее количество платформ. Ну, Кланка через LVM пытается таргетировать вообще всё что угодно, правильно же? А GCC чуть-чуть более консерватив, да, более консервативный. Угу. Да. Но тем не менее всё равно пытается. Вроде бы у них разный подход к архитектуре компилятора. То есть один из них быстрее, один медленнее в разных условиях. У сторонников э у одного и другого тоже разные лагери. А там прямо война, типа мы, значит, за этих, а те лохи, да? Или или не так? Ну я не могу сказать, но но но есть люди, которые там предпочитают только кланк, а есть люди, которые предпочитают только GCC. Ну флаги, производительность, это есть там история какая-то с тем, что эти более оптимальны, а, ну между, например, между клангом и GCC там пытается выдерживать некоторые фичи парити, что есть флаги компиляции оптимизации, которая поддерживает GCC. Ну и клан должны должен тоже поддерживать их, по идее. Хотя там есть всякие весёлые разницы. Я да, там есть флажок, который проверяет. Вроде бы в кланге сначала добавили санитайзеры, а потом уже cсиc их перенял. И в кланге есть флаг undefined behavior санитайзера, который проверяет переполнение без знаковых. как бы для безнаковых переполнения вполне себе определено и нет никакого неопределённого поведения, но как бы часто переполнение даже без знаковых - это проблема. И его в кланге можно включить, и он отловит, что вот тут вы перемножили два числа и они переполнились. Результат переполют переполнение в GCC на отрез отказались зовывать этот флаг, потому что глупость какая-то. Знаешь, что интересно вот в этом отношении? Во многих языках, я, наверное, скажу, что не соврусь, скажу, что в большинстве, вообще-таки у тебя в компиляторе как правило, ну, много гарантий сразу уже, да, потому что это вот C++ немноче позволяет, в остальных всё. Но как только речь идёт о каких-то вот таких вещах, ну, тот же самый наable там в Джаве, которого нет в самой Джаве, реализуются, ну, либо в редакторах, либо в библиотеках, которые там линтеры и так далее, да, пытаются проверять всякие штуки. И в этом плане, ну, вебовские, особенно всякие скриптовые языки, они там далеко вперёд ушли, что они позволяют делать. Вот как в этом отношении с плюсами? То есть если вот вообще инструментарий, там автоматические форматоры, линтеры, которые тебе всё это подсветят, им неважно, что это в компилятор добавлено, они вот сами там айстэшки строят, сами всё делают или как-то по-другому? Расскажи очень. Конечно же, есть, э, есть огромная. Ну, во-первых, ты можешь, э, у кланга запросить айстэшку и сделать с ней, что хочешь, да? Берёшь, строишь, берёшь, билдишь свой экстеншн для vs-кода, который вызовет кланк, чтобы, э, получить э метадату от о твоёмко-коде, в том числе там астэшку, а дальше делать не что хочешь. Ну и вроде бы кодный плагинди именно так и работает. Есть линтеры, есть простейшие линтеры, например, мой любимый - это include what you what you use. Это такая вроде бы даже на Питоне написан простенький скрипт, который сканирует каждый исходник и проверяет, что о'кей, вот тут ты используешь такой тип, а есть ли у тебя вот здесь в списке инклюдов инклюд, из которого этот тип пришёл. Ну, в основном он работает со стандарт со стандартными типами. Ну, например, ты используешь Unordered map, это ассоциативный массив плюсовый. Ты его используешь в своём коде, а include забыл. Соответствующий map incled map ты не написал. Ну вот такой простенький линтер тебе скажет, что не надо бы подключить. Почему это важно? Ну, потому что из-за вот этой вот раздельной компиляции и разделения хедеры и C cpp файлы, у тебя настоящий инклюд этого mapпа может быть в каком-то из других инклюдов, если когда ты его поменяешь, ну, в одном из других хедеров, и когда ты его поменяешь, у тебя там поломается сборка, либо есть стандартная проблема, что include алгорит алгоритм в в GCC и в кланге includдит всё, всёвс всё всёвс вообще. Всё, а под MSVC он не инклюдит всё. Поэтому, если мы написали код include алгоритм, дальше используем вектор Map и ещё что-то под GCC и CL, оно компилируется, а партируем на MSC не компилируется. А вот этот простенький линтер от такого впасает. Не могу тут сразу не заметить вот прямо на этом месте, потому что я уже привык к тому, что это стандартная фича лспишки редактора, да? То есть то, что ты говоришь, это ты, например, начинаешь набирать код, да, и у тебя просто знаешь, что получается по твоему разговору, что ты сначала его начинаешь использовать, а это значит, что у тебя нет ни автокомплита, ничего. И только после этого он тебе говорит: "Ой, а тут ещё импорт нужен". Да, мне не показалось. Да, потому что я в джаве или в тайпскрипте, там в Джессе, неважно или в PHP начинаешь набирать, у тебя он тебе сразу такой: "О, вот он в какой подключаем, пап, автоимпорт". И всё, у тебя автокомплит пошёл. А ну именно так, да? И в последних версиях компиляторов я видел, что для многих стандартных типов всё-таки ошибка - это не просто какой-то абстрактный un unknown type, а тебе предлагают d forget get to include алгоритм, ещё что-нибуд такое, да, клан как минимум. То есть, да, последние, наверное, года три или четыре, не три, наверное, компиляторы мажорные. Я не знаю, как про про МСВЦ, про GCC, пронки я вот могу более меренно говорить, как они поменяли свой курс от того, чтобы выкидывать вк пользователя чудовищные огромные. Давайте попытаемся хоть что-то с этим сделать и предлагать более userfriendly человекочитаемые ошибки. Боже мой. Да, и мне кажется, знаешь, мы периодически на эту тему рассуждаем, что у тебя современный язык должен начинаться с написания package-менеджера и форматирования кода, да, как в го. И C++, слава богу, пошёл в сторону девелопер экспириенса, потому что иначе это капец. Ты просто не привлечёшь людей, блин, в язык. Формары были, кланк формат ещё там всякие. Бьютифаire был какой-то. Я я помню последний раз я им Не звучит как стандартное решение. Нет, они не стандартные. У каждого, у каждого тулчейна что-нибудь своё. Стандартного обычно нету. Ну, очень многие используют преимущественно кланкформат, потому что он довольно гибкий. Э, там у него есть пресеты, которыми пользуются большие корпорации. Ты можешь там просто написать там кланформат settings use, не знаю, llvm style или use Google style или use Apple style и дальше радоваться. Почти ничего не настраиваю. получаешь что-то вменяемое из коробки. Ну вот я помню, что с этими форматорами были давно, очень, а 7 лет назад, наверное, да? Да, 7 лет назад а были проблемы, что они типа могли код поломать в том смысле, что какие-нибудь лишние фигурные скобочки могут могут убраться. А в C++ - это важно. C++ лишняя фигурная скобочка может что-то очень-очень важное значить. Например, это дополнительный экстраскоп. Там деструктор нужно вызвать или ещё что-то. Вот. они могли это отломать и поломать тебе код. Поэтому я к ним довольно осторожно относился, а сейчас вроде бы более-менее нормально. Угу. Вопрос: какой редактор любят, предпочитают использовать? А насколько я слышал у тебя vsкод? Просто я знаю, что джавистам, когда говоришь слово vocд, они такие: "Фу, у нас intтеelligent". Типа и код не тянет. А хотя я в Виме пишу, в том числе на джаве. Что в плюсах? Ну, хардкорные, да, какой-нибудь вим или там неовим любят использовать. Ну, я пользуюсь кодом. Я с девятнадцатого по двадцать первый год я писал в селайне джетбрейновском. Тоже вполне себе адекватно было. До этого я пользовался эклипсом внезапно. Да, мне кажется, было время, когда все эклипс на Beс, помнишь, были времена. Да. Дадада. Дадада. Аэ, ещё qйor, вот я знаю, есть тоже хороший друг, знакомый, который геймдевелопер. Никита, привет. Он QT QT Creator использует, потому что редактор ему нравится, да, в принципе. Почему нравится, не знаю, но он его использует. А мне он относительно нравился, когда я в ней работал и на кти писал. Ну, как бы почти всё работало из коробки. Автокомплит, подчёркивание, где я ошибся. Навигация по ошибкам, да, дебагр встроенный тоже, ну, как интеграция с дебагром. Это не встроенный дебагр, это всегда интеграция. У тебя какой-нибудь GDB или LMDB, LDB, ты к нему подключаешься. Слушай, а давай давай поговорим про знания, которые нужны дополнительно. А мы в начале это упоминали, но не развивали эту тему. опять же C++ из-за своей сложности и специфической области применения, да, то есть это не классический веб, где, ну, какие-то там DNS, HTTP, сервер. Ну, там, конечно, тоже есть свои истории, да, но они понятные более-менее. А вот эти области, они требуют, ну, часто специфических знаний, опять же, как мы упоминали, например, операционной системы. Вот. Можешь про это рассказать немножко? Потому что я сомневаюсь, что если к тебе придёт просто человек, скажет: "Я плюсы понимаю", а ты ему скажешь: "Ребята, ну у нас тут сильно больше, чем просто плюсы". Или изначально подразувается, что ты не можешь знать хорошо плюсы, если ты, например, офигенно не разбираешься в операционках или в железе, или ещё в чём-то. Как это устроено? Не, ну почему как, ну, скажем так, офигенно знать плюсы, по-моему, никто не может знать. Даже, наверное, никто из с комитета по стандартизации не может их знать, потому что, ну, просто чудовищно огромный э язык, чудовищно огромный стандарт. Есть специально обученные люди, которые умеют толковать стандарт. Вот там, не знаю, мой мой любимый пример - это а почему вектор не почему можно написать вектор pushb, передать в пушбек ссылку на первый элемент вектора, и тебе гарантируется, что всё будет нормально. ничего не поломается. Ну, в стандарте это не написано, потому что в стандарте ничего не сказано такого, чтобы это запретило. То есть вот объяснение такое, потому что, да, есть специальные люди, которые умеют умеют толковать этот талмут. Я им восхищаюсь немножко и боюсь. Ну, в целом, ты можешь понимать довольно хорошо язык в вакууме, но язык в вакууме мало кому нужен. Ну, исключения, если ты entry level программист, дальше тебе нужен какой-то лабы пишешь студентам на на заказ. Да, да, да. Если ты лабы пишешь студентам на заказ, вот тебе вот скорее всего, если это не лабы по операционным системам, компьютерным сетям или ещё что-то, а просто лабы по, скажем, алгоритмам на C++, тебе ничего, кроме языка C++, ну, и, наверное, так или иначе всё равно нужны знания алгоритмов, да, хотя бы. Но тем не менее, есть всё-таки курсы чисто C++ в вакууме. Вот, да, там C++ знаний как языка, наверное, будет достаточно. Умеешь циклы писать, умеешь умные указатели использовать. Здорово, да? Обычно тебя просят алгоритмы какие-то знать. Потому что если ты будешь писать на C++, то, возможно, вы будете писать что-то относительно наукоёмкое и требующее алгоритмического подхода. Там какие-то, не знаю, деревья будете вращать. Ну, в базах данных, да, то они все на деревьях. Будете их там вращать и перекладывать и списки делать интрузивные. В дополнение к этому всё-таки желательно хоть какое-то понимание архитектуры компьютера, операционных систем, что вот, да, память, скажем, алоцируется она не из воздуха, а там аэ есть куча, есть всякие э мапинги страниц. Ты можешь у ядра попросить замать мне, пожалуйста, сюда какую-то память. Ядро тебе скажет: "Да, пожалуйста". Но ничего не замапит. Ну, как физическую память не алоцирует, а просто скажет: "Ну вот там что-то будет, когда будет, тогда когда посмотришь, тогда и будет". Ну да, нужны вот хоть какие-то понимания, как это дело работает. Дальше уже, наверное, доме, более доме специфик, да, если, скажем, в том же AVS Cloudфронте, наверное, от тебя ожидают понимание дополнения, как HTP примерно работает. Ну, понимать, какие погуглить, почитать. А чем get от пост отличается, тоже полезно. Тут аудитория встрепенулась, потому что многие такие: "Тактактак, этих этих знаний у меня достаточно, чтобы там быть". Ну, кстати, мне кажется, вот если брать геймдев какой-нибудь, там, наверное, вообще капут, там дополнительные знания. Там также зависит от того, чем именно заниматься. Если те, кто будут заниматься движком, ну, наверное, им будет нужны алгоритмы, им, наверное, нужна всякая линейная алгебра. Если они ещё более глубоко будут заниматься движком и всякими физическими симуляциями, им, наверное, нужны численные методы внезапно. Моя любимая. Дадада. Не, ну, наверное, слушай, и физику надо понимать, в принципе. немножко понимать, ну или хотя бы дифференциальное уравнение понимать, короче, это будет весело. Поэтому у меня и сложилось, и говорю, всегда было впечатление такое, что, как правило, туда идут после какого-то вуза, где ты прямо вот учился и, ну, у тебя есть такая вот направленность в эту сторону, и ты выходишь готовый, иначе это прямо сильная боль. То есть вот так с улицы не зайдёшь. Ну либо ты там на своём собственном не знаю, запале вот очень сильно захотелось, скажем, игры делать. Ну да, да. идёшь, изучаешь там какой-нибудь Open GL или сейчас что WebGPU, да, предлагают использовать Web GPU. Основная библиотека-то на расте написана. Есть интересная такая штука ещё, связанная с не знаешь C++, не программист. Боже мой, сколько я этого вижу тоже в комментариях и везде. И на эту тему всегда шучу, когда меня спрашивают тоже иногда типа: "Кирилла, а вот как так? Вот C++?" Я говорю: "Ребята, обратите внимание, вот все, кто вам говорят, что без плюсов вы не программисты, это типа первый язык, который вы должны учить". Это, как правило, люди, которым сломали немножко жизнь в университете тем, что в них пихали C++. Ни один разработчик, который не начинал с C++, не будет вам говорить, что C++ нужно учить, это язык, без которого вы не станете программистом. Ну, это моё мнение. Что ты про это думаешь? Ну, я считаю, что как бы в современном мире, э, не обязательно начинать с C++. C++, ну, вернее, как не обязательно вообще даже начинать с C++, чтобы стать, э, хорошим специалистом даже в низкоуровневом раграммировании. Можно сегодня начинать, ну, если сильно хочется, с чистого си, можно с Раста начинать, но вот не с того раста, который Давайте сейчас Актикс возьмём и запилим свой очередной HTTP сервер, и всё будет здорово, а с чуть-чуть более низкоуровневого а раста и даже uns раст посмотреть. Но в целом, да, если мы хотим иметь в конечном итоге разработчика, который понимает не только как работает узкий набор менеджed, где там всё ссылочное и про и всё здорово, не нужно думать о памяти, ну да, нам тогда C и C++ не нужны. Если мы хотим всё-таки иметь более широкого спектра специалиста, но ему стоит изучить хотя бы C на минималке, да? То есть C++ не обязательно. А я уверен, что мновь, вот гошники, они же любят примазываться, простите, гошники, что мы занимаемся системным программированием, да? Вот интересно, какое отношение у сишников и C++сплюсников к гошникам? То есть они просто гошники такие: "Мы про системное программирование, а может быть плюсовики такие типа: "Не примазывайтесь к нам, вы не настоящие программисты". Я не знаю, такая идея пришла в голову. Ну в Гугле же го сделали зачем? чтобы программисты, которые плохо могут писать на си, но вполне себе адекватно могут писать на каком-нибудь баше, могли писать ээ на что-то, на чём-то среднем. Короче, оскорбительно всё равно звучит. Ну, немножко оскорбительно. Не, я мне Го, в принципе, так издалека понравился, конечно. Да, у него есть проблемы с эргономикой. Вот это известные срач за возвращение ошибок. Это Нил не равно, да? в каждой строчке. То есть в Go очень много хороших идей, там, например, бить по рукам за неиспользованные переменные. Ну, действительно, потому что если мы возьмём какой-нибудь C++, если там неиспользуемая нетривиальная переменная, у неё есть деструктор, она, скорее всего, употребляет память, жрёт ресурсы, надо от неё избавиться. Это хорошо, это раздражает, но это хорошо, на самом деле. Аэ, там какой-то более-менее унифицированный синтаксис и форматирование тоже хорошо, потому что когда пишут акак, потом читать тяжело. Вот если ты смотришь на какой-нибудь обычный проект на C++, там всё здорово, красиво, camel Cas, Snake Cas, всё здорово, потом идёшь посмотреть, что там в стандартной библиотеке и ещё куча нижних подчёркиваний в повсюду. Вот это нечитаемо. Если есть какой-то унифицированный подход, что к что экспортируется, что не экспортируется, ну, ты можешь адекватно писать код, а не изобретать костыли с тем, что два нижних подчёркивания это только для стандартной библиотеки. Ну, дженерики там, наконец-таки завезли, да, в го. Без них было как-то грустно. Ну, не всем, кстати. Кстати, я не знаю, почему вы про это не поговорили. Так, сколько в C++ должно быть отступов, пробелов? Давай. Всё, надо было с этого вопроса начинать вообще наш сегодняшний разговор. Сколько пробело? Сколько пробелов? Сколько? Мне четыре достаточно, но два, когда пабли и privдификаторы. То есть у вас это ещё и меняется. А редактор вообще так можно физически настроить? У тебя же вот можно, да? Можно форматор можно настроить. Вот если открыть кланкформат, там на каждый тип интенданции можно указать сколько ты хочешь. То есть если у тебя private одно, если паблик другое, вот так вот у тебя отступы меняются. Нене не не, я имел в виду другое. Ну вот. А, слава тебе, Господи, я уж Да, класс, фигурная скобочка, а дальше слово прайт сдвинуть на два пробела, при этом всё остальное на четыре. Да ну вы вообще вот это очень жёстко. Так нравится, например, очень жёстко. Главное не открывайте кодовые базы GCC, потому что там форматор никто не применял, поэтому там и табы, и пробелы, всё в перемешку. Так, открываешь, тут восемь, тут четыре. Что в этом плане? Мне в го, кстати, не очень нравится история, что у тебя privсит от названия первая буква большая маленькая. Просто потому что банально ты решил поменять, тебе надо переименовывать и ну да, конечно, рефактори им все дела, но у тебя изменения там в куче файлов будут. Не знаю. Мне кажется, тут они с наглядностью переборщили. Хотя уверен, многие гошники со мной не согласятся. Ну, это так просто в дополнении к этому. О'кей, понятно. А, ребят, если вы гопрограммист и мы задели ваши чувства отношения C++, напишите в комментариях, интересно, потому что действительно я просто помню эту историю, когда был спор я со стороны на неё смотрел, сразу скажу, на тему того, является это системным языком или нет, можно ли на нём писать какие-то такие вещи. Понятное дело, что у вас есть, что у вас там сборка мусора, и это всё, вообще-то, не одно и то же, да, а мягко говоря, когда мы говорим про C++ и го, например. Поэтому, конечно, между этими языками пропасть, даже несмотря на наличие указателей, да. Ну как так? Какие-то возможности, ну, как мы, как я говорил в начале, да, ты можешь всегда предоставить для питона библиотеку и с помощью этой библиотеки писать в твою железяку, да. Ну вот тут примерно то же самое. Ты можешь для Го предоставить какие-то библиотеки на C и дальше, используя Unsave части Go с указателями этой библиотекой пользоваться и писать в железяку. Ну, делает ли это прямо сильно системным языком Goа? Ну, я бы сказал, что он ближе к системным, чем какой-нибудь Python, но Ну, чем PHP точно, это правда. Хорошо. Мы вот много раз, пока с тобой разговаривали уже, видишь, там прошло время много. В принципе, про C++, наверное, всё понятно. И, ну, как бы ниша, язык, мощь, все дела. Давай поговорим про альтернативы. Мы уже несколько раз упоминали их, да. У нас раз, наверное, eк - это из того, что вообще в целом звучит в последнее время, да? Давай поговорим. Является ли это реальной конкуренцией? Да, нет. Есть ли перспективы? Ну и так далее. Давай сначала с Раста начнём, а потом паразику. Смотри, вот в тех нишах, где C++ засел основательно там по LEGC причинам или по причинам отсутствия поддержки, РАСТ пока никакой конкуренции не предо не представляет с C++ и C, к сожалению. Ну или к счастью, наверное, с одной стороны. С другой стороны, вот в таких областях, как web, serverless, cloud, AVS, Cloudf и ещё много разных, наверное, контор, они от C и C++ уходят в сторону Раст, например. Вот я могу говорить точно за AWS, не только как со стороны, что да, они там публикуют периодически, что да, мы там что-то на раст перешли, мы поддерживаем и прочее, а реально стратегическая инициатива и план такой, что весь новый код, который сенсив к перфомансу, а также к секюрити и обращается с кастомерскими данными на data дапe, то есть там на непосредственно на серваках, которые ваши реквесты перекладывают в кэш предоставляют и прочее. Он должен быть написан на безопасных языках. Ну, конкретно на расте Зика. Ну там кто-то практикует Зик, но я его не видел серьёзно в АVS. Прямо чатик Z зика in AVS есть, да? Я в нём состою, мне очень нравится. Но никакого реально большого проекта на Зиге я ещё там не видел. А на Расте? Да, я пишу, то есть последние 3 года, да, я пишу преимущественно на Расте. У меня есть там Legy на C и на C++, но есть новый код на Расте. Это с одной стороны, конечно, да, мы выполняем цель, с другой стороны, да, на расте конкретно в этой области писать удобнее и проще. Ну, тут очень много обработки строк, да, в вебе там хедеры. Это хедер строками идёт http текстовый формат. Если, конечно, не смотреть HTTP3, да, которая там не совсем текстовый. Очень много строк их обрабатывать когда у тебя язык в из коробки поддерживает все вот эти преобразования. Split, join, бла-бла-бла, намного приятнее, чем на C и на C++. Плюс нету риска нультерминатором э куда-то въехать или буфер забыл пролоцировать или ещё что-то. А достаточно длины. То есть тут очень много средств внутри стандартной библиотеки и внутри самого языка, которые решают твою доomaпек провали тебе хорошо, да? Это это улучшает developer experience. Плюс там поддержка тестирования внутри языка тоже очень хорош хорошо организована. Там тебе не нужно задумываться о том, что вот что что нужно сделать private, что нужно сделать паблик, чтобы можно было по-нормальному протестировать, потому что только паблик поля будут доступны. Да, тебе не нужно думать. Просто в том же файле втыкаешь тест и тестируй, что хочешь. Проверяй публичные поля, проверяй приватные поля. Вот за пределами файла у тебя не будет к ним доступа, а внутри тестируешь, как хочешь. Ну воще это очень удобно, на самом деле. Developer experience ускоряет немножко разработку, но потом поскольку есть очень много legacy на C и на C++, тебе нужно выстраивать мосты между ними. А это требует unсей раста. И это довольно болезненная штука, если её сделать неправильно. Если её делают какой-нибудь не очень подготовленный разработчик, очень легко совершить ошибку и получить более куда более страшное неопределённое поведение в расте, чем C++. Да, да, да. Ираст вид раста. Да. Если мы в безопасный раст принесём неопределённое поведение, мы больше не можем верить безопасному раст, правильно? И вся магия, что написал, скомпилировалась и оно уже валидно, она сразу же рушится, потому что ты написал, скомпилировался и получил получил segmentation f или ещё что-нибудь страшное. Да, и такое было и много раз. Да. Да. То есть как в зону ансейва входишь, а это любые либы, я так понимаю, которые глубоко копают. Та любые. э-э существующие старые либо на C и C++, да, это сразу же ансей плюс любое взаимодействие с каким-нибудь сырым API ядра, для которого нету безопасных обёртки, это тоже сразу же. Плюс uns довольно сложная штука. Изначально вот этот unсей в расте, он только про меory safety, да? А он же идёт куда глубже и дальше. Memory safety. Том ещё включается Safety, который тоже влияет на Memory Safety, а также ещё и другие виды безопасности. Ну, скажем, сделать так, чтобы нельзя было с чужими токенами авторизации куда-то подключиться, да, тоже требует какой-то saфти. Ты можешь думать о том, хочешь ли ты эту инкодить, эту safety в твоём языке или не хочешь. И некоторые библиотеки на раст они её энкодят. Что ты говоришь? У тебя функция unsafe, потому что если ты её используешь неправильно, она не поломает память, она тебе разрешит невтори неавторизированный доступ к каком какому-то ресурсу. Вот и начинаются вопросы: "А если мы её сделаем сейф, она же не ломает память". Знаешь, у меня какая всегда мысль по поводу раса, когда на всё это смотрю. бывает относительно, ну, так чуйкой понимаешь, вот этот язык реально будущее там по определённым причинам для определённых задач. Почему-то, когда каждый раз я смотрю на Раст, я, может, это моё личное только впечатление и всё, у меня не складывается впечатление, что это прямо сильно более лучший язык. Он он в этом плане как будто как ди э решает какие-то проблемы. Но вот сколько я слышу про Unт механику, ну нет такого, что говорят: "Блин, это реально следующий шаг, это эволюция, это лучше". Скорее говорят, что это альтернативный способ, в котором есть определённые задачи, которые выразить очень сложно, это очень геморройно, больно и так далее. И это звучит как не то, чтобы продолжение C++, а как альтернативный C++. Или это ошибочное мнение? И раст - это следующий этап. Это альтернатива. Действительно, все эти статические проверки лайфтаймов, они же как бы могут вполне себе существовать и вне языка. А, например, в том же C++ в Клан были попытки реализовать лайфтайм-анотации. Ну, если ты аннотируешь вообще весь код лайфтаймами, запускай статический анализатор, он проверит, что всё хорошо, что бесящих ссылок не остаётся. Ну, всё классно. РАСТ - это попытка сделать этот статический анализ принудительным. Ценой того, что, ну, код будет какой-то более привычный для менедж языков или для того же C, C++ и C, будет писать чуть более сложнее. Ну, там стандартный пример. Я хочу иметь ссылки на два разных элемента в хэш таблице и обновлять их параллельно. Ну, в смысле, одновременно хочу их обновлять. Ну, в Расте это было сделать, в сейф Расте это сделать было до последних обновлений, э, стандартной библиотеки почти не возможно, потому что, ну, ты не можешь иметь две мутабельные ссылки на один и тот же контейнер. Вот, господи, какой ужас. То есть, с одной стороны Раст решает много довольно тривиальных в узком скоупе проблем. То есть, если мы с мы лимитируем проблему до там пяти строчек, что вот здесь переменная, здесь мы передали ссылку, а тут мы пытаемся помутировать, как бы, ну, это ж очевидно, очевидно проблемы, что мы вот там поменяем или поломаем ссылку. Аэ, и если сфокусироваться на этом, сказать: "Ну, а зачем нам Раз для этого?" Но раз ты решает эту проблему на более длинной дистанции, когда у тебя очень много компонентов и ты между ними шаришь эти данные, тебе компилятор статически гарантирует, что такого не произойдёт. А если ты попытаешься так сделать, тебя компилятор либо, так сказать, отговорит от этого, либо он заставит тебя переписать всё приложение. И это, с одной стороны хорошо, с другой стороны, это замедлять разработку, правильно? Если если каждое изменение, если я добавил новый параметр в функцию, и теперь я должен обойти все свои 150 файлов, чтобы его правильно туда передать, ну да, я буду очень долго тратить это время. Не очень радостно, может быть, да. В связи с этим сразу вопрос: а не получится ли так, что как только раз станет вот более популярным, в этом смысле больше разработчиков, и они все наедятся и скажут: "Ребята, давайте следующий язык". И в итоге он окажется, что в него все очень активно быстро пошли, но очень быстро придумали язык, который реально является следующей имплементацией. Ну, я не говорю обязательно, что это Зик, тем более я про него вообще ничего не знаю, но вдруг он является именно тем самым языком, который действительно эволюция, где легче, проще или просто, знаешь, может быть, вообще вся проблема в том, что C++, то есть проблема, которую решают они при работе с тем, что тебе с памятью надо самому работать, она, в принципе, нерешаема никакими другими способами. То есть, грубо говоря, у тебя любое альтернативное решение - это компромисс, который будет стрелять в другом. И поэтому любой следующий язык тоже будет проблемный. Ну это правда. У тебя проблема безопасной работы с парамитью. У неё есть множество решений, там Garbage Коллектор, делаем всё менедж, да, и отдаём всё на откупч коллектору. Мы в этом случае жертвуем производительностью. Тенси у нас может быть непредсказуемый. Ну, опять-таки, зависит от конкретно коллектора, но почти, ну, но очень многие из них у тебя вызывают как-то Worldх Hup, да, надо подождать, пока отработает. Не обязательно для всех потоков, но всё равно есть подходы вот статические, как Раст делает. Он тебе просто не даёт писать. Ну, он сужает множество кода, которые ты можешь написать до чего-то, что удобри и может быть проверено. А всё остальное, ну, не пиши так, либо используй Unсей, если ты очень уверен. Есть ещё подход. Я вот видел там какой-то разработчик, вроде бы из Epic Games тоже какой-то отпачковался и делает ELC. Ну, ил это имени его себя любимого. А подход тоже довольно прямолинейный. Давайте не будем вообще менять C или C++. Давайте инструментируем все обращения к сырым указателям и к памяти и будем их проверять. Такой подход, естественно, имеет накладные расходы на перфоманс. И его ещё и любят практиковать в э в железе. Хардварный харденинг. То есть если у тебя инструкция чтения по какому-то адресу, то железо проверить, что этот адрес относительно валиден. То есть такой подход есть, то, что вообще давайте не будем делать язык, давайте просто инструментацию улучшим и будем её оптимизировать. Есть ещё варианты, что о'кей, давайте немножко совместим вариант, что наша проблема с ручным управлением памяти возникает в основном тогда, когда мы память освобождаем. Правильно? Если мы не будем освобождать память, висячих ссылок не будет, правильно? Потому что он мы же мы же мы же не удаляем объекты, значит, они все всегда валидные. Давайте просто не освобождать память. И я помню, в PVS-студии такой подход практиковали, что они там используют буферы, которые постоянно увеличиваются и никогда не освобождают память. Ну потому что зачем им освобождать память? Один раз проходит их анализатор, что-то выплюнул и дальше он закрывается и память всё равно будет освобождена. Такой более узкий такой же подход в Game Davви с их ареналокаторами и поколениями объектов. любят принимать. То есть вот у тебя начало обработки фрейма, ты выделил большущий буфер и в этом буфере работаешь в конце ничего не освобождаешь. В конце обработки фрейма, ну, просто удалил весь этот буфер и всё. То есть нет никаких проблем с двисячими ссылками. Ты просто просто не сохраняй ссылки между фреймами. Ну да, логично. Хм. Ну, в общем, да, то есть э появление новых языков в этом плане не будет прорывом. То есть у тебя будет просто опять же компромиссный какой-то вариант. Я почему про это спрашиваю? Пото что, да, раз не выглядит, опять же повторюсь, просто не выглядит чем-то эпичным. И поэтому я даже не удивляюсь и не удивлюсь, что многие C++шники, наверное, говорят так, что: "А почему бы не продолжить писать на плюсах, чтобы не мучиться? Тем более мы его знаем". И у нас теперь есть классные инструменты там в современных плюсах. Нет, я придумал. Ну и они прамы в каком-то смысле. Угу. Там, с другой стороны, там есть какое-нибудь исследование Гугла, Андроида, что вот, да, мы старый код на C и на C++ оставили, аминовый код только пишем на расте, теперь у нас меньше уязвимостей. Ну, ну тоже, наверное, правда. Я лично для себя пришёл к выводу, что это очень сильно домейн specific специфиic. РАСТ со всеми статическими гарантиями - это очень здорово, конечно. Классно, если это маленький компонент, да, ты можешь его очень хорошо так промазать статическими проверками, и тебе будет довольно удобно на расте писать, если это большой сервис с огромным количеством компонентов. Ну, каждый из них на расте. То есть, скажем так, это один процесс, один проект, всё компилируется в кучу, всё на расте. Со сложными нетривиальными data flow, то вот эти ограничения Раста, они тебя очень сильно замедлят в плане реализации новых фич. Да, у вас возможно, скорее, возможно, у вас будет всё оченьоченьочень безопасно, хотя опять-таки оно может быть безопасно с точки зрения memory safety, да, там буфер overflow не позволит злоумышленнику remote cд execution атаку провести какую-нибудь. Всё, всё здорово. Но из-за ограничений языка, чтобы писать, оставаясь в сейф подмножестве, вы нагородили какую-то совершенно другую архитектуру, там на акторах и на кучах каналов и этим самым создали неявно датарейсы. И теперь у вас другая уязвимость, что вот тут у вас проверка, авторизация, вот тут у вас запрос данных, и они меняются местами. Ну да, да, да. То есть ты можешь отдать данные до прохождения авторизации. Вы вот всё мемори сейф. Блиц вопрос. Если бы сейчас тебе предложили работу хорошую и говорят: "У нас раз-то нет и не будет, только плюсы". Ты бы пошёл? Я бы спросил, какой версии плюсы? М, пояснее, да, интересно. Я, честно говоря, не хотел бы работать с C++ до, э, скажем, семнадцатого стандарта, потому что это совсем. И какая фича там является для тебя ключевой? Концепты. Я, кстати, от тебя несколько раз слышал, но я вообще не понимаю, что это такое. Ну, это в двадцатом, ну, это в двадцатом стандарте. В семнадцатом там наконец-таки лямбда функции починили полностью. А, ну ладно. Тут, по крайней мере, я понимаю, понимаю, в чём более и что нужно было. Хорошо. А что за концепты? Расскажи. Вот это я вообще первый раз слышу. Как интерфейсы, только статические. То есть, если есть понимание, что такое трейды в расте, ну, это статический интерфейс, он может быть, конечно, ещё динамический, если удовлетворяет там ряду требований, но в основном статически с ограничениями на то, что, ну, грубо говоря, ограничение, что конкретно этот тип может сделать. C++сные концепты - это примерно то же самое, только немножко по-другому. Если ростовые трейты - это детище номинативной типизации, что вот что ты сказал, то ты и можешь делать. В случае C++ концептов это больше детящее структурной типизации и утиной типизации, да, что вот если оно похоже на то, что ты описал, значит оно это это оно. Ну и плюс в C+с-плюсных шаблонах, ну как проблема, в C++сплюсных шаблонах исторически утиная типизация. Ты там пишешь template t add. Ну оба из них Т. Пытаешься их сложить. Если оператор плюсик перегружен для этого, для этого типа т, то всё хорошо будет во время, когда ты попытаешься вызвать эту функцию. Если нет, ты получишь страшную ошибку компиляции. Substitution failed или ещё что-нибудь или cannot find operator plus для этих типов. И ты её получишь из тела функции, то есть не в моменте вызова функции, ты её получишь изнутри функции. Решение, ну, с помощью историческое решение с помощью техники сфиная. Давайте проверим, что у Т есть оператор плюсик. Если есть, тогда эта функция addд валидна, иначе мы её режектим и получаем ошибку компиляции в момент вызова этой функции, а не изнутри её. Техника сфина была чудовищно громоздкой. Тебе нужно было писать просто какие-то какую-то магию чёрную. И концепты C++ эту проблему решают тем, что предоставляют тебе нативный механизм, чтобы эту сфина и магию писать. Вместо того, чтобы писать странный набор специализаций и typeades, э, структур, которые проверяют, что у тебя есть, что у твоего класса S есть методфу, тебе там нужно было штуки три классов написать для этого, а ты пишешь просто концепт такой-то ТОМ методфу. Если оно компилируется, значит, концепт удовлетворён. Просто это синтаксический сахар и улучшение Quality of Life при использовании этих сфиная и всей всей шаблонной метамагии. Просто потому что писать шаблоны я люблю. А с одной стороны это пото что шаблоны свободны от почти свободные от неопределённого поведения. Очень много действительно шаблонного кода генерится в процессе жизнедеятельности любого проекта. Ну и плюс современный C++ ориентирован на писателей библиотек и на писателей шаблонов. Поэтому поэтому без концептов не хочется жить. Да. Как же хорошо, что а я пишу на тайпскрипте много и система типов тайпскрипта меня делает счастливым человеком. Вот. Ну просто очень много борьбы, конечно, в плюсах такой искусственной, скажем так, да. То есть там историческое наследие, ещё что-то. То есть всё это выглядит исторически в основном обосновано, к сожалению. Это капут просто какой-то. Я, честно говоря, не понимаю эту политику стандартизаторов комитета, потому что, с одной стороны, они пытаются поддерживать обратную совместимость со старыми версиями стандартов ESC. С другой стороны, они периодически эту поддержку отламывают. Ну, я думаю, там, ну, так, ну, давайте радикально хоть раз поломаем. У нас же есть флаги компиляторов. Ну, ну, ну, ну, ну, есть же. Вот если я указал C++ 20, я теперь хочу вот, чтобы у меня не было всего этого счастья с неявными привидениями и прочими. Ну, кстати, возможно, это сложнее реализовать. Это тебе внутри тоже как подумать такой код писать. Возможно, да, вендеры, возможно, отбивают это дело. Да, да, да. Не, тут, естественно, там много умных ребят, которые понимают, что делают в этом отношении. Вот эти попытки типа сбросить старьё и новое. Ты сам знаешь, к чему это часто приводит. И какой бы жест нам Linux показал? Linux, если бы мы его про это сказали? Это да. Не, нуже подожди. Ли ядро Linux оно си там C++ нету. Я про изменения сломать совместимость. Он у него есть однозначное мнение на на эту тему. Понятно. Хорошо. Смотри, давай зайдём с обратной стороны. Если мы берём плюсы и ты бы мог удалить какую-то одну самую раздражающую тебя фичу, что бы это было? А, неявное привидения типов, да, я хочу удалить неявные привидения типов. Это основная боль почти всегда. Оно порождает неявные копии. Неявные копии порождают часто, а, висячие ссылки, потому что ты получил ссылку на копию. Я хочу явный контроль над этим. Плюс это они ещё по по производительности постоянно бьют. То есть огромное количество докладов на разных метапах по C++, они посвящены тому, что вот мы взяли stringview viw вместо stdстн и у нас стало всё быстрее. Ну действительно, вы удалили кучу лишних копий. А если бы у вас этих неявных копий не было, вы бы сразу же об этом подумали, наверное. Вопрос, может быть, опять же, я тут до конца всю сложность не понимаю этого вопроса. Если ты берёшь тот же самый дз, в котором тоже есть такая проблема, но она скорее не про производительность, а в целом, что у тебя неявное, ну, поведение может быть совсем не то, но у тебя банально это линтером решается. То есть у тебя в тех местах, где есть преобразование, тебе линтер просто скажет: "Так нельзя, делай вот так". Это невозможно линтером порешать в плюсах. Линтером не уверен, но как ээ плагин анализатор с фидбком от компилятора, да, скорее всего, можно. Ты имеешь компилятор, который просто выдаёт э позволяет его инструментировать и выдавать инфу на тему вдруг появления этих ссылок. И он может, ты можешь там выводить: "О, у вас тут вот пошло". Да. Да. Вот тут. Ну, кстати говоря, вот кланг, ему за это респект, респект и уважуха. Очень много диагностик по умолчанию включены в кланги, в отличие от GCC. И да, он там про лишние мувы может сказать, но вот про лишние мувы сказать, а вот про неявные копии он редко может сказать. Хотя всё равно, да, инструментацию статического анализа дополняют и, ну, то есть тут две проблемы. Одна - это просто неявные копии, которые перфомансу делают плохо. Другая - это неявные копии, из-за которых потом временные объекты и висячие ссылки создаются. Вот вторую проблему до сообщества C++ разработчики компиляторов, статических анализаторов, они пытаются как как возможно решать, добавляют диагностики, ну там отдельные статические анализаторы, там тот же PV Studia, Tidйди, CPPчек, они пытаются это хотя бы хоть как-то отслеживать, но чтобы это делать, им нужно поддерживать всё многообразие грамматики C++, ээ парсить его. его кто-то полагается на то, что предоставляет лvм, кто-то пытается самостоятельно парсить. Ну я им ими нужно только восхищаться, что они пытаются это парсить, да. Хорошо. А в обратную сторону, опять же, учитывая, что ты так много работаешь с разтом и, может быть, чем-то ещё, чего в C++ точно не хватает с твоей точки зрения? Мне бы очень хотелось там видеть эш методы, чтобы вот вся эта проблема с обьюзом перегрузок операторов, чтобы добавить чейны обработки Rнже, на которую не может подсказать ни один ни один детерминированный анализатор кода, чтобы она была решена нативным способом более-менее. Э-э, да, хочу экстеншены методы, чтобы я написал точку и чтобы мне показало, что у него, что имеет этот тип, а что я в него добавил. Кстати, это настолько часто вот возникает история. Я вот для слушателей скажу, я сделаю обязательно отдельное видео, где немножко расскажу, что вообще понятие экшн методов, несмотря на то, что многие такие: "О, смотрите, какая крутая фича". На самом деле это, вообще-то, тоже хак для того, чтобы решить проблему того, что методы и данные засунули в одно место. И люди, которые писали функциональных, понимают, что, вообще-то, если это разделить и при этом по-человечески сделатьператоры там и всё остальное, у вас экстеншн методы просто будут не нужны. То есть у вас, грубо говоря, ядро языка будет намного более простым. При этом вы получите все те же самые фичи, не добавляя вот всей этой сложности. Это, кстати, очень неочевидная мысль, потому что многие воспринимают это как добро. Хотя на самом деле это, знаешь, за деревьями не видно лес. То есть люди уже не видят, насколько много сложных абстракций было накручено, и что многие новые фичи - это всего лишь фикс этих абстракций, а не какая-то крутая фича. Это да, не знаю, сколько ты про это знаешь, да, потому что экстрашен методы - это решение проблемы, которой вообще-то изначально могло и не быть. Вот если тупо не объединять методы с данными, да. Ну вот, да, в Расте в каком-то смысле методы и данные разделены, да? Ты отдельно объявляешь структуру, отдельно к ней дописываешь методы. Ты их можешь дописать, вообще-то, в любом файле своего проекта, а не только вот в том же, где объявил. Это будет только влиять на то, есть ли у тебя доступ к приватным полям или нету. Экстеншнов тоже в расти нету. Они, так сказать, случайно получаются с помощью этих трейтов. Да. Ты их тоже отдельно от данных реализуешь. Да. Да. А можно ещё проще через, ну, опять же, тут, конечно, уже зависит от там много всяких нюансиков, но в целом Unified Function call, когда у тебя вообще нет понятия методов, у тебя, грубо говоря, просто если первый параметр совпадает по типу, он просто автоматом может вызываться, например, через точку или опять же через пайп. То есть ты, в принципе, можешь не создавать такое понятие, как метод. В таком случае у тебя просто любая функция, она может вызываться либо так, либо так, в зависимости от того, что там пришло первым аргументом. Да, всё так. В C++ был и есть, наверное, всё ещё висит пропозил на Unified Function call syntax, но он вряд ли будет когда-либо принят. Ну, потому что, скорее всего, поломает обратную совместимость и логику, как идёт поиск перегрузок. Абсолютно верно. Да, кстати, вот понятно, что это немножко не в тему этого подкаста. Он буквально, я просто новость видел, что в новый PHP выходит пайоператор добавляют, да, чтобы у тебя как в хаскеле можно было вот так вот работать или там в эликсире так классно в F-шарпе пайп-оператора там прекрасный в Акаamле всё это добро там просто про проблема появляется что это полностью противоречит вот вызову через точки методом и если уж язык пошёл в одну сторону то, честно говоря, мне кажется, надо её придерживаться. Но это ладно, это уже так общее рассуждение сбоку. Хорошо, в принципе, смотри, по плюсам как будто бы всё. Честно скажу, что я такой думал: "Ну, может быть, я что-то недопонимаю и там всё проще". Нет, ни фига не проще. И действительно, эта штука такая меня как пугала, так и продолжает пугать. Но давай немножко прямо про обучение плюсам поговорим. Я думаю, ты подскажешь, что и как. Э, в двух словах, я помню, что давным-давно, будучи я на прикладной математике учился в универе, и у меня была книжка C++. Причём, кстати, по-моему, мы плюсы-то сами не проходили, пото что на прикладной математике там что-то другое было. Там си, по-моему, мы проходили. Но, короче, когда я открыл эту книжку, помнишь, такая чёрнозелёная такая книжка, толстая толстая вот такая вот. Я на пяти, ну, оно прямо такое какое-то фундаментальное было издание. В общем, я на пятидесятой страничке сломался. И более тебе того скажу, я на тот момент плюсы стали причиной, почему я на лет вообще забыл, что можно стать программистом, что это вообще интересно. То есть вот эта книжка сломала меня, да, травму получил. И потом спустя лет примерно шесть я про это, ну, как, короче, начал учить PHP, и вдруг оказалось, что программирование бывает очень разным. Так вот, допустим, человек, послушав нас, сказал: "Да, всё-таки C++ класс хочу, что делать? Что делать?" Есть много курсов, да, самых разных, интересных или не очень. Я точно знаю, что не, если хочется изучить C++, то не стоит начинать с книжки поси. Там вот старые вот, которые научат вас читать по символьное и использовать снеф. Вот их не надо использовать. Чтобы научиться писать на современном, скажем так, C++, нужно, ну, я не знаю, я курсов не видел таких. Нужна книжка, которая вот, скажем так, первые 60 страниц про указатели вообще ничего не будет говорить. Она вам покажет. Вот смотрите, какой классный язык там. Ладно, син, чтобы прочитать переменный. Ни одно ни одной ссылки, ни одного ни одной звёздочки, ни одного амперсанда ещё не появляется. Всё, красота, всё здорово. Потом вас должно научить ссылкам и передаче параметр по ссылкам. И вам этого на первое время должно хватать, чтобы написать какие-либо простейшие приложения типа калькуляторов или ещё чего-то. После этого можно уже знакомиться с указателями и решать, вы хотите в какую сторону C++ идти. Красивую, сияющую, которую нам обещал Страуструп, когда вот мы забудем про си полностью или в прикладную, которая, к сожалению, нужна людям. И там вот все эти указатели, сырая память, э кастомные локаторы и весь проче прочее безумие. Я не помню, я очень давно листал книжку Страуструп, этот Туров C++, он же Экскурс C++, а также экскурсия в C++. Вроде бы как раз-таки он, э, идёт без большого погружения в указатель. Возможно, стоит её посмотреть для начала. Понятно. Ну, а потом дивный мир шаблонов и всех тех вещей, о которых мы сегодня говорили, да? Потом дивный мир шаблонов. Да, в одной стороне будет дивный мир шаблонов, рефлексия и вся вся всявся вот эта красота, которую возможно будет на практике потрогать в трёх или четырёх компаниях, которые могут себе позволить использовать последние версии компиляторов. Ну а с другой стороны будет безумие, страдания C++ 11, дай бог, и компилятор GCC6. И макросы, да, и макросы, да, кстати, макросы, когда ты про них говоришь, я правильно понимаю, что они как всях такие же примерно дубовые или Ну это ж сишные макросы, да? Те самые. А, сишные макросы. Ну да, да, да. Я-то избалованный лисповыми макросами, да, для других нам не заводили, да. У меня уже другое восприятие этого слова. Слушай, я знаешь что понял? Всё, последний вопрос. Мы такие с тобой про C говорили, как будто вот, ну, типа вот C++, вот C. Но ведь на самом-то деле это же тоже в каком-то смысле конкуренты. То есть у тебя и те, и другие штуки на нижнем уровне пишут. А в этом плане что происходит? То есть они как-то вообще перетекают друг в друга или у тебя просто тупо есть вещи, которые на си написано, а есть на плюсах? Они перетекают. Расскажи. Из одного в другой, из и наоборот. И обратно тоже как хоббит. Например, сейчас вот в C наконец-таки добавили этот дирекэн

инклюlлюды. Директива, директива, директива Т, чтобы включить содержимое файла в твой исходник, да? Ну, например, ты хочешь массив чем-нибудь стро, да, заийнлайнить. Вот до последних 3 лет в C это было сделать почти невозможно средствами языка. И даже тебе нужен был либо какой-то свой собственный припроцессор, либо ты пишешь скрипт поверх всего это дела, а сейчас-то добавили. И оно перетекает в C++, потому что C++ не может не может средствами стандартной библиотеки не может предоставить шаблон для включения файлов. Ну вот не получается, ограничения технические мешают. Возможно, лет через пять придумают, как это обойти. в обратную сторону. Стати Косерт есть такой, а также всякие автовыводы типов, типа авто. Они из C++ в C перешли потихоньку. То есть они сначала перешли с такими странными для того, чтобы не сломать обратную совместимость, они перешли со странными ключевыми словами, типа нижнее подчёркивание S большое static ST. Это в C ушло. Сейчас его наконец-таки в нормальный вид переименовали. Теперь это просто статик assрt. Ты теперь можешь на этапе компиляции что-то что-то asсёртит в Conspor поддержки переходит из C++ в C, потому что, ну, в C - это была очень большая проблема, на самом деле, просто средствами языка, не макросами, объявить константу. Ну, понятное дело, просто число довольно легко написать, да, constчето равно равно что-то. А если у тебя какие-то сложные вычисления ты хочешь выполнить, то объявить такую константу в си, чтобы она была на самом деле константой, это очень сложно. Угу. И это перешло. Ты знаешь, что меня сейчас шокировал? Ты меня шокировал тем, что C развивается синтаксически, как язык. У меня, я не знаю, почему у меня в голове сложилось какое-то такое восприятие, что C когда-то застыл и с точки зрения именно синтаксиса он не меняется, а получается меняется, да. Там очень-очень маленькие такие хирургические изменения. добавили специальный синтаксис, чтобы временную переменную создать и сразу же на неё адрес взять. Ну там там очень интересные вещи появились. Я когда говорил про перетекание, я понял, что мы друг друга не совсем правильно поняли. Мой поинт был именно с точки зрения, вот мы говорим C++ и Rast, и то же самое C++ и C в плане, знаешь, того, что проекты переписываются. То есть какой какой смысл, да, в существовании этих То есть понимаешь, у тебя теперь три языка на самом деле. Ну вот это интересно, не я не видел, чтобы прям C++ на чистый C переписывали. Может быть, кто-то кто-то этим занимается. Ну C++ не заменил C. Да, он не заменил, он просто стал рядом и использует C вовсю просто. А зачем зачем ему зачем переписывать огромную кодовую базу на C на C++, если C++ содержит 95% C в себе? Ну, просто напрямую зовём и всё. То есть это, по-моему, это было просто такой стратегически верный ход, осознанный или неосознанный со стороны Строуструпа поддерживать обратную совместимость си, ну, почти до символа, да, там просто чтобы вот программа на C могла быть скомпилирована как программа на C++ почти в 95% случаев. Ну, это на самом деле известная, да, а с точки зрения движения языка это очень хорошо, да, это, слушай, у тебя все языки, которые пытаются подменить какой-то базовый язык, у них обязан быть интеро прозрачный абсолютно, cotle java, JavaScript Typeescript. Там есть просто определённый набор признаков, который должен сохраняться, чтобы ты просто расширение поменял, у тебя всё продолжило работать. Ну, конечно, такие вещи делаются осознанно, потому что это, в принципе, базовая история. Поэтому, собственно, всякие ди и другие не взлетели. Хотя вот можно сказать, что а вот раз же взлетел. Ди вроде бы имел какой-то интероп с си и с Точно, но это другой язык. Вот зик интересный вариант. У него есть интеро си из коробки. Ты можешь хедеры сишные, именно сишные, не C++плюсные, подключать и использовать. Ну и, наверное, в 9% случаев это работает. Там вопрос ещё в типах. То есть если у тебя другие типы, то появляется проблема, потому что, ну, трансляция сразу и всё такое. Поэтому, смотря, что в зиге реализовано. Если у него сишные типы, то тогда интеро будет прозрачный. То есть даже синтаксически он может выглядеть, да? Там там у него у него почти все сишные типы есть. Там вроде бы с битфилдами какие-то проблемы были и с zero size ареями тоже это хак сишми довольны, да. Короче, если подводить итог про C и плюсы, на C пишется что-то новое или речь идёт о том, что на C просто написана куча большого серьёзного кода, который бесконечное количество времени теперь будет поддерживаться, а, но в целом на C новое ничего не пишут или нет? Это всё-таки с плюсами они где-то разъезжаются в этом плане. К сожалению, ну или к счастью пишут ядро Линукс оно на C новые части на C пишет. Ну это опять же исторический проект. А вот новые, но а новые новые не уверен, вот я не могу не не то, ну то есть как будто бы нет смысла, да, на C начинать проект. Большого смысла нету. Большого смысла нету, за исключением, если есть какие-то исторические обоснования. Но прямо большого смысла нету, если нет религиозной какой-то убеждённости, что вот C во всём лучше, чем C++. И в плане читаемости и понимаемости проектов проекты на C они, конечно же, более понятные, чем C++. Неудивительно, [смех] что, ну, то есть я могу вот сказать: "О'кей, я у меня нету нового проекта, есть просто существующая кодовая база на C, она придерживается подхода". Ну вот как в геймдеве любят выделить одинфер и использовать и лоцировать всё в нём и ничего не очищать, да, там оче в этой кодовой базе очень приятно и удобно дописывать ээ в 90% случаях новые функции, потому что, ну, ты не думаешь обо всей этой марокке, кто там эту память очистит. Я просто пишут это, добавить это туда. Я знаю, что она всё всегда будет живо и всё здорово. Никаких проблем нет. Кстати, в HTTP серверах тоже такой подход используется, так сказать, создаётся контекстрепроса, и вот всё там живёт, ничего не не дилоцируется до тех пор, пока реквест не будет обработан, потому что это упрощает, да. А и это более производительно, в том числе. Угу. Инкс, кстати, на чём написан? Джинкс как раз-таки этим Да, он насях написан. И как раз-таки этот же подход там и используется. Ну что, Дим, спасибо тебе большое. Посветил нас ты немножко в этот дивный мир, весёлый, магический, не для всех, я бы сказал. Ребят, напишите, кто пишет на плюсах, так ли это всё? Дайкиньте каких-то хороших историй про СИ Плюсплюс, проси, может быть, про переход на Раст, если у вас такое есть, и обратно, если такое тоже есть. А интересно послушать, потому что для меня, говорю, это всегда такие какие-то отдельные люди, супермены, которые решают сложные задачи, а я слишком туп и в вебе пишу всякую фигню для бизнеса. Да, кстати, про про переход на раст. Вот я полтора года последние в AWS, в Клоудфронте как раз-таки занимаюсь тем, что, ну, относительно небольшая а кодовая база на C++, ну, там что-то около 40.000 срок, плюс ещё столько же тестов, наверное, переписывается на РАСТ. Ну, по полтора года это занимает. Ну не потому, что это так сложно переписать, а потому что когда ты переписываешь э что-то с одного языка на другой, а тебе это нужно дальше подсунуть в существующую систему, у тебя начинаются проблемы, а как это сделать безопасно? О'кей, ты написал на безопасном языке, на расте всё здорово. никакой Zero Unsafe, но а вдруг у тебя там баг, кото который не был никогда покрыт тестами, потому что все чкейсы вам недоступны, и ты выполнишь замену одного сервиса на другой и думаешь, что всё будет классно, а потом аутач на 30% интернета. Вотвот я и хотел сказать, а потом у тебя полнтернета не работает, и мы такие: "Опять Amazon там что-то намутил". Да. Так что с этим надо быть поаккуратней. Дим, спасибо тебе, спасибо, что смотрели, слушали. Всем пока. До новых встреч. Пока.