Fil-c: Rust killer

@shdown А ты рассказывал, что в Си на лисп-машине указатели не то, что обычно? Кажется тут тоже что-то такое.

Эх, @Obezyan в бане.

@AlexVR @zurg

Ну нет, друзья, постойте!

Провозглашаем memory safety? Провозглашаем.

Затем делаем unsafe блоки. Непоследовательно?

И вот, та-дам, есть решение БЕЗ unsafe блоков.

П. С. Подумываю собрать что-то своё с этим вот, оценить импакт.

Шо, опять?

Снова

• Fil-C -- компилятор для языков C и C++, гарантирующий безопасную работу с памятью

Так уже сколько времени прошло! Почему бы не писать по любому поводу и без про Fil-C? Скажем, дважды в день.

Провозглашаем memory safety? Провозглашаем.

Затем делаем unsafe блоки. Непоследовательно?

Вопрос дилетанта. Не понимающего что и зачем.

Если тролишь. То это слишком плоско.

Мне напомнить о известном напитке и количестве раз его приëма в день? :)

Про руст каждый день по три раза пишут

Признаюсь, я о расте знаю только по историям с ЛОРа. Можем продолжить моё образование: объясни, почему мой вопрос некорректен.

В видосике, который я привёл, озвучен довод про unsafe блоки. Он показался мне достойным внимания.

Иногда чувствую, будто я уже захлебываюсь… :c

Но баяны им не ставят!! А мне ставят(

Rust killer

Ну ему точно хана!

Your C or C++ software most likely compiles and runs in Fil-C with zero changes.

Т.е. все UB в языке на месте? Ну и нафиг он такой нужен?

runtime checks

бгг.

C, C++, Rust берут там, где выжимают максимальную скорость, экономят память и избавляются от GC.

Сабж на всё это забил, какой он киллер?

rewrite all your software in Rust and still have unsafe blocks and runtime checks (bounds, div by zero, etc.)

бгг.

если существуют вещи, без которых принципиально нельзя обойтись, то давайте и на всё остальное наплюём.

ну-ну

Т.е. все UB в языке на месте?

А сколько их там, которые возникают не из-за ошибок программиста?

Чем это лучше чем любой другой язык с GC, например голанг?

выжимают максимальную скорость, экономят память и избавляются от GC

Сомнительное утверждение про скорость. GC никак не мешает «скорости», часто даже быстрее чем пердоханье со всякими умными указателями.

Advanced runtime checks

Кина не будет, клоуны закончились.

которые возникают не из-за ошибок программиста?

Если программист пишет программу, он избегает UB, т.е. все UB - результат ошибки. Поэтому я не понимаю, для чего задавать этот вопрос?

В очередь, собакины дети!

Поэтому я не понимаю, для чего задавать этот вопрос?

Потому что он в точности соответствует вашему:

Т.е. все UB в языке на месте?

Ведь если программист «избегает UB», т.е. не совершает ошибок, то ему и без разницы все ли UB на месте или нет.

почему мой вопрос некорректен.

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

т.е. не совершает ошибок

А, так вы свидетель расы сишников-сверхлюдей, не совершающих ошибки, понятно.

GC никак не мешает «скорости»

Возможно. Это ортогональные причины.

Чем это лучше чем любой другой язык с GC, например голанг?

Думаю, пойнт в возможности «захарденить» уже написанный код.

А, так вы свидетель расы сишников-сверхлюдей, не совершающих ошибки, понятно.

Ни в коем разе.

Меня интересует стоимость.

Грубо говоря, вот есть ошибка – выход за пределы массива. Сколько стоит ее предотвратить в коде (чтобы не дать программисту ошибиться)? Сколько стоит ее диагностировать в ран-тайме (т.е. программист таки ошибся, мы не хотим, чтобы она привела к пагубным последствиям)?

В вину C++у ставят то, что он вообще не пытается предотвращать последствия ошибок в ран-тайме. Т.е. если вышел за пределы массива, то у тебя UB, а не исключение или паника. Но при этом твой код работает на 5% быстрее и потребляет на 20% меньше памяти (условно).

Мне кажется, что C++ предлагает честный обмен. И как-то странно, что его этим попрекают.

При чём тут UB? UB для работы программы требоваться не может.

при этом твой код работает на 5% быстрее и потребляет на 20% меньше памяти (условно)

Зачем тебе неправильный результат работы программы на 5% быстрее и 20% меньше памяти?

UB для работы программы требоваться не может.

Конечно, не может. Но что делать, если программист ошибся?

Во-первых, баян.

Во-вторых, с таким же успехом можно писать на Java или Go.

Fil-C achieves this using a combination of concurrent garbage collection

Зачем тебе неправильный результат работы программы на 5% быстрее и 20% меньше памяти?

Так фокус-то в том, что неправильный результат программы не нужен вне зависимости от того, была ли ошибка диагностирована в ран-тайме или не была (произошло UB).

Т.е. если я открываю в условном текстовом редакторе документ со сложным форматированием и мне выдают аккуратное окошко «не шмогла» или же редактор тупо падает с SIGSEGV, результат для меня одинаковый – я не могу сделать то, что мне нужно.

Причина этого не в наличии/отсутствии UB, а в том, что программист ошибся. И его ошибка не была обнаружена при тестировании.

Т.е. мне в принципе нужна программа, которая делает свою работу без ошибок. Если в ней есть ошибки, то (по большому счету) программа бесполезна. Вне зависимости от того на безопасном Rust-е она написана или на опасном C++.

Через год программистов не будет. Все программисты пойдут работать в КБ и пятёрочку.

В gcc уже есть нужная фича, чтобы не было утечек при динамическом выделении памяти, но без дженериков её сложно юзать.

редактор тупо падает с SIGSEGV

Или не падает, т.к. ты вышел за пределы массива, но не попал не следующую страницу памяти. И редактор просто записывает на диск мусор. UB не приводит автоматически к сегфолтам, это было бы слишком просто.

Compiler is based on a recent version of clang

шило на мыло

Или не падает

Мне без разницы падает ли он или начинает рисовать мусор на экране. Или писать мусор в файл.

Вы упускаете ключевое – программный продукт должен работать без ошибок. Иначе в нем нет ценности.

Возникновение паники или исключения так же может портить данные в файле, например, часть до паники записали, а после паники ничего не восстановили или не удалили записанное.

В итоге такое же говно, только в другой обертке.

Поэтому и странно, что акцент делается на UB (т.е. на последствиях ошибки), а не на средствах по ее (ошибке) предотвращению.

Если бы вы спросили «а Fil-C поддерживает все те же возможности выстрелить себе в ногу?», то мне бы это было понятно. Но ваш вопрос был про количество UB.

программный продукт должен работать без ошибок. Иначе в нем нет ценности.

Должен. Разница в том, как разные языки подходят к проблеме того, что программисты ошибаются. Яваскрипт до последнего делает вид, что всё нормально, Раст бьёт по рукам по большей части на этапе компиляции. Си заметает проблему под ковёр так, что даже тестирование не всегда спасёт, программист должен писать идеально, и точка.

Возникновение паники или исключения так же может портить данные в файле

Могут. Но это будет заметно по самому факту паники. Будет повод достать бэкап вместо того, что бы сохранить новую версию в бэкап.

акцент делается на UB (т.е. на последствиях ошибки), а не на средствах по ее (ошибке) предотвращению.

Именно на отсутствии оных средств и делаю акцент.

Если бы вы спросили «а Fil-C поддерживает все те же возможности выстрелить себе в ногу?», то мне бы это было понятно. Но ваш вопрос был про количество UB.

Это эквивалентные вопросы, и вы это сами понимаете, предлагая такую замену.

Речь же о Fil-C. С Fil-C тебе не нужен unsafe, не нужно «хорошенько тестировать» — потому что он даёт гарантии memory safety. Более того, Fil-C позволяет иметь memory safety межку либами, чего также не даёт rust, если я правильно понимаю.

Если ошибся - значит программа будет неправильной. Но при чём тут UB? Ни при каких обстоятельствах UB не может требоваться для работы. Это противоречит его определению.

Речь же о Fil-C. С Fil-C тебе не нужен unsafe, не нужно «хорошенько тестировать» — потому что он даёт гарантии memory safety. Более того, Fil-C позволяет иметь memory safety межку либами, чего также не даёт rust, если я правильно понимаю.

Звучит буквально как чудо)

