Недавно делал ядро на C++, писал свой рантайм поверх UEFI. Собственно, требуется предоставить операции new/delete и ещё stack unwinding (процессорозависимый) для обработки исключений. Никто не заставляет тащить весь stdlib. В совокупности минимальный рантайм можно в 30 KiB исходника запихать. Шаблоны работают и без рантайма, там компилятором всё делается.
вспомни демосцены 4к, на с++. можно, но это одноразовая поделка, никак изменить код нельзя, чтобы не выйти за границы 4к, например, все предельно упаковано, не читабельно, и выглядит как сплошной mind hack C++. ни о какой поддержке такого кода С++ речи быть не может. если разработчик умер - всё, пиши всё с нуля, сам.
@@default-writer Ну, то, что я описал, не имеет отношения к качеству кода. Я исторически джавист-перфекционист, так что мой код (как для джависта) самодокументирован. Хотя на поддержку своего детища не претендую, это образовательный проект был.
Реальные причины, их 2, и то, наверное можно сказать, что и 1: это ABI, потому что в си нет манглирования, как в С++, а на манглировании устроен механизм перегрузки. Все остальное - скорее отговорки, так как современные компиляторы, в том числе и GCC, состоят из 2 или даже 3 частей, из которых точно есть front-end, и back-end. И, по идее, если у компилятора есть back-end для какой-то архитектуры, то не важно на каком front-end-е написана программа. Но. всё же думаю не для всех архитектур может в принципе быть реализован такой back-end, но это скорее исключение в наши дни.
Rust появился уже после того, как браузер mozilla был уже огромным работающим продуктом написанном в основном на плюсах. То, что Rust уже почти в нем догнал плюсы говорит о целесообразности его внедрения.
Пример на Си без ОС точно также реализуем и на плюсах, потому что уже есть ядро. А надо код на чистом Си, без системных вызовов) Это надо будет самому сделать драйвера для монитора,консоли и т.д.
4:14 говорят, браузеры давно обогнали операционные системы по сложности и по количеству строк кода. а как Вам новый язык Zig? его систему сборки уже используют в stlib и xserver.
На xserver ориентироваться не стоит. Похоже, на stdlib тоже, но тут я не до конца понял, что сказал. Надо думать. Смотрите тут самый первый комментарий (должен быть про stdlib)
Как большой любитель C и системного программирования хочется сказать... насколько же автор тут притягивает каждый пункт за уши, то ли специально, пытаясь сыграть на том, что кто-то может не знать, то ли из-за полной неграмотности в разбираемом вопросе
9:57 - Я бы не сказал, что у разработчиков ядра производительность - основная причина в выборе С. Скорее причина в том, что С очень понятно транслируется в ассемблер - а это очень важно при низкоуровневой разработке. У того же С++ или Rust компилятор так жонглирует абстракциями, что то как они лягут на уровень машинного кода предсказать очень сложно. А Rust ещё jmp на ошибки в runtime в конце кода накидывает с ломаты, на каждый чих. 13:30 - помнится в прошлом году был огромный срач в сообществе Rust потому, что разработчик модуля сериализации (serde) стал распространять его в бинарном виде, т.к. его компиляция стала занимать чуть ли не весь день! Всего то 1 модуль; библиотека! Да и С++ с boost::spirit тоже компилируется не быстро.
Я пропустил эту новость. Но странно звучит что serde компилируется весь день... Это ведь интерфейс, а не реализация.... Наверное речь о serde_derive макросе Да и вообще, у меня игры на bevy собираются с нуля всего 10 минут. И это всё статическая сборка. Помниться статическая сборка Qt приложение занимала часы..
@@АлексейПрищепа-ы9щ Ну вот та конкретная драма и была из за того, что serde_derive перенесли в бинарный вид. Последнее, что я читал об этом была статья "Handling of the recent drama involving T-libs member David Tolnay" от alonely0. Это если вам будет интересно во всём этом копаться. Ну а про скорость компиляции... ну у меня примеры наоборот, rust оказался хуже при сборке gui приложения. Хотя я это даже в качестве аргумента не использую, ибо сильно зависит от того, что ты разрабатываешь и на какой системе собираешь. Это просто пальцем в небо )
@@ГригорийГанчарук чем же си ближе к железу чем с++? можно хоть один факт? прям раз -- вырезка из стандартов, и все бы тут же было признано -- и никаких приреканий... -- а так ентот бред про близость к железу и какие то "абстракции" с++ можно вечно нести... в чем абстракции с++ относительно си?
можно вырезку из стандарта си, в которой говорится про понятность (предсказуемость) транслируемости в асм? ну хоть строчечку? или под си снова понимается конкретный компилятор? если так -- то вообще нет смысла такие посты делать, поскольку компилятор енто всего лишь реализация, -- и на следующий день в нем может поменяться многое, и енто будет все тот же комиплятор си или с++ -- по ентому только важно указывать отсылки на стандарт языка -- а трансляция в асм туда не входит...
К сожалению в этом видосе оказалось очень поверхностное понимание работы и архитектуры современных компиляторов, языков программирования и менеджмента разработки сложных систем. А из таких поверхностных исходных получились странные выводы, которые, так уж получается, не очень отражают действительность. За труды спасибо, но пока слушал видео пару тройку батхёртов словить пришлось.
Ну, ABI это не совсем про код, это всё же про бинарную совместимость, то есть к примеру порядок параметров в стеке и кто этот стек потом вычишает, вызывающая функция или вызываемая. Очевидно, говоря про С, вы говорите про gcc, ведь ABI MSVC не просто отличается от gcc, но и с завидной регулярностью ломает обратную совместимость.
Ну не совсем, MSVC ABI не менялся с 2015 года, впрочем как и GCC - 2015 год. Изменения ABI не от хорошей жизни делают, обычно это и улучшение производительности и подстраивание под новые реальности.
25:48 -- раскрываю невиданную скрытую тайну.... компиляторы мало сча делаются неслоёными -- и фронтенд языка там может меняться на какой угодно, и будут доступны все реализованные в бекенде архитектуры для ентих фронтендов... -- тот же gcc или clang... все перечисленные архитектуры на видео уже давным давно доступны для с++ (на сколько я осведомлён)
про ансейф везде и вся рассмешил. неужто весь код ядра это доступ к железкам? что-то я сомневаюсь, что там отсутствуют какая-либо логика. такое ощущение будто ничего сложнее hello world вы не писали
если ты соединяешь лбой высокоуроовневый язык с сишной либой,у тя всплывет небезопасная работа с память. что на расте,что на жабе, что на шарпах. в этом плане он ничем не отличается от языков со сборщиком мусора. что оч забавно
@@Александр-ф9в4ю > unsafe в раст более ограничен Тут как посмотреть. unsafe на расте писать сложнее, чем просто код на си. Но зато код на сейф расте писать проще (с точки зрения обеспечения сейфти) чем на си. unsafe в расте не отключает правила алиасинга, тебе всё равно нужно следить за мутабельностью и неизменяемостью. В си всё что угодно можно менять через указатель (на самом деле даже если указатель const это валидно), разве что указатель на статические константы и на какую-то полностью рид онли память нельзя. Но сверх этого, в расте ещё и нужно писать unsafe код так, чтобы его потом можно было использовать через safe API - а этого добиться уже очень сложно, даже прогон кучи тестов через miri тебе не гарантирует что твой API нельзя как-то неправильно использовать и поломать его сейфти гарантии. В Си думать о подобных вещах не нужно, там по сути все функции неявно unsafe, просто если ты что-то сломал то сам виноват. Но всё же, несмотря на сложность растового unsafe-а считаю что такой подход всё же имеет куда больше преимуществ, так как делает язык универсальнее, позволяя писать на нём не только системный софт и ембед, но и более хайлевельный софт уровня Go. Тут уже выбор между писать всё на одном языке (пусть safe и unsafe раст различаются, всё же это один и тот же язык) или писать на Си в паре с каким-то хайлевельным сейфным языком где всё, от синтаксиса до библиотек будет разным. И тут уже выбор довольно индивидуален как кому больше нравится. Лично я не люблю учить по 20 языков чтобы делать, в общем-то, не такие уж и принципиально разные вещи
@@Александр-ф9в4ю не смузихлебам поминать священную ошибку) раст это именно ограниченный язык.спецификация си все говорит сама. а нащет сегфолтов, они на стадии написания проги тестятся. как и утечки. смешные такие,пишут на копрокале и еще чет вякают
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." А вы продолжайте сравнивать молоток и отвёртку.
@@MrChelovek68 ага -- а еще в ядре линукс юзался (и возможно до сих пор) УБ как вариант оптимизации -- "работало же в предыдущих версиях gcc" -- сказал Торвальдс -- "я понимаю, что по стандарту енто УБ" продолжил он... На что ему верно пояснили гуру написания компилятора, что на то оно и УБ, что на него нельзя полагаться в поведении...
На самом деле, если на С++ писать как на Си, то и результат компиляции будет практически одинаковый. Конечно, у этих языков есть с десяток несовместимостей, но это несущественные и решаемые мелочи. Оба языка позволят написсть код для микроконтроллера без библиотек и практически ассемблерных вставок. В общем случае С++ удобнее из за бесплатных плюшек, контроля типов, и чуть более лаконичного кода. (Пока о объектах речи нет) А что не так? Почему не перешли? А переходят, и обычно довольны. Дело в чуть худшей переносимости, и чуть более мутной стандартизации. Именно чуть чуть. Но сколько споров из за этого.
Жалко, что автор вместо того чтобы поговорить о реальных проблемах rust, привел кучу устаревших или невалидных аргументов, а я уже было надеялся что у кого-то есть взвешанная точка зрения. С кроссплатформенностью у rust всё отлично, просто писать надо на rust, а не на ассемблеровских вставках - для этого есть hal. Проблемы есть с эргономикой, особенно если говорить про экосистему, но фанаты rust это не признают, а хейтеры - обижены на borrow checker и дальше него обычно не продвигаются.
автор просто не понимает что такое LLVM, и собс за счет него раст с кроссплатформенностью справляется нормльно, и дальше будет лучше, потому что LLVM оч активно развивается. Про борроу чекер - мне кажется это школьники какие то о него вспотыкаются, по факту ничего там такого нет - по сути принуждение к чистоте и порядку, хороший код (который если без всякой уличной магги для каких то особенных случаев) в принципе также может выглядеть в других языках. Лайфтаймы на мой взгляд гораздо более пугающий новичков механизм - особенно когда не хоумпетпроджект, а более менее большой проект
Шаблоны порождают IFNDR это еще хуже UB. Ну и вообще стандарт дырявый так как вариантов комбинаторно много. Пример кода, который компилируется см "delete delete" это IFNDR. template void del(T a){ delete delete a; } int main(){return 1;}
привет! спасибо за ролик, хорошо подсветил интуитивно просящиеся вещи ) интересно твое мнение (в том числе по тематике видео) про zig. сам пока, к сожалению, его не пощупал, но на мой взгляд выглядит интересным
Добавь в сравнение ассемблер и подавляющее большинство пунктов будет не в сторону Си, а в сравнении с другими языками будет очевидно что Си не всегда самый лучший выбор, по сути причины только две это большая экосистема в Си в соотношении с другими, и потому что так захотелось...
17:45 -- а без исключений ты ичего не обрабатываешь? при ентом ты вынужден каждый раз проверять в нескольких местах условия обрабатывая возвратный код из функции... а исключения работают именно когда они выкидываются -- не надо каждый раз "прокидывать" коды ошибок -- тоесть как раз наоборот -- исключения экономят рантайм
27:57 -- а где в стандарте си указано что компилятор обязан делать все построчно неотходя от приданного программистом порядка действий -- в случае когда компилятор может сделать аналогичную по логике программу? в ентом и проблема подобных видосов -- авторы почти никогда вообще не исследуют именно объективную сторону вопроса -- и конкретные значимые сведения
10:54 А C# компилируется ещё быстрее. И что (я знаю, что C# не системный язык и вообще всё о нём знаю, речь не об этом)? Мне кажется, что это всё притянуто за уши. Я бы точно не стал выбирать системный язык только по скорости компиляции. Скорость компиляции у C будет всегда выше любого нового языка, который имеет много возможностей для написания безопасного, но при этом всё ещё быстрого кода.
Все видео пацан доказывал на примерах высосанных из пальцах, что Си благороднее Раста, а Плюсы для сравнения добавил чисто, что бы казалось объективным сравнением. Безусловно, некоторые пункты имеют долю истины, но сверху начинают такое накидывать на вентилятор, что видно, что человек не понимает даже как Си ведет себя в тех пунктах, которые он доказывает. А говорить о его компетентности в знании нюансов Раста и Плюсов даже не приходиться.
Код на Rust очень сложно разрабатывать, тяжелая плата за стабильность, люди выгорают. Утилиты которые уже написаны на Rust как правило работают лучше (лучше потребление памяти и быстрее). Возможно это связано с компиляцией / оптимизацией под современные процессоры. Считаю что Rust в любом случае догонит C, через 25-30 лет все критически важные части Linux (возможно всё) будут реализованы на Rust
29:02 -- а вот тут как раз таки можешь -- атомарные операции поддержаны в с++... можно как раз задать именно зависимость порядка выполнения одной части программы от другой.
11:25 -- каких нафиг абстракций? можно хоть один пример? с++ вмещает в себя си -- тут вообще нечего сравнивать -- для с++ просто доступны многие оптимизации (а некоторые из них являются обязательными по стандарту) которых в си нельзя сделать. Не может код на с++ быть менее быстрым чем на си... енто антинаучно и абсурдно -- там в примере скорость компиляции, а не работы... рантайм си не может быть быстрее рантайма с++...
Я смотрел код этих "бэнчмарков", там такое написано, что лучше бы я этого не видел, автор намеренно исопльзовал динамическую память, там где нужна стековая, да и сам бэнчмарк если его правильно написать выполнился бы в компайл тайме, в общем это вообще не тесты производительности, не обращайте на них внимания...
Скорее корректнее сравнивать Zig с С и Rust с C++? Все-таки это две разные ниши. С++ и Rust все-таки на уровень выше и там уже абстракции пригодятся. Но тема интересная, спасибо !
Вопреки утверждению автора о том, что на C++ нельзя работать на голом железе (или очень затруднительно), имею опыт запуска программ C++ на голом STM32. Запуск одинаково возможен, что на C, что на C++, однако по размеру кода, занимаемой оперативной памяти и быстродействию ситуация будет не в пользу C++. Хотя в моём случае разница не превышала 5% по быстродействию и 12% по памяти.
15:11 -- как раз будет многое уже доступно в с++ -- freestanding либа -- советую почитать что такое и зачем она -- лучше сразу стандарт или на цппреференсе -- и что туда сча входит в обязательном порядке.
и енто как раз на си пишут код, эмулируя конструкции из с++ -- даже в ядре линукс таких конструкций ну прям очень много... при ентом они делаются сильно неэффективно, поскольку си не позволяет их реализовать эффективно -- а с++ позволяет -- и компилятор в ентих моментах может делать кучи оптимизаций дополнительных
26:45 не соглашусь, LLVM хоть даже с питона или js, хоть даже микс из сотен языков)) вам скомпилирует ядро которое будет совместимо с **любой** архитектурой для которой вы напишите ассемблер LLVM (который даже проще СИ)
28:29 -- простыми словами -- все что компилятор с++ делает (может делать) забортом контроля кодера -- на си пишут ручками -- при чем в точности повторяя суть ентих оптимизаций -- иначе код на си был бы вообще настолько неоптимальным по производительности, что про си бы уже давно забыли заслуженно как страшный сон.
Ну блин, почему не выделить часть кода, близкую к железу в "драйвер" и написать на С, а остальное в Rust сделать. Основная проблема - трудозатраты - работает сейчас и пусть работает.
Так и делают, просто сейчас вот эту прослойку ядра, которую нужно писать на ассемблере целевого железа, уже и используется в других языках, которые тоже позволяют делать ассемблерные вставки. Т.е. не использовать, например, два высокоуровневых языка, как Вы написали (C и Rust), а выбрать какой-то один и спокойно это сделать, чтобы было меньше сущностей, что полезно сказывается на качестве и отладке.
И что значит как долго код будет поддерживаться? Причем тут поддержка если у ABI только одна стабильная версия? Разве если взять за основу одну и туже версию с++ или Раст и не мигрировать их на новые версии - это вам не даст аналог "стабильного не меняющегося ABI"?
Не знаю зачем стабильный ABI в монолитном ядре, где все модули статические. Но даже внешние модули должны быть собраны под конкретную версию ядра. Так что не понятно что имел ввиду автор. Но по поводу ABI, в расте до сих пор все библиотеки распространяются кодом, а не бмнарниками. В этом есть плюсы (маленький размер бинаря в итоге, и опции настроек), но а в минусе скорость сборки... И размер target большой
Ядро линукс используется преимущественно на смартфонах и wi-fi роутерах, некотором сетевом оборудовании. Серверов миллионы, но девайсов и смартфонов МИЛЛИАРДЫ. В них особенно могут быть критичны размеры ядра и производительность. Си и только си. Какой еще Раст? С++ да, то Раст это усего лишь еще один убийца С++, не более.
28:40 -- не обязательно -- нет такой гарантии в стандарте си. -- могу лишь рекомендовать к прочтению стандарты языков -- иначе будут подобные "чьи то мнения" и не более -- объективными доводами енто вообще никак нельзя назвать я считаю
а еще если углубиться в то, что именно аппаратура может поменять местами ход выполнения программы -- тут вообще понимаешь, что только особые команды аппаратуре дадут тебе именно тот ход выполнения, который ты хочешь видеть -- но енто увы будет сильно менее оптимальным по производительности.
Когда наступят 70-е и мы вернемся в каменный век, где будут 16 битовые процессоры одноядерные какой там Rust или С++, то вспомтят Pascal, там тоже можно на asm вставки писать. А может все перейдут на Fortran. Или будут писать на Basic, любителей было много. В те времена много инструкций в процессоре небыло, mmx, sse появилось только 1997, а сам процессор 32 бита 40 мгц только 1985г, до этого руками оптимизировали. Но никто не задумывается что ChatGPT 5.0 или 10.0 будет писать весь софт под ваше NULL железо, написав ему лишь пару слов. Сам напишет, оптимизирует, скампилирует, протестирует и еще установщик напишет или загрузчик на любом языке. Технологий не стоят на месте, только древние люди которым нравиться писать ручками с нуля, но не на старых машинах, а на многоядерных и многие это любят делают на asmblere куда там rust\с\с++.
25:32 продолжение цитаты "Если написал код на C, то будет работать везде ... херово". Если мы хотим перфоманса, а на C мы хотим перфоманса, то под каждую платформу нужно будет переписывать код. И если ещё у нас под разными платформами разные компиляторы, то здравствуйте новые UB. Также под платформу собирает не фронтенд компилятора, который для разных языков разный, а бэкэнд, которому пофигу на каком языке написана программа.
11:34 -- для написания ОС нету рантайм библиотеки -- там будешь юзать freestanding версию либы -- или самому все сделать, но енто гемор просто дополнительный и ненужный. уже одалели если честно енту тему вообще поднимать -- линукс на си только по одной единственной причине -- потому что Линус Торвальдс хейтер с++ и адепт си -- больше нет никаких причин -- и тем более нет вообще никаких объективных
Мое мнение такое, Си - это хороший язык, но устарел морально, и ему либо нужно совершенствоваться, либо искать другие инструменты. Тем самым появился раст и плюсы, но их опыта мало еще в наше время, чтобы создать что-то вроде линукса. Во всем есть плюсы и минусы По поводу производительности, то у rust на уровне компилятора всегда есть лишняя проверка какая-нибудь, чтобы не совершать ошибка переполнения и так далее.
Не в восторге от Rust, но аргумент против него в том что ядро firefox с большего на cpp не верный, просто они еще не все переписали. Что касается Си vs С++/Rust. Первый аргумент это - Си не имеет паник и исключений, а значи некий код ядра потенциально имеет меньше шансов сломать рантайм выбросив исключение или панику. Второй аргумент компилятор Си намного проще чем Cpp/Rust и уже портирован на многие архитектуры. Про производительность, у Cpp намного лучше компиляторы по оптимизации, их годами задрачивали но вот рантайм либа у cpp намного жирнее и в том же embedded с десятками и сотнями килобайт памяти может занимать слишком много памяти или вообщеине вылазить за доступные объемы. В тех же машинах исспользую очень много чипов, обычно там памяти может быть десятки килобайт и ни какие либы для поддержки исключений, дженериков, многпоточности и др. туда просто не помещаются. Для более мощых по памяти девайсов cpp это очевидный выбор т.к. в "любимый" Си до сих по не добавили даже модульность аля неймспейсов и удобную обработку ошибок, что на практике геморой и много мусорных строчек в прикладном коде.
На самом деле, ваш коментарий, гораздо лучше, чем всё видео. Единственное с чем я бы поспорил, это с исключениями, они очень легко отключаются в С++, а на уровне ядра они явно будут лишними (по крайней мере на самом низком уровне). В общем исключения - не проблема, т.к. их можно отключить там, где они не нужны. А вот с тем, что компилятор Си проще (а следственно безопаснее) чем С++/Rust - это 100%.
Да и про портированность на большое количество платформ уже не так. Сейчас любой производитель нового железа пишет лишь бэк под инфраструктуру llvm, а не выпиысвает полный компилятор под конкретный высокоуровневый язык. Теоретически лишь могли остаться очень специфичные старые архитектуры, под которые еще бэк не писали, но при этом там еще существует какой-то экзотический компилятор C
Кто будет переписывать бесплатно миллионы строк кода на другом языке? Все разработчики ядра будут обязаны изучить еще один язык, чтобы что? Плюсов от переписывания больших нет. А сложности на пустом месте - есть. Вот поэтому все и пишется на все том же C.
Rust это вообще бред, а на плюсах можно писать также эффективно как на С если не использовать множественное наследование. Мне так плюсы удобнее чем С. Но Торвалд Линус предпочитает С поэтому ядро на С....
Си привнес удобство в общение с машиной , стало гораздо проще организовывать ресурсы и выстраивать логику для выполнения задач, Си ближе к скорости , чем с++ и более высокоуровневые языки, си это супер середина супер баланс между человекопонятным синтаксисом и эффективностью работы. Все что выше си например, с++, раст, итд, это однозначно ещё большая простота в использовани, синтаксис становится ещё проще, но и цепочка посредников обеспечивающая эту простоту возрастает и в следствии этого падает производительность. кроме того реализация не всегда самая эффективная в этом упрощении синтаксиса. такие мысли. в любом случае си будет оставаться базовой базой до тех пор пока индустрия придерживается булевской логики.
У C++ больше простота использования чем у C? У C++ синтаксис сложнее, больше ключевых слов + ООП. У него больше возможностей, но и сложней в использовании
@@NNAKG у плюсов есть "встроенные" вектора и строки, что уже само по себе делает его синтаксически слаще чем стандартные си. Да, на плюсах чрезмерно много библиотек, что делает его сложнее в использовании, понимании и обучении. Однако писать что-то высокоуровневое со словарями, хэш таблицами, алгоритмами и т.д. на плюсах гораздо проще и удобнее. ИМХО: плюсы удобнее чем си в использовании в 60% случаев, когда нужен низкоуровневый язык, и в 95% случаев, когда нужно собрать что-нибудь прикладное. Из этого следует, что плюсы - язык более простой в использовании* (следует отличать, что не простой в плане синтаксиса (хотя и это сомнительно ввиду отсутствия ООП на сях)) чем си
К сожалению автор несёт чушь. Проверяйте всё что он говорит, (не)приятно удивитесь. В частности, компиляторы С умеют оптимизировать код. Ну и хинт. Если вы нагородили что-то на С++ такое, что оно стало тормознее С, просто используйте С реализацию. Добиться того, чтоб С++ был тормознее С технически невозможно, потому что всегда можно взять программу на С и сказать что это С++. (мелкие хаки на темных местах стандарта, когда С код не является валидной программой на С++ не в счёт)
std20 не на многих платформах поддерживается, если говорить о С, то там до сих пор С99 (или вообще С89) в большинстве случаев. Имхо, С и С++ нужны современные гигиеничные макросы, ну и модульную систему, конечно, доделать. Эти header guards - это отвратительно. Еще хотелось бы статическую рефлексию на уровне языка (привет С++26 experimental)
Стабильность ABI = стабильность багов, стабильность костылей, стабильность непроизводительных решений. Это скорее вынужденная поддержка Легаси костылей а не стабильность
Недавно делал ядро на C++, писал свой рантайм поверх UEFI. Собственно, требуется предоставить операции new/delete и ещё stack unwinding (процессорозависимый) для обработки исключений. Никто не заставляет тащить весь stdlib. В совокупности минимальный рантайм можно в 30 KiB исходника запихать. Шаблоны работают и без рантайма, там компилятором всё делается.
вспомни демосцены 4к, на с++. можно, но это одноразовая поделка, никак изменить код нельзя, чтобы не выйти за границы 4к, например, все предельно упаковано, не читабельно, и выглядит как сплошной mind hack C++. ни о какой поддержке такого кода С++ речи быть не может. если разработчик умер - всё, пиши всё с нуля, сам.
@@default-writer Ну, то, что я описал, не имеет отношения к качеству кода. Я исторически джавист-перфекционист, так что мой код (как для джависта) самодокументирован. Хотя на поддержку своего детища не претендую, это образовательный проект был.
а можно ссылку на код? интересно глянуть кое-что. спасибо
Реальные причины, их 2, и то, наверное можно сказать, что и 1: это ABI, потому что в си нет манглирования, как в С++, а на манглировании устроен механизм перегрузки. Все остальное - скорее отговорки, так как современные компиляторы, в том числе и GCC, состоят из 2 или даже 3 частей, из которых точно есть front-end, и back-end. И, по идее, если у компилятора есть back-end для какой-то архитектуры, то не важно на каком front-end-е написана программа. Но. всё же думаю не для всех архитектур может в принципе быть реализован такой back-end, но это скорее исключение в наши дни.
при чем тут манглирование? чо за дичь про аби что от автора видео, что в посте? - в чем нестабильный аби в с++ ? хоть однажды пример можно?
Почитав комментарии узнал много нового и понял что очень мало знаю )
Спасибо за видео и за умные комментарии.
пространные рассуждения.
С железом плюсы прекрасно дружат. Отключение rtti и исключений не делает из плюсов С.
Rust появился уже после того, как браузер mozilla был уже огромным работающим продуктом написанном в основном на плюсах. То, что Rust уже почти в нем догнал плюсы говорит о целесообразности его внедрения.
Пример на Си без ОС точно также реализуем и на плюсах, потому что уже есть ядро. А надо код на чистом Си, без системных вызовов) Это надо будет самому сделать драйвера для монитора,консоли и т.д.
4:14 говорят, браузеры давно обогнали операционные системы по сложности и по количеству строк кода.
а как Вам новый язык Zig? его систему сборки уже используют в stlib и xserver.
На xserver ориентироваться не стоит. Похоже, на stdlib тоже, но тут я не до конца понял, что сказал. Надо думать. Смотрите тут самый первый комментарий (должен быть про stdlib)
Браузеры , браузерами - у мелкомягкого офиса 65М. Шах и мат))
Пока папа может в Си- все в порядке в Линукси! 😅
Как большой любитель C и системного программирования хочется сказать... насколько же автор тут притягивает каждый пункт за уши, то ли специально, пытаясь сыграть на том, что кто-то может не знать, то ли из-за полной неграмотности в разбираемом вопросе
второе, скорее всего
9:57 - Я бы не сказал, что у разработчиков ядра производительность - основная причина в выборе С. Скорее причина в том, что С очень понятно транслируется в ассемблер - а это очень важно при низкоуровневой разработке. У того же С++ или Rust компилятор так жонглирует абстракциями, что то как они лягут на уровень машинного кода предсказать очень сложно. А Rust ещё jmp на ошибки в runtime в конце кода накидывает с ломаты, на каждый чих.
13:30 - помнится в прошлом году был огромный срач в сообществе Rust потому, что разработчик модуля сериализации (serde) стал распространять его в бинарном виде, т.к. его компиляция стала занимать чуть ли не весь день! Всего то 1 модуль; библиотека! Да и С++ с boost::spirit тоже компилируется не быстро.
си ближе к железу да, думать на си в работе с железом гораздо удобнее, чем как вы верно сказали на абстрактном с++.
Я пропустил эту новость. Но странно звучит что serde компилируется весь день... Это ведь интерфейс, а не реализация.... Наверное речь о serde_derive макросе
Да и вообще, у меня игры на bevy собираются с нуля всего 10 минут. И это всё статическая сборка.
Помниться статическая сборка Qt приложение занимала часы..
@@АлексейПрищепа-ы9щ Ну вот та конкретная драма и была из за того, что serde_derive перенесли в бинарный вид. Последнее, что я читал об этом была статья "Handling of the recent drama involving T-libs member David Tolnay" от alonely0. Это если вам будет интересно во всём этом копаться.
Ну а про скорость компиляции... ну у меня примеры наоборот, rust оказался хуже при сборке gui приложения. Хотя я это даже в качестве аргумента не использую, ибо сильно зависит от того, что ты разрабатываешь и на какой системе собираешь. Это просто пальцем в небо )
@@ГригорийГанчарук чем же си ближе к железу чем с++? можно хоть один факт? прям раз -- вырезка из стандартов, и все бы тут же было признано -- и никаких приреканий... -- а так ентот бред про близость к железу и какие то "абстракции" с++ можно вечно нести... в чем абстракции с++ относительно си?
можно вырезку из стандарта си, в которой говорится про понятность (предсказуемость) транслируемости в асм? ну хоть строчечку?
или под си снова понимается конкретный компилятор? если так -- то вообще нет смысла такие посты делать, поскольку компилятор енто всего лишь реализация, -- и на следующий день в нем может поменяться многое, и енто будет все тот же комиплятор си или с++ -- по ентому только важно указывать отсылки на стандарт языка -- а трансляция в асм туда не входит...
c++ вполне классно живёт на голом железе, без директив всяких и ужимок, только линкеру спеку указать и стл пашет нормально даже
К сожалению в этом видосе оказалось очень поверхностное понимание работы и архитектуры современных компиляторов, языков программирования и менеджмента разработки сложных систем. А из таких поверхностных исходных получились странные выводы, которые, так уж получается, не очень отражают действительность. За труды спасибо, но пока слушал видео пару тройку батхёртов словить пришлось.
программисты под ентот видос явно знатно фейспалмили)))
думаю сам Линус бы тож фейспалмил)))
показать бы создателям LLVM эти рассуждения))
вот сама в шоке сидела от всего рассказываемого с рукой у лица, причем сама люблю, уважаю и пишу на C
Ну, ABI это не совсем про код, это всё же про бинарную совместимость, то есть к примеру порядок параметров в стеке и кто этот стек потом вычишает, вызывающая функция или вызываемая. Очевидно, говоря про С, вы говорите про gcc, ведь ABI MSVC не просто отличается от gcc, но и с завидной регулярностью ломает обратную совместимость.
Ну не совсем, MSVC ABI не менялся с 2015 года, впрочем как и GCC - 2015 год. Изменения ABI не от хорошей жизни делают, обычно это и улучшение производительности и подстраивание под новые реальности.
@@serhiymalokhatko но к языку программирования енто какое отношение имеет?
25:48 -- раскрываю невиданную скрытую тайну.... компиляторы мало сча делаются неслоёными -- и фронтенд языка там может меняться на какой угодно, и будут доступны все реализованные в бекенде архитектуры для ентих фронтендов... -- тот же gcc или clang... все перечисленные архитектуры на видео уже давным давно доступны для с++ (на сколько я осведомлён)
про ансейф везде и вся рассмешил. неужто весь код ядра это доступ к железкам? что-то я сомневаюсь, что там отсутствуют какая-либо логика. такое ощущение будто ничего сложнее hello world вы не писали
если ты соединяешь лбой высокоуроовневый язык с сишной либой,у тя всплывет небезопасная работа с память. что на расте,что на жабе, что на шарпах. в этом плане он ничем не отличается от языков со сборщиком мусора. что оч забавно
Смысл от safe если существует блок unsafe - значит все будем писать в unsafe. Действительно, ведь в си не надо писать блоки unsafe. Как удобно. Вау
unsafe rust в разы более ограничен чем С. Но адептам легаси кала некогда - нужно искать сегфолт
@@Александр-ф9в4ю > unsafe в раст более ограничен
Тут как посмотреть. unsafe на расте писать сложнее, чем просто код на си. Но зато код на сейф расте писать проще (с точки зрения обеспечения сейфти) чем на си. unsafe в расте не отключает правила алиасинга, тебе всё равно нужно следить за мутабельностью и неизменяемостью. В си всё что угодно можно менять через указатель (на самом деле даже если указатель const это валидно), разве что указатель на статические константы и на какую-то полностью рид онли память нельзя. Но сверх этого, в расте ещё и нужно писать unsafe код так, чтобы его потом можно было использовать через safe API - а этого добиться уже очень сложно, даже прогон кучи тестов через miri тебе не гарантирует что твой API нельзя как-то неправильно использовать и поломать его сейфти гарантии. В Си думать о подобных вещах не нужно, там по сути все функции неявно unsafe, просто если ты что-то сломал то сам виноват.
Но всё же, несмотря на сложность растового unsafe-а считаю что такой подход всё же имеет куда больше преимуществ, так как делает язык универсальнее, позволяя писать на нём не только системный софт и ембед, но и более хайлевельный софт уровня Go.
Тут уже выбор между писать всё на одном языке (пусть safe и unsafe раст различаются, всё же это один и тот же язык) или писать на Си в паре с каким-то хайлевельным сейфным языком где всё, от синтаксиса до библиотек будет разным. И тут уже выбор довольно индивидуален как кому больше нравится. Лично я не люблю учить по 20 языков чтобы делать, в общем-то, не такие уж и принципиально разные вещи
@@Александр-ф9в4ю не смузихлебам поминать священную ошибку) раст это именно ограниченный язык.спецификация си все говорит сама. а нащет сегфолтов, они на стадии написания проги тестятся. как и утечки. смешные такие,пишут на копрокале и еще чет вякают
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
А вы продолжайте сравнивать молоток и отвёртку.
@@MrChelovek68 ага -- а еще в ядре линукс юзался (и возможно до сих пор) УБ как вариант оптимизации -- "работало же в предыдущих версиях gcc" -- сказал Торвальдс -- "я понимаю, что по стандарту енто УБ" продолжил он... На что ему верно пояснили гуру написания компилятора, что на то оно и УБ, что на него нельзя полагаться в поведении...
Круто, продолжай также, ждём след видосов про линукс:)
а зачем переписывать ядро linux? пусть и будет на си
На самом деле, если на С++ писать как на Си, то и результат компиляции будет практически одинаковый.
Конечно, у этих языков есть с десяток несовместимостей, но это несущественные и решаемые мелочи.
Оба языка позволят написсть код для микроконтроллера без библиотек и практически ассемблерных вставок.
В общем случае С++ удобнее из за бесплатных плюшек, контроля типов, и чуть более лаконичного кода. (Пока о объектах речи нет)
А что не так? Почему не перешли?
А переходят, и обычно довольны.
Дело в чуть худшей переносимости, и чуть более мутной стандартизации. Именно чуть чуть. Но сколько споров из за этого.
Жалко, что автор вместо того чтобы поговорить о реальных проблемах rust, привел кучу устаревших или невалидных аргументов, а я уже было надеялся что у кого-то есть взвешанная точка зрения. С кроссплатформенностью у rust всё отлично, просто писать надо на rust, а не на ассемблеровских вставках - для этого есть hal. Проблемы есть с эргономикой, особенно если говорить про экосистему, но фанаты rust это не признают, а хейтеры - обижены на borrow checker и дальше него обычно не продвигаются.
автор просто не понимает что такое LLVM, и собс за счет него раст с кроссплатформенностью справляется нормльно, и дальше будет лучше, потому что LLVM оч активно развивается.
Про борроу чекер - мне кажется это школьники какие то о него вспотыкаются, по факту ничего там такого нет - по сути принуждение к чистоте и порядку, хороший код (который если без всякой уличной магги для каких то особенных случаев) в принципе также может выглядеть в других языках. Лайфтаймы на мой взгляд гораздо более пугающий новичков механизм - особенно когда не хоумпетпроджект, а более менее большой проект
Те же ассемблерные вставки в Rust тоже есть, если очень надо...
Шаблоны порождают IFNDR это еще хуже UB.
Ну и вообще стандарт дырявый так как вариантов комбинаторно много.
Пример кода, который компилируется см "delete delete" это IFNDR.
template
void del(T a){
delete delete a;
}
int main(){return 1;}
привет!
спасибо за ролик, хорошо подсветил интуитивно просящиеся вещи )
интересно твое мнение (в том числе по тематике видео) про zig.
сам пока, к сожалению, его не пощупал, но на мой взгляд выглядит интересным
Добавь в сравнение ассемблер и подавляющее большинство пунктов будет не в сторону Си, а в сравнении с другими языками будет очевидно что Си не всегда самый лучший выбор, по сути причины только две это большая экосистема в Си в соотношении с другими, и потому что так захотелось...
17:45 -- а без исключений ты ичего не обрабатываешь? при ентом ты вынужден каждый раз проверять в нескольких местах условия обрабатывая возвратный код из функции... а исключения работают именно когда они выкидываются -- не надо каждый раз "прокидывать" коды ошибок -- тоесть как раз наоборот -- исключения экономят рантайм
27:57 -- а где в стандарте си указано что компилятор обязан делать все построчно неотходя от приданного программистом порядка действий -- в случае когда компилятор может сделать аналогичную по логике программу?
в ентом и проблема подобных видосов -- авторы почти никогда вообще не исследуют именно объективную сторону вопроса -- и конкретные значимые сведения
10:54 А C# компилируется ещё быстрее. И что (я знаю, что C# не системный язык и вообще всё о нём знаю, речь не об этом)? Мне кажется, что это всё притянуто за уши. Я бы точно не стал выбирать системный язык только по скорости компиляции. Скорость компиляции у C будет всегда выше любого нового языка, который имеет много возможностей для написания безопасного, но при этом всё ещё быстрого кода.
Каким боком там Go???
На счёт ОС - не согласен. "Проще делать" - чисто субъективное мнение
Спасибо за видос. Я не супер продвинутый в линукс, но подобная утилита для скриншотов из коробки на zorin os (core edition тут как раз wayland)
Все видео пацан доказывал на примерах высосанных из пальцах, что Си благороднее Раста, а Плюсы для сравнения добавил чисто, что бы казалось объективным сравнением. Безусловно, некоторые пункты имеют долю истины, но сверху начинают такое накидывать на вентилятор, что видно, что человек не понимает даже как Си ведет себя в тех пунктах, которые он доказывает. А говорить о его компетентности в знании нюансов Раста и Плюсов даже не приходиться.
Более проще сделать компилятор для другой архитектуры на си и более проще словить не очевидный баг также. Это скорее костыль нежели чем преимущество
Код на Rust очень сложно разрабатывать, тяжелая плата за стабильность, люди выгорают. Утилиты которые уже написаны на Rust как правило работают лучше (лучше потребление памяти и быстрее). Возможно это связано с компиляцией / оптимизацией под современные процессоры.
Считаю что Rust в любом случае догонит C, через 25-30 лет все критически важные части Linux (возможно всё) будут реализованы на Rust
А в чем преимущества С# над С и С++? Вопрос не по теме
C# - это совсем другой язык для совсем других задач. Преимущества в том, что те "другие задачи" на нём решать легче, чем на С и С++.
12:13 -- вот тут надо смотреть что за код сравнивается -- скорее всего там просто непомерно неравнозначный код сделан...
Накидай вим плагинов, которыми пользуешься по приоритетности
Красавчик . 100%
Если бы мы в 2024 году писали бы ядро операционной системы, то на одни из нас не трепали бы языком на ютуюбе, а другие не развешивали бы уши тут же.
17:18 syscall что делает?
а с хрена нет то??? на микроконтроллеры пишу и на С++ и на расте... там нет ни каких ОС, могут быть, но чаще всего не нужны. чувак, ты грустный
29:02 -- а вот тут как раз таки можешь -- атомарные операции поддержаны в с++... можно как раз задать именно зависимость порядка выполнения одной части программы от другой.
11:25 -- каких нафиг абстракций? можно хоть один пример? с++ вмещает в себя си -- тут вообще нечего сравнивать -- для с++ просто доступны многие оптимизации (а некоторые из них являются обязательными по стандарту) которых в си нельзя сделать. Не может код на с++ быть менее быстрым чем на си... енто антинаучно и абсурдно -- там в примере скорость компиляции, а не работы... рантайм си не может быть быстрее рантайма с++...
Я смотрел код этих "бэнчмарков", там такое написано, что лучше бы я этого не видел, автор намеренно исопльзовал динамическую память, там где нужна стековая, да и сам бэнчмарк если его правильно написать выполнился бы в компайл тайме, в общем это вообще не тесты производительности, не обращайте на них внимания...
Скорее корректнее сравнивать Zig с С и Rust с C++? Все-таки это две разные ниши. С++ и Rust все-таки на уровень выше и там уже абстракции пригодятся. Но тема интересная, спасибо !
В Zig есть свои плюшки в виде метапрограммирования, но разработчик языка при этом стремится сделать его достаточно простым, плюсы просто нечитаемые
а можно хоть один момент из с++ привести, где он чем то выше по абстракции относительно си?
Дайте пожалуйста исходники бенчмарков
Вопреки утверждению автора о том, что на C++ нельзя работать на голом железе (или очень затруднительно), имею опыт запуска программ C++ на голом STM32. Запуск одинаково возможен, что на C, что на C++, однако по размеру кода, занимаемой оперативной памяти и быстродействию ситуация будет не в пользу C++. Хотя в моём случае разница не превышала 5% по быстродействию и 12% по памяти.
15:11 -- как раз будет многое уже доступно в с++ -- freestanding либа -- советую почитать что такое и зачем она -- лучше сразу стандарт или на цппреференсе -- и что туда сча входит в обязательном порядке.
и енто как раз на си пишут код, эмулируя конструкции из с++ -- даже в ядре линукс таких конструкций ну прям очень много... при ентом они делаются сильно неэффективно, поскольку си не позволяет их реализовать эффективно -- а с++ позволяет -- и компилятор в ентих моментах может делать кучи оптимизаций дополнительных
Если адаптировать с++ и rust до написания ядра, то их придется адаптировать до С
32:06 -- а почему не должно? можно хоть один пример?
python 2 и python 3
@@nikisik ??? чо питон?
26:45 не соглашусь, LLVM хоть даже с питона или js, хоть даже микс из сотен языков)) вам скомпилирует ядро которое будет совместимо с **любой** архитектурой для которой вы напишите ассемблер LLVM (который даже проще СИ)
Видеоблогер: "C решает проблему биранкой совместимости!"
Разработчики и пользователи загружаемых модулей ядра линукс: "Да ну???"
Ну несколько я знаю мозилла уже не использует раст для своего браузерного движка. Команду которая писала на расте в итоге распустили..
Команда раста финансируется теперь чрез опенсорс механизм, но закидывают деньги теперь туда в том числе и Мелкомягкие.
28:29 -- простыми словами -- все что компилятор с++ делает (может делать) забортом контроля кодера -- на си пишут ручками -- при чем в точности повторяя суть ентих оптимизаций -- иначе код на си был бы вообще настолько неоптимальным по производительности, что про си бы уже давно забыли заслуженно как страшный сон.
Ну блин, почему не выделить часть кода, близкую к железу в "драйвер" и написать на С, а остальное в Rust сделать. Основная проблема - трудозатраты - работает сейчас и пусть работает.
Вы не поверите, но бОльшая часть ядра ОС - это драйверы, так что смысл писать на расте, если 99% кода будет на Си...
Так и делают, просто сейчас вот эту прослойку ядра, которую нужно писать на ассемблере целевого железа, уже и используется в других языках, которые тоже позволяют делать ассемблерные вставки. Т.е. не использовать, например, два высокоуровневых языка, как Вы написали (C и Rust), а выбрать какой-то один и спокойно это сделать, чтобы было меньше сущностей, что полезно сказывается на качестве и отладке.
И что значит как долго код будет поддерживаться? Причем тут поддержка если у ABI только одна стабильная версия? Разве если взять за основу одну и туже версию с++ или Раст и не мигрировать их на новые версии - это вам не даст аналог "стабильного не меняющегося ABI"?
Не знаю зачем стабильный ABI в монолитном ядре, где все модули статические. Но даже внешние модули должны быть собраны под конкретную версию ядра. Так что не понятно что имел ввиду автор.
Но по поводу ABI, в расте до сих пор все библиотеки распространяются кодом, а не бмнарниками. В этом есть плюсы (маленький размер бинаря в итоге, и опции настроек), но а в минусе скорость сборки... И размер target большой
Нужна переносимость! LLVM? Нет, не слышал...
Ядро линукс используется преимущественно на смартфонах и wi-fi роутерах, некотором сетевом оборудовании. Серверов миллионы, но девайсов и смартфонов МИЛЛИАРДЫ. В них особенно могут быть критичны размеры ядра и производительность. Си и только си. Какой еще Раст? С++ да, то Раст это усего лишь еще один убийца С++, не более.
Раст мёртворожденный?
@vitall789, а ты его ответу свято поверишь?
28:40 -- не обязательно -- нет такой гарантии в стандарте си. -- могу лишь рекомендовать к прочтению стандарты языков -- иначе будут подобные "чьи то мнения" и не более -- объективными доводами енто вообще никак нельзя назвать я считаю
а еще если углубиться в то, что именно аппаратура может поменять местами ход выполнения программы -- тут вообще понимаешь, что только особые команды аппаратуре дадут тебе именно тот ход выполнения, который ты хочешь видеть -- но енто увы будет сильно менее оптимальным по производительности.
Когда наступят 70-е и мы вернемся в каменный век, где будут 16 битовые процессоры одноядерные какой там Rust или С++, то вспомтят Pascal, там тоже можно на asm вставки писать. А может все перейдут на Fortran. Или будут писать на Basic, любителей было много. В те времена много инструкций в процессоре небыло, mmx, sse появилось только 1997, а сам процессор 32 бита 40 мгц только 1985г, до этого руками оптимизировали. Но никто не задумывается что ChatGPT 5.0 или 10.0 будет писать весь софт под ваше NULL железо, написав ему лишь пару слов. Сам напишет, оптимизирует, скампилирует, протестирует и еще установщик напишет или загрузчик на любом языке. Технологий не стоят на месте, только древние люди которым нравиться писать ручками с нуля, но не на старых машинах, а на многоядерных и многие это любят делают на asmblere куда там rust\с\с++.
25:32 продолжение цитаты "Если написал код на C, то будет работать везде ... херово". Если мы хотим перфоманса, а на C мы хотим перфоманса, то под каждую платформу нужно будет переписывать код. И если ещё у нас под разными платформами разные компиляторы, то здравствуйте новые UB.
Также под платформу собирает не фронтенд компилятора, который для разных языков разный, а бэкэнд, которому пофигу на каком языке написана программа.
9:14 я тут проверил... Война и Мир - 188(!) тысячи слов...
т.е. строк(!) в браузере в 200 раз больше, чем слов(!) в ВиМ о_О
11:34 -- для написания ОС нету рантайм библиотеки -- там будешь юзать freestanding версию либы -- или самому все сделать, но енто гемор просто дополнительный и ненужный.
уже одалели если честно енту тему вообще поднимать -- линукс на си только по одной единственной причине -- потому что Линус Торвальдс хейтер с++ и адепт си -- больше нет никаких причин -- и тем более нет вообще никаких объективных
если ОС будет слишком толстым слоем, то получится браузер
Будущее за умными компиляторами (оптимизаторами) энивнэй
k chertu c davay na pascal pisat
Мое мнение такое, Си - это хороший язык, но устарел морально, и ему либо нужно совершенствоваться, либо искать другие инструменты. Тем самым появился раст и плюсы, но их опыта мало еще в наше время, чтобы создать что-то вроде линукса. Во всем есть плюсы и минусы
По поводу производительности, то у rust на уровне компилятора всегда есть лишняя проверка какая-нибудь, чтобы не совершать ошибка переполнения и так далее.
Писали бы на Ассемблере если бы не так муторно было бы, C - компромисс!
Не в восторге от Rust, но аргумент против него в том что ядро firefox с большего на cpp не верный, просто они еще не все переписали.
Что касается Си vs С++/Rust. Первый аргумент это - Си не имеет паник и исключений, а значи некий код ядра потенциально имеет меньше шансов сломать рантайм выбросив исключение или панику. Второй аргумент компилятор Си намного проще чем Cpp/Rust и уже портирован на многие архитектуры.
Про производительность, у Cpp намного лучше компиляторы по оптимизации, их годами задрачивали но вот рантайм либа у cpp намного жирнее и в том же embedded с десятками и сотнями килобайт памяти может занимать слишком много памяти или вообщеине вылазить за доступные объемы. В тех же машинах исспользую очень много чипов, обычно там памяти может быть десятки килобайт и ни какие либы для поддержки исключений, дженериков, многпоточности и др. туда просто не помещаются. Для более мощых по памяти девайсов cpp это очевидный выбор т.к. в "любимый" Си до сих по не добавили даже модульность аля неймспейсов и удобную обработку ошибок, что на практике геморой и много мусорных строчек в прикладном коде.
На самом деле, ваш коментарий, гораздо лучше, чем всё видео. Единственное с чем я бы поспорил, это с исключениями, они очень легко отключаются в С++, а на уровне ядра они явно будут лишними (по крайней мере на самом низком уровне). В общем исключения - не проблема, т.к. их можно отключить там, где они не нужны. А вот с тем, что компилятор Си проще (а следственно безопаснее) чем С++/Rust - это 100%.
Да и про портированность на большое количество платформ уже не так. Сейчас любой производитель нового железа пишет лишь бэк под инфраструктуру llvm, а не выпиысвает полный компилятор под конкретный высокоуровневый язык. Теоретически лишь могли остаться очень специфичные старые архитектуры, под которые еще бэк не писали, но при этом там еще существует какой-то экзотический компилятор C
@@AlexAlex-jk2tn спасибо.
Они не gecko переписывают на Rust, а с нуля создают Servo
Кто будет переписывать бесплатно миллионы строк кода на другом языке? Все разработчики ядра будут обязаны изучить еще один язык, чтобы что? Плюсов от переписывания больших нет. А сложности на пустом месте - есть. Вот поэтому все и пишется на все том же C.
Rust это вообще бред, а на плюсах можно писать также эффективно как на С если не использовать множественное наследование. Мне так плюсы удобнее чем С. Но Торвалд Линус предпочитает С поэтому ядро на С....
Си привнес удобство в общение с машиной , стало гораздо проще организовывать ресурсы и выстраивать логику для выполнения задач, Си ближе к скорости , чем с++ и более высокоуровневые языки, си это супер середина супер баланс между человекопонятным синтаксисом и эффективностью работы.
Все что выше си например, с++, раст, итд, это однозначно ещё большая простота в использовани, синтаксис становится ещё проще, но и цепочка посредников обеспечивающая эту простоту возрастает и в следствии этого падает производительность. кроме того реализация не всегда самая эффективная в этом упрощении синтаксиса. такие мысли.
в любом случае си будет оставаться базовой базой до тех пор пока индустрия придерживается булевской логики.
У C++ больше простота использования чем у C? У C++ синтаксис сложнее, больше ключевых слов + ООП. У него больше возможностей, но и сложней в использовании
@@NNAKG
у плюсов есть "встроенные" вектора и строки, что уже само по себе делает его синтаксически слаще чем стандартные си. Да, на плюсах чрезмерно много библиотек, что делает его сложнее в использовании, понимании и обучении. Однако писать что-то высокоуровневое со словарями, хэш таблицами, алгоритмами и т.д. на плюсах гораздо проще и удобнее.
ИМХО: плюсы удобнее чем си в использовании в 60% случаев, когда нужен низкоуровневый язык, и в 95% случаев, когда нужно собрать что-нибудь прикладное. Из этого следует, что плюсы - язык более простой в использовании* (следует отличать, что не простой в плане синтаксиса (хотя и это сомнительно ввиду отсутствия ООП на сях)) чем си
@@NNAKGЕсли коротко, то плюсы проще в использовании, но зачастую сложнее в синтаксисе
@@SaCorv это всё от недопонимания базы, когда базу понимаешь тогда и становится ясно что проще реализовывать на чистом си
@@ГригорийГанчарук Я надеюсь это шутка
Кто такой Раст?
Все просто- С это свобода и гибкость.ну на мой взгляд по кр мере
Неужели хоть 1 нормальный канал нашел по C на русском.
Ktotonokto можешь ещё посмотреть
@@andreevgerman1298 видел
Лучший канал тот на котором хвалят твой язык)
34:27 нейронка, программисты уже не нужны.
Интересная тема
на рутубе есть?
Там иди бузову смотри
В коментах гении собрались
К сожалению автор несёт чушь. Проверяйте всё что он говорит, (не)приятно удивитесь. В частности, компиляторы С умеют оптимизировать код. Ну и хинт. Если вы нагородили что-то на С++ такое, что оно стало тормознее С, просто используйте С реализацию. Добиться того, чтоб С++ был тормознее С технически невозможно, потому что всегда можно взять программу на С и сказать что это С++. (мелкие хаки на темных местах стандарта, когда С код не является валидной программой на С++ не в счёт)
Какой же бред: чел вообще за компиляторы не шарит, а "ключевые" причины строятся именно на них
Выберите Аду
пишу на С, сделал прототип
Причем тут не тот rust не тот c++? Причем тут их философия? Что за высосанные из пальца аргументы? Также можно и про философию с сказать
Скажи давай.
кловн
В с++ уже есть модули
Нет. Вернее как бы есть, но в продакшн код это еще ой как рано.
Когда они везде нормально будут работать, отпишите
std20 не на многих платформах поддерживается, если говорить о С, то там до сих пор С99 (или вообще С89) в большинстве случаев.
Имхо, С и С++ нужны современные гигиеничные макросы, ну и модульную систему, конечно, доделать. Эти header guards - это отвратительно. Еще хотелось бы статическую рефлексию на уровне языка (привет С++26 experimental)
Стабильность ABI = стабильность багов, стабильность костылей, стабильность непроизводительных решений. Это скорее вынужденная поддержка Легаси костылей а не стабильность
баги, костыли и "плохие" решения это скорее проблема прокладки между стулом и клавиатурой, а не проблема языка.
хруст ....
Растишка
деген
Чем высокоуровнее язык, тем больше неоднозначностей в нем можно начудить, отсюда ошибки, взломы, ..итд. Мое мнение.
на си налажать проще всего и взломов больше всего именно сишных тупых ошибок за границами массивов и проч.