> Для вызова кода из с++ из библиотеки нужно обернуть его в unsafe. А unsafe делает код на раст менее безопасным. Кажется это ввзов функции на c++ делает его менее безопасным :)
Решающее значение имеет не удобство написания кода, zero abstraction, memory safety, и прочие технические детали, а пресвятая пара: СТАНДАРТ и КОМИТЕТ. Без СТАНДАРТА и КОМИТЕТА проекты с жизненным циклом более 30-ти лет: такие, как те же Unreal Engine или WebKit - в принципе невозможны. Язык, обделённый СТАНДАРТОМ и КОМИТЕТОМ, и как следствие, имеющий только одну реализацию, а не множество альтернативных - на длинной дистанции обречён. Как обречена и Мозилла, затеявшая весь этот блудняк с мертворожденным Servo и новым языком под него, вместо концентрации на реально хорошем Firefox.
@@bigtuedsay места разные везде. Вакансии на плюсах есть в местах куда Java никогда не придёт по причинам, как минимум, high load и embedded что разные стороны одной и той же проблемы "в железо не влазит/жрёт слишком много" и вот на примере этих двух областей может быть и зарплата и зряплата :) Жаль в Зеленограде нет офиса, например, Яндекса :) не променяю я хорошую зарплату на ежедневные прогулки на работу и с работы по лесу.
@@bigtuedsay во, я понял где так. Меня сегодня очень настойчиво с формулировкой "разработчик программного обеспечения (в основном C++, немного Java (только в рамках Android), и совсем чуть чуть Python)" зовут Team Lead-ом в Java команду на зарплату 300к деревянных. И... в гробу я видел банковский сектор с их гестапо, пусть ищут дальше терпил и любителей концлагеря. Java очень много в банковском секторе, там конские зарплаты, но такое гестапо, что кроме как временную подработку я бы такое рассматривать не стал.
@@HedgehogInTheCPP Стоит во дворе автомат по продаже воды, в один морозный зимний вечер узрел на монохромном дисплее описание исключения, которое выкинула Java: будка к серверу подключиться не могла. Так что всё индивидуально
Интересно узнать, как в mission critical приложении на С++ заменить, скажем без изменения полей, метод в классе, не останавливая приложение ? А если изменились поля ? А если в новом коде ошибка, как не упасть или подняться после падения. Это к тому что С++ НЕ универсален, и вообще такого универсального языка быть не может. Если вы надёжно реализуете такой функционал, то получится очередной Common Lisp, Erlang, Java etc. и замедление в тех аспектах, которые потребовали специальных приседаний. Фанатики С++ часто упускают из вида, что язык для базовых задач конечно близок по производительности к Си и за счёт метапрограммирования даже может его где то обходить, но если добавлять специфику, от былой шустрости не останется и следа ! Монструозная система классов, шаблонов и прочих нагромождений из новых стандартов это скорей попытка сохранить универсальность, чем реальная помощь в какой то задаче. Кроме того это в некотором роде давно устарело, например говорилось про перевод шаблонов для использования в constexpr окружении. Но давным давно существовали языки, которые могли в compile time использовать сами себя для определения всех конструкций, а С++ лишь очень частично реализовал этот функционал и использует не полноценный С++, а весьма урезанный по функциональности, а до этого вообще была эра извратов на шаблонах.
Речь о динамической линковке в runtime? - LoadLibrary в Windows и dlopen/dlsym в Linux, но если нужно что-то общее, то можно поискать библиотеку (вроде boost.dll)
Спикер хочет не чтобы она была решена в Rust, а хочет чтобы фанатики Rust не говорили что она решена в этом ЯП. И не решена она как раз потому что это фундаментальная проблема алгоритмов. А значит от ЯП решение проблемы не зависит
Managed язык не может работать без виртуальной машины, писанной на С++. С чего бы это ? Такую машину можно написать на любом другом "системном языке", хоть Pascal, скорей всего Си, так как для С++ там и размаха толком не будет. Кроме того у С++ такой жирный рантайм, что до недавнего времени писали на С, чтобы влазило в контроллеры, я работал в такой конторе !
Он не говорил, что не может работать без c++. Речь, которую ты слушаешь интерпретируй правильно. Без спорно можно использовать другие языки. Но КАК ПРАВИЛО используют C++ . Та же JVM на нём написана
3D моделирование? Не всё так однозначно, Blender на голёмом C по большей части, ровно как и многие-многие программы микроконтроллеров Так что выбора по крайней мере два
ИМХО, область применения manage-языков намного шире, чем область применения С++. И вот почему. 1. На несколько порядков иной раз легче порог вхождения. Следовательно ресурс из рабочей силы более доступен нанимателю. Кроме того, с помощью manage-языков часто гораздо быстрее создать работающий прототип приложения, чем на C++. А это иной раз может быть огромным конкурентным преимуществом в сравнении с иной раз мифической производительностью C++. Почему мифической? Потому что для того, чтобы её достичь на практике (а не в теории), надо обладать очень глубокими знаниями, как в области алгоритмизации, так и в особенностях языка и соответствующих программных инструментов. О чём чуть ниже. 2. Далеко не везде нужна сверхпроизводительность. А там, где нужна, часто (не всегда) дешевле купить более мощное железо, чем содержать команду высококвалифицированных программистов на C++. Да и не факт, что эти программисты действительно высокопрофессиональны. Читал рассказ, как один человек за 6 месяцев с помощью F# оптимизировал на известной американской бирже то, что команда из примерно 20 программистов (точную цифру не помню, но она близка к этой) на C++ не смогла за несколько лет. Приводить компании мирового уровня для того, чтобы оправдать 5% прироста производительности в датацентрах - это манипуляция в чистом виде, потому что ну сколько на самом деле таких компаний? 3. Ошибки программистов, исправляемые в автоматическом режиме интерпретаторами и/или компиляторами manage-языков, обходятся намного дешевле, чем ошибки программистов на C++. В начале выступления прозвучал тезис о том, что C++ безопасен. И откуда столько новостей о memory leaks в разных продуктах, написанных на C++? И почему программисты из Microsoft решили очень настойчиво посмотреть в сторону того же Rust? Конечно же я не пытаюсь отрицать важность необходимости C++ в настоящее время. Просто не понравились манипулятивные выпады в выступлениях Антона в сторону manage-языков. Недостатки их он как бы указал, но о преимуществах решил подзабыть (разве что к самому концу обозначив недостатки C++, которые одновременно являются преимуществом manage-языков). PS. Про поддержку стандартов C++ его компиляторами - это отдельная интересная тема. Стандарты как бы есть, а вот полноценная поддержка далеко не всегда присутствует, а если присутствует, то не всегда в полном объёме. Такая себе "кросс-платформенность". Почему выступающий об этом ничего не сказал, остаётся только догадываться. en.cppreference.com/w/cpp/compiler_support
Вы отстали от жизни и по факту верен только первый пункт, а именно быдлокодер обойдется дешевле. А дальше можно сразу не читать т.к. теорию алгоритмов обязан знать каждый нормальный программист.
@@Gimli_Dwarf Знать - это одно. А уметь всегда правильно применять - это совершенно другое. Вы всё-таки попробуйте не только прочитать дальше первого пункта, а ещё попытаться осмыслить с точки зрения работодателя эти тезисы. Можно было бы ещё добавить и просто производительность труда на разных языках в разных сферах применения при прочих равных условиях.
@@anst9017 никто и не говорит о знании всего, но алгоритмы, принципы работы вычислительных машин и математику программист знать обязан. А то бывает такое, что большое О за мат воспринимают.
@@ЮрийПопов-л6я я использовал Python для прототипирования до 11 стандарта, зачем использовать после так и не придумал ибо потом переписывать всё равно на плюсы. На счёт матлаба: всё больше и больше математики появляется в плюсах из коробки, это очень радует.С каждым новым стандартом немного велосипедов из кода удаётся выкинуть и это очень хорошо, пусть оптимизации делает компилятор и гораздо большая команда математиков.
@@ЮрийПопов-л6я P.S. на математике из коробки правда торчат детали реализации в железе в области математики, но для общих целей подходит sin(pi) = 1.2246467991473532e-16 cos(pi/2) = 6.123233995736766e-17 cos(pi/3) = 0.5000000000000001 всё стандартное, включая pi из C++20 numbers::pi_v и хотелось бы использовать большие числа кроссплатформенно на уровне стандарта. Как с плавающей точкой так и фиксированные и целочисленные, ну т. е. 128, 256, 512 и 1024 битные как минимум.
Мне нравится современный C++ по сравнению со всеми альтернативами, Rust не греет ни разу. Здесь я написал много, но критикую лишь необъективность высказываний и в прошлом имел дело с радикалами от крестов :-) По поводу сборщика мусора тот самый случай: подмена понятия "стоимость управления памятью" на "накладные расходы на сборку мусора". Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения ! В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно, и заметно, что там, где разработчики чувствуют себя свободнее в плане управления памятью, и алгоритмы совершеннее (динамические языки, функциональные языки). Преждевременная оптимизация часто стоит очень дорого, вплоть до отказа от языка (одно из слабых мест C++ в современной разработке из-за чего могут выбрать Java или C#). Сборщики мусора бывают Real Time (т.е. гарантирующие некое время отклика системы), тем более современные сборщики обычно многопоточные и не тормозят-лочат весь мир. Бывают как Erlang машине локальные "сборщики", очень эффективные, на них никто ещё не жаловался. Есть же сборщики и для C++, почему его надо противопоставлять управляемым языкам ??? Архитектура может быть разной. Почему бы крупные объекты не держать на сборке, чтобы удешевить разработку, а мелкие передавать по значению и локально по ссылкам ?
Вы пишете: *Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения* Не извиняю. Архаичные счетчики несопоставимо дешевле мусоросборки.
Вы пишете: *В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно* Это какой то бессмысленный набор слов.
@@princessmary5556 попробуйте соорудить некую сложную структуру вроде дерева с циклами пользуясь только классическим RAII на стеке, может поймёте о чём я. Сборщик мусора выигрывает за счёт "оптовости" когда огромное количество объектов друг на друга ссылаются и передаются туда сюда, постоянно щёлкать счётчиком и ссылка на общий счётчик вместе с самим счётчиком - не бесплатна, и может быть враждебна кэшированию в процессоре. Убирать поколениями или как Erlang целыми пулами может быть выгодней. И я даже не говорю, что это совсем невозможно реализовать в C++, может быть только в нём и возможно такое сделать на самом языке не вламываясь в компилятор.
@@IExSetЭффективность архаичных счетчиков очевидна любому человеку, который хотя бы чутка понимает принцип их действия. И нужно быть реально тупым дебилом, что думать, будто бы это вранье.
А вы уверены что приложение которым вы пользуетесь написано на java? 😂 Думаю от Java там лишь new Window(), а дальше управление на себя берет c++ или kotlin native. Есть правда и хуже вариант React/javascript 😅
Если №6 переформулировать как "сборка мусора дешевле чем ручное управление" то оно уже не будет заблуждением. Понятно что так или иначе памятью приходится управлять, но "микроменеджмент" с постоянными "микропроверками" на предмет живо оно или уже нет выходит дороже.
Кто бы что не говорил С++ хороший язык программирования. А изучение Rust - это риск, так как он может завтра умереть и есть ряд других причин отсутствие вакансии, комьюнити и т. д. . Так что С++ намного предпочтительнее.
Это и есть главное преимущество С++, что он хоть более менее всем знаком и как то живёт с припарками, хорошая поддержка, компиляторы и библиотеки. Насчёт "хороший язык программирования", кхм. Назвать это нагромождение стихийно образовавшихся фич хорошим в смысле красивым, язык не поворачивается. Фанатам крестов привет !
Спустя 3 года с выхода доклада Раст - цветет и пахнет. Популярность растет. Как пример - пустили в ядро линукс (а почему не пустили плюсы?). Хорошо, что не прогадал в свое время с выбором основного яп ) Выбравшим плюсы - сочувствую ...
Думаю это выдача желаемого за действительное, включая банкомат, на кой там С++ ???? С++ якобы везде, но доказательств этому нет. Например в Machine Learning рулят Python, Julia, R, может Яндекс что то скрытно пишет на С++ ? :-) Если бы всё писали на С++, то было бы море вакансий. Но фактически бизнес компании пишут на C#, Java, Python. Под контроллеры по крайней мере ещё недавно большей частью галимый Си, его то не надо с С++ смешивать, это совершенно другой язык, это к вопросу о дефибрилляторах :-) Ядра каких ОС написаны на С++ ? Их можно пересчитать по пальцам. С++ в Mission Critical приложениях ? Это жестоко. Тот же Erlang не свалить, а С++...хе хе. Кроме того С++ не годится там где надо на DSL часто менять некие описания, сценарии и т.п., хотя может кто то так и делает (злобные такие буратины). То что Яндекс его применяет, это такая фишка самого Яндекса. Крупномасштабное проектирование на С++ довольно сложная штука, язык требует слишком много внимания к низкоуровневым деталям, не давая сосредоточиться на крупных аспектах. Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок. Получается полезная штука, но переоценивать не стоит.
"В ML рулят Python, Julia, R,...откуда тут возьмется C++?" - tensorflow/pytorch/etc почти полностью написаны на C++, если исключить обертки, - вот numpy на C, но ему сколько лет уже, как говорится?) - Но тут больше ода соглашениям о вызовах будет, как мне кажется "Фактически бизнес компании пишут на C#/Java/Python/Javscript/etc" - так и есть: продуктовые фичи в основном "доставляют" на том, на чем не нужно (по началу) заморачиваться о памяти и хотел было написать скорости, но тут уже давно не так, и вопрос состоит в том "на сколько быстро мы хотим чтобы что-то работало" *что забавно: в том же питоне уже дошли до того уровня, что нормальный программист должен знать как структуру уложить в стэк без оверхэда (привет __slot__), а джависты compile-time фреймворки осваивают с кодогенерацией (привет Dagger), и много-много чего ещё в других языках, что приводит к мысли: "слушайте, а почему мы к этому пришли и почему стало так неудобно? - Вот в {await GetNextMyFavoriteLanguage()} это сделано лучше") В общем, имхо, но фраза "Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок" скорее относится ко всем языкам программирования, как только программист уходит за рамки написания базовых вещей, и в настоящее время уже начинает казаться, что решение выбрать тот или иной язык для написания конкретных вещей зависит от A. Платформы, B. Изначальных потребностей компании, C. Стоимость программистов с нужными знаниями (или их обучением) на рынке, естественно D. Знаний/пожеланий участников команды разработки (порядок пунктов расположить в зависимости от пожеланий)
смотрю из 2023, std::format до сих пор нигде, держу в курсе
И код из примеров на расте и плюсах компилятся в одинаковый код на асм )
всегда есть fmt
> Для вызова кода из с++ из библиотеки нужно обернуть его в unsafe. А unsafe делает код на раст менее безопасным.
Кажется это ввзов функции на c++ делает его менее безопасным :)
В списке сравнений языков нет Visual Basic, случайность? или боязнь конкуренции? :))
он мёртв
Это сарказм?)
@@dont_know_who_ юмор :))
Угар
Лютейше интересно слушать.
Благодаря таким парням С++ рулит!
Антон Полухин - просто зверь в этом деле.
С++ рулит!!!!
Кто может сказать что за библиотека регулярок от "Ханны" ? Как это гуглиться?
boost.hana
github.com/hanickadot/compile-time-regular-expressions
Hana Dusikova, Compile Time Regular Expressions
На отсутствии изкоробочности расплакался
Спасибо, было интересно.
Решающее значение имеет не удобство написания кода, zero abstraction, memory safety, и прочие технические детали, а пресвятая пара: СТАНДАРТ и КОМИТЕТ.
Без СТАНДАРТА и КОМИТЕТА проекты с жизненным циклом более 30-ти лет: такие, как те же Unreal Engine или WebKit - в принципе невозможны.
Язык, обделённый СТАНДАРТОМ и КОМИТЕТОМ, и как следствие, имеющий только одну реализацию, а не множество альтернативных - на длинной дистанции обречён.
Как обречена и Мозилла, затеявшая весь этот блудняк с мертворожденным Servo и новым языком под него, вместо концентрации на реально хорошем Firefox.
А как называется сервис, в котором код в ассембли переводится
Нашел уже, если кому надо - godbolt
Компилятор
Godbolt
Всё так, только Senior C++ Dev получает зарплату как Junior Java Dev. Как так?
это где такое видано?))
@@bigtuedsay В Питере года три назад, когда нас собирались "оптимизировать'. У вас разве не так?
@@bigtuedsay места разные везде. Вакансии на плюсах есть в местах куда Java никогда не придёт по причинам, как минимум, high load и embedded что разные стороны одной и той же проблемы "в железо не влазит/жрёт слишком много" и вот на примере этих двух областей может быть и зарплата и зряплата :)
Жаль в Зеленограде нет офиса, например, Яндекса :) не променяю я хорошую зарплату на ежедневные прогулки на работу и с работы по лесу.
@@bigtuedsay во, я понял где так. Меня сегодня очень настойчиво с формулировкой "разработчик программного обеспечения (в основном C++, немного Java (только в рамках Android), и совсем чуть чуть Python)" зовут Team Lead-ом в Java команду на зарплату 300к деревянных. И... в гробу я видел банковский сектор с их гестапо, пусть ищут дальше терпил и любителей концлагеря. Java очень много в банковском секторе, там конские зарплаты, но такое гестапо, что кроме как временную подработку я бы такое рассматривать не стал.
@@HedgehogInTheCPP Стоит во дворе автомат по продаже воды, в один морозный зимний вечер узрел на монохромном дисплее описание исключения, которое выкинула Java: будка к серверу подключиться не могла.
Так что всё индивидуально
Интересно узнать, как в mission critical приложении на С++ заменить, скажем без изменения полей, метод в классе, не останавливая приложение ? А если изменились поля ? А если в новом коде ошибка, как не упасть или подняться после падения. Это к тому что С++ НЕ универсален, и вообще такого универсального языка быть не может. Если вы надёжно реализуете такой функционал, то получится очередной Common Lisp, Erlang, Java etc. и замедление в тех аспектах, которые потребовали специальных приседаний. Фанатики С++ часто упускают из вида, что язык для базовых задач конечно близок по производительности к Си и за счёт метапрограммирования даже может его где то обходить, но если добавлять специфику, от былой шустрости не останется и следа ! Монструозная система классов, шаблонов и прочих нагромождений из новых стандартов это скорей попытка сохранить универсальность, чем реальная помощь в какой то задаче. Кроме того это в некотором роде давно устарело, например говорилось про перевод шаблонов для использования в constexpr окружении. Но давным давно существовали языки, которые могли в compile time использовать сами себя для определения всех конструкций, а С++ лишь очень частично реализовал этот функционал и использует не полноценный С++, а весьма урезанный по функциональности, а до этого вообще была эра извратов на шаблонах.
Речь о динамической линковке в runtime? - LoadLibrary в Windows и dlopen/dlsym в Linux, но если нужно что-то общее, то можно поискать библиотеку (вроде boost.dll)
У вас проблема с проектированием, и от этого и все эти велосипеды
Проблема остановки -- фундаментальная проблема теории алгоритмов. А спикер хочет что бы раст ее смог решил
Спикер хочет не чтобы она была решена в Rust, а хочет чтобы фанатики Rust не говорили что она решена в этом ЯП. И не решена она как раз потому что это фундаментальная проблема алгоритмов. А значит от ЯП решение проблемы не зависит
Майнкрафт поддерживает хорошую графику, просто надо указать качество текстуры и меняй спокойно
Потому что он уже переписан на с++ Майкрософтом
@@Roman-rx9op хахаха, от языка не зависит графика
@@daishinkan12 ещё как зависит. Если бы не зависела, то все писали бы графику на Python. Увы Python слишком медленный.
@@cppprograms5868 да, она не зависит. Python медленный, но это не мешает сделать какую нибудь 16к графику. Ты прочитай внимательнее
@@daishinkan12 в риалтайме?)
достаточно исключить то что нельзя сделать на cpp
Даже то что можно сделать на С++ часто получается слишком дорого делать на С++. Достаточно исключить то, что нельзя сделать на Си или ассемблере :-)
@@IExSet Вы пишете какое то бла бла бла. Поконкретнее, пожалуйста.
Managed язык не может работать без виртуальной машины, писанной на С++. С чего бы это ? Такую машину можно написать на любом другом "системном языке", хоть Pascal, скорей всего Си, так как для С++ там и размаха толком не будет. Кроме того у С++ такой жирный рантайм, что до недавнего времени писали на С, чтобы влазило в контроллеры, я работал в такой конторе !
Он не говорил, что не может работать без c++. Речь, которую ты слушаешь интерпретируй правильно. Без спорно можно использовать другие языки. Но КАК ПРАВИЛО используют C++ . Та же JVM на нём написана
Carbon?
3D моделирование? Не всё так однозначно, Blender на голёмом C по большей части, ровно как и многие-многие программы микроконтроллеров
Так что выбора по крайней мере два
наверное имеется ввиду С/С++
ИМХО, область применения manage-языков намного шире, чем область применения С++. И вот почему.
1. На несколько порядков иной раз легче порог вхождения. Следовательно ресурс из рабочей силы более доступен нанимателю.
Кроме того, с помощью manage-языков часто гораздо быстрее создать работающий прототип приложения, чем на C++. А это иной раз может быть огромным конкурентным преимуществом в сравнении с иной раз мифической производительностью C++. Почему мифической? Потому что для того, чтобы её достичь на практике (а не в теории), надо обладать очень глубокими знаниями, как в области алгоритмизации, так и в особенностях языка и соответствующих программных инструментов. О чём чуть ниже.
2. Далеко не везде нужна сверхпроизводительность. А там, где нужна, часто (не всегда) дешевле купить более мощное железо, чем содержать команду высококвалифицированных программистов на C++. Да и не факт, что эти программисты действительно высокопрофессиональны. Читал рассказ, как один человек за 6 месяцев с помощью F# оптимизировал на известной американской бирже то, что команда из примерно 20 программистов (точную цифру не помню, но она близка к этой) на C++ не смогла за несколько лет.
Приводить компании мирового уровня для того, чтобы оправдать 5% прироста производительности в датацентрах - это манипуляция в чистом виде, потому что ну сколько на самом деле таких компаний?
3. Ошибки программистов, исправляемые в автоматическом режиме интерпретаторами и/или компиляторами manage-языков, обходятся намного дешевле, чем ошибки программистов на C++. В начале выступления прозвучал тезис о том, что C++ безопасен. И откуда столько новостей о memory leaks в разных продуктах, написанных на C++? И почему программисты из Microsoft решили очень настойчиво посмотреть в сторону того же Rust?
Конечно же я не пытаюсь отрицать важность необходимости C++ в настоящее время. Просто не понравились манипулятивные выпады в выступлениях Антона в сторону manage-языков. Недостатки их он как бы указал, но о преимуществах решил подзабыть (разве что к самому концу обозначив недостатки C++, которые одновременно являются преимуществом manage-языков).
PS. Про поддержку стандартов C++ его компиляторами - это отдельная интересная тема. Стандарты как бы есть, а вот полноценная поддержка далеко не всегда присутствует, а если присутствует, то не всегда в полном объёме. Такая себе "кросс-платформенность". Почему выступающий об этом ничего не сказал, остаётся только догадываться.
en.cppreference.com/w/cpp/compiler_support
Вы отстали от жизни и по факту верен только первый пункт, а именно быдлокодер обойдется дешевле. А дальше можно сразу не читать т.к. теорию алгоритмов обязан знать каждый нормальный программист.
@@Gimli_Dwarf Знать - это одно. А уметь всегда правильно применять - это совершенно другое. Вы всё-таки попробуйте не только прочитать дальше первого пункта, а ещё попытаться осмыслить с точки зрения работодателя эти тезисы. Можно было бы ещё добавить и просто производительность труда на разных языках в разных сферах применения при прочих равных условиях.
@@anst9017 так-то знать и означает уметь применять. Кто не умеет что-то применить значит он и не знает
@@Gimli_Dwarf Всего на свете знать невозможно. Это прекрасно продемонстрировал лектор (смотрите комментарии ниже от других пользователей).
@@anst9017 никто и не говорит о знании всего, но алгоритмы, принципы работы вычислительных машин и математику программист знать обязан. А то бывает такое, что большое О за мат воспринимают.
эх, используется везде, а вакансий нет
Это для эстетов язык. Я пользую изза скорости вычислений. Рчдом ниче не стояло. А так по быстрому прототип матлаб питон.
@@ЮрийПопов-л6я я использовал Python для прототипирования до 11 стандарта, зачем использовать после так и не придумал ибо потом переписывать всё равно на плюсы. На счёт матлаба: всё больше и больше математики появляется в плюсах из коробки, это очень радует.С каждым новым стандартом немного велосипедов из кода удаётся выкинуть и это очень хорошо, пусть оптимизации делает компилятор и гораздо большая команда математиков.
@@ЮрийПопов-л6я P.S. на математике из коробки правда торчат детали реализации в железе в области математики, но для общих целей подходит
sin(pi) = 1.2246467991473532e-16
cos(pi/2) = 6.123233995736766e-17
cos(pi/3) = 0.5000000000000001
всё стандартное, включая pi из C++20 numbers::pi_v
и хотелось бы использовать большие числа кроссплатформенно на уровне стандарта. Как с плавающей точкой так и фиксированные и целочисленные, ну т. е. 128, 256, 512 и 1024 битные как минимум.
На С++ вакансий нет?
Мне нравится современный C++ по сравнению со всеми альтернативами, Rust не греет ни разу. Здесь я написал много, но критикую лишь необъективность высказываний и в прошлом имел дело с радикалами от крестов :-) По поводу сборщика мусора тот самый случай: подмена понятия "стоимость управления памятью" на "накладные расходы на сборку мусора". Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения ! В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно, и заметно, что там, где разработчики чувствуют себя свободнее в плане управления памятью, и алгоритмы совершеннее (динамические языки, функциональные языки). Преждевременная оптимизация часто стоит очень дорого, вплоть до отказа от языка (одно из слабых мест C++ в современной разработке из-за чего могут выбрать Java или C#). Сборщики мусора бывают Real Time (т.е. гарантирующие некое время отклика системы), тем более современные сборщики обычно многопоточные и не тормозят-лочат весь мир. Бывают как Erlang машине локальные "сборщики", очень эффективные, на них никто ещё не жаловался. Есть же сборщики и для C++, почему его надо противопоставлять управляемым языкам ??? Архитектура может быть разной. Почему бы крупные объекты не держать на сборке, чтобы удешевить разработку, а мелкие передавать по значению и локально по ссылкам ?
Вы пишете: *Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения* Не извиняю. Архаичные счетчики несопоставимо дешевле мусоросборки.
Вы пишете: *В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно* Это какой то бессмысленный набор слов.
@@princessmary5556 это враньё конечно, нифига не дешевле
@@princessmary5556 попробуйте соорудить некую сложную структуру вроде дерева с циклами пользуясь только классическим RAII на стеке, может поймёте о чём я. Сборщик мусора выигрывает за счёт "оптовости" когда огромное количество объектов друг на друга ссылаются и передаются туда сюда, постоянно щёлкать счётчиком и ссылка на общий счётчик вместе с самим счётчиком - не бесплатна, и может быть враждебна кэшированию в процессоре. Убирать поколениями или как Erlang целыми пулами может быть выгодней. И я даже не говорю, что это совсем невозможно реализовать в C++, может быть только в нём и возможно такое сделать на самом языке не вламываясь в компилятор.
@@IExSetЭффективность архаичных счетчиков очевидна любому человеку, который хотя бы чутка понимает принцип их действия. И нужно быть реально тупым дебилом, что думать, будто бы это вранье.
Насчёт Java, забавно слышать это на фоне успеха Java под Android, вроде вопрос размера виртуальной машины и библиотек там никого не колышит.
А вы уверены что приложение которым вы пользуетесь написано на java? 😂 Думаю от Java там лишь new Window(), а дальше управление на себя берет c++ или kotlin native. Есть правда и хуже вариант React/javascript 😅
Если №6 переформулировать как "сборка мусора дешевле чем ручное управление" то оно уже не будет заблуждением. Понятно что так или иначе памятью приходится управлять, но "микроменеджмент" с постоянными "микропроверками" на предмет живо оно или уже нет выходит дороже.
Кроме того есть RT сборщики мусора и помогает умение не мусорить, чтобы не убирать.
А разве что-то может заменить С++?
Зависит от предметной области.
В какой нише ?
Кто бы что не говорил С++ хороший язык программирования. А изучение Rust - это риск, так как он может завтра умереть и есть ряд других причин отсутствие вакансии, комьюнити и т. д. .
Так что С++ намного предпочтительнее.
про python тоже так говорили в начале 2000-х. Что мол зачем учить python если все вакансии для php и ruby on rails.
@@zxcq так по твоему надо ждать 20 лет?
Это и есть главное преимущество С++, что он хоть более менее всем знаком и как то живёт с припарками, хорошая поддержка, компиляторы и библиотеки. Насчёт "хороший язык программирования", кхм. Назвать это нагромождение стихийно образовавшихся фич хорошим в смысле красивым, язык не поворачивается. Фанатам крестов привет !
Спустя 3 года с выхода доклада Раст - цветет и пахнет. Популярность растет. Как пример - пустили в ядро линукс (а почему не пустили плюсы?). Хорошо, что не прогадал в свое время с выбором основного яп ) Выбравшим плюсы - сочувствую ...
@@ГерманМальцев-ш5ж С++ тоже процветает, но что будет потом узнаем.
Думаю это выдача желаемого за действительное, включая банкомат, на кой там С++ ???? С++ якобы везде, но доказательств этому нет. Например в Machine Learning рулят Python, Julia, R, может Яндекс что то скрытно пишет на С++ ? :-) Если бы всё писали на С++, то было бы море вакансий. Но фактически бизнес компании пишут на C#, Java, Python. Под контроллеры по крайней мере ещё недавно большей частью галимый Си, его то не надо с С++ смешивать, это совершенно другой язык, это к вопросу о дефибрилляторах :-) Ядра каких ОС написаны на С++ ? Их можно пересчитать по пальцам. С++ в Mission Critical приложениях ? Это жестоко. Тот же Erlang не свалить, а С++...хе хе. Кроме того С++ не годится там где надо на DSL часто менять некие описания, сценарии и т.п., хотя может кто то так и делает (злобные такие буратины). То что Яндекс его применяет, это такая фишка самого Яндекса. Крупномасштабное проектирование на С++ довольно сложная штука, язык требует слишком много внимания к низкоуровневым деталям, не давая сосредоточиться на крупных аспектах. Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок. Получается полезная штука, но переоценивать не стоит.
"В ML рулят Python, Julia, R,...откуда тут возьмется C++?" - tensorflow/pytorch/etc почти полностью написаны на C++, если исключить обертки, - вот numpy на C, но ему сколько лет уже, как говорится?) - Но тут больше ода соглашениям о вызовах будет, как мне кажется
"Фактически бизнес компании пишут на C#/Java/Python/Javscript/etc" - так и есть: продуктовые фичи в основном "доставляют" на том, на чем не нужно (по началу) заморачиваться о памяти и хотел было написать скорости, но тут уже давно не так, и вопрос состоит в том "на сколько быстро мы хотим чтобы что-то работало"
*что забавно: в том же питоне уже дошли до того уровня, что нормальный программист должен знать как структуру уложить в стэк без оверхэда (привет __slot__), а джависты compile-time фреймворки осваивают с кодогенерацией (привет Dagger), и много-много чего ещё в других языках, что приводит к мысли: "слушайте, а почему мы к этому пришли и почему стало так неудобно? - Вот в {await GetNextMyFavoriteLanguage()} это сделано лучше")
В общем, имхо, но фраза "Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок" скорее относится ко всем языкам программирования, как только программист уходит за рамки написания базовых вещей, и в настоящее время уже начинает казаться, что решение выбрать тот или иной язык для написания конкретных вещей зависит от A. Платформы, B. Изначальных потребностей компании, C. Стоимость программистов с нужными знаниями (или их обучением) на рынке, естественно D. Знаний/пожеланий участников команды разработки (порядок пунктов расположить в зависимости от пожеланий)
Вы пишите: *Если бы всё писали на С++, то было бы море вакансий* Вакансий действительно море.
Уже давно заменимый
Полтора часа опровданий того, почему автор до сих пор пишет на плюсах
Навязчивый маркетинг и враньё :-)
Ничем
Антон опрокинул Rust ))))
Попытался, скажем так.
Тем временем амазон AWS переходит на раст.
А вам не смешно с таких примеров, как были в докладе? Одним запросом гуглятся десятки примеров, где раст спасет, а C++ заставит неделями валгриндить