Через год программистов не будет.

Да, ИИ внедряется в программирование семимильными шагами, гораздо быстрее других отраслей. Но и до вашей отрасли дойдет)

Но и до вашей отрасли дойдет)

Я директор Советского Союза.

Advanced runtime checks to prevent exploitable memory safety errors.

Безусловно, такие проверки приведут к скачку производительности, что очень понравится писателям критически чувствительных к задержкам приложений. Ну что сказать, ново, оригинально, молодёжно!

Очередной филипок-недоучка, выкинутый из университета за проф. непригодность познаёт мир. Пожелаем ему успеха, и дальнего плавания.

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

Это уже разговор о том, как лучше обосраться: много и жидко или мало и твердо (ну или наоборот).

Возможно, для каких-то областей это важно. Например, если у нас есть сервер, который смотрит прямо в Интернет и его могут атаковать. Перестанет ли он пускать вообще всех или, напротив, начнет пускать вообще всех.

Но ведь суть-то все равно в другом: как не обосраться.

Но это будет заметно по самому факту паники.

В ноябре 2025-го клиентам Cloudflare от этого факта стало сильно легче, ага.

Это эквивалентные вопросы, и вы это сами понимаете, предлагая такую замену.

Для меня это как раз не эквивалентные вопросы.

Но при чём тут UB?

При том, что бывают языки и их подмножества без UB. В которых ошибка на единицу не приводит к инкременту не той переменной или тихой записи мусора в файл.

Ни при каких обстоятельствах UB не может требоваться для работы.

Конечно, не может. Так зачем плодить языки, нафаршированные UB?

Перестанет ли он пускать вообще всех или, напротив, начнет пускать вообще всех.

Встроенные в язык проверки приведут к первому варианту, UB запросто и ко второму.

Но ведь суть-то все равно в другом: как не обосраться.

Вот именно. И если обосрался, как заметить этот нюанс. Языки с UB активно мешают заметить.

Меня больше всего настораживает слово exploitable, не зря оно там. Видимо, другие классы memory safety errors остались на месте.

@unC0Rr что-то не так?

Безусловно, такие проверки приведут к скачку производительности, что очень понравится писателям критически чувствительных к задержкам приложений. Ну что сказать, ново, оригинально, молодёжно!

Говорит от 1.2 до 10 раз медленне. Но это хобби проект одного человека.

Очередной филипок-недоучка, выкинутый из университета за проф. непригодность познаёт мир. Пожелаем ему успеха, и дальнего плавания.

http://www.filpizlo.com/