Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью

Есть же Qt например, там это автоматизированно без всяких GC.

А зачем создавать новый язык для исправления таких мелочей?

Ещё один.

Кликните два по сслыке на источник, там целая статья объсняющая зачем.

По ссылке вообще написано: «В куче применяется инкрементальное автоматическое управление памятью, но без сборщика мусора.». Па-ра-пара-пам!

Про дихотомию Оустерхаута слышали?

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

Если какой-нибудь Гуй, так не на Си точно. Вон X11 написали, так до сих пор мучаемся. :) И GC там дело не главное. При написании всяких ГуЁв временный объем потребляемой приложением памяти может расти самым драматическим образом. На том же умном скроллинге, например, если у тебя не просто текст, а таблица каких-нибудь объектов. И управляемые языки с GC там, скорее, вред, чем польза. Хоть и удобно.

Ygor, скорее всего в TrapC нет GC.

https://www.opennet.ru/opennews/pics_base/CFD0C5CECEC5D4_1731442817.png

Fast incremental automatic heap memory management: no gargbage collector stop-theworldsweep memory manager as in Java

Что качается Trap - заглушки которые перенаправляют указатель вышедший за пределы массива на 0.

And I was like, ‘Well, since the compiler knows where the end is, what if when it goes off the end, the pointer just went to zero?’ And that’s much easier to deal with than a wild pointer because you can easily check if the pointer is zero.

https://www.theregister.com/2024/11/12/trapc_memory_safe_fork/

Создается решение под определенную область для людей хорошо знающих С.

Люди хорошо знающие Си, использовали и будут использовать память. Без этого вообще ничего нормального не написать.

Фон-Неймановским языкам не нужен никакой сборщик мусора, программист на этих языках думает как машина.

Отлично. Вам не нужен, вы не пользуйтесь.

И чо?

Prototypical examples of system programming languages include C, OCaml and Modula-2.

Он бы в системные языки еще Хаскель бы записал. Тоже в машкод компилируется и имеет статическую типизацию :)

Проверил календарь. Сегодня не первое апреля!

Уже есть Hare и Zig. Чем этот язык лучше?

спиральное разворачивание можно лишится как и кучи раставляющих очерёдность скобок при условии что все унарные операции записывать только с одной стороны(левой али правой здесь не суть - главное что с одной стороны что однозначно задаёт порядок(дальность) от выражения )

в действительности за полвека многие баго-фичи Сей( а си не самоцель как и Sexp)(«си вообще имя от CompilerConstructor» из книжки 60ых где тримоно трансляций показывали как заменить n*m трансляторов на (n+m) ) исчерпаны

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

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

Да любое добавление скрытого рантайма и безопасных указателей ломает способы работы с raw-указателями, к которым все в Си и привыкли.

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

Гошечка не выглядит таким уж ублюдством.

4.2

Окамл — тоже. У него есть компилятор в машкод, но без скрытой исполняющей системы я не представляю, как это работает. Ленивые потоки в Окамле есть, а, значит, есть и space leaks и прочие «недокомпиленные» замыкания. Может окамловцы с этим борются, но как? Я как-то спрашивал Лероя давно-давно на тему спортировать Окамл на КПК, так ответ был — стека не хватит :)

Это вкусовщина :)

Ну именно так! И «мы его любим не только за это» (с)

Если какой-нибудь Гуй, так не на Си точно.

Ну так-то да, для гуя объектики с сигналами чуть удобнее, чем портянки с case(event).

Вон X11 написали, так до сих пор мучаемся. :)

Проблема X11 в том, что так и не удосужились стандартизировать виджеты (кнопки, контролы, treeview и пр.) на стороне сервера и создать соответствующий протокол, из-за чего возник зоопарк несовместимых реализаций виджетов на стороне клиента со всеми вытекающими, от Xaw/Motif до KDE/GTK. X11 на самом деле не отличается от вендового GUI на уровне событий и отрисовки, практически один-в-один примитивы, концепции и пр. Только виджетов не хватает. Виджеты можно было бы реализовывать на стороне сервера в любом желаемом виде, что дало бы неограниченные возможности для кастомизации, тем и т.п. И тогда не помножились бы на ноль сетевые возможности иксов из-за того, что клиент со своей библиотекой виджетов норовит не отправить сообщение «создать кнопку с надписью ‘ОК’» и только ловить нажатия от сервера, а самостоятельно пикселями отрисовать её и обслуживать весь жизненный цикл этой кнопки, да ещё и со всякими OpenGL или Vulkan для рюшечек и украшений.

При написании всяких ГуЁв временный объем потребляемой приложением памяти может расти самым драматическим образом. На том же умном скроллинге, например, если у тебя не просто текст, а таблица каких-нибудь объектов.

Не очень понял. Имеется ввиду что рендерится вся таблица, а не только тот кусок, который должен быть виден на экране? Так какой же это «умный скроллинг»? Умный же скроллинг, это вообще когда при скроллинге рендерится даже не вся видимая часть, а только строчка которая должен появится в окне, а всё содержимое рендерится только при страничном перелистывании или инициализации. Откуда тут расти потреблению памяти?

Кликните два раза по сслыке на источник, там целая статья объсняющая зачем.

На заборе тоже написано, а там — дрова.

Вы без критического мышления верите всему, что написано?

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

Раст даёт статические гарантии, а сабж — только рантайм-гарантии.

Выше правильно пишут, что сабж можно условно рассматривать только как (зачем-то) альтернативу Go, но не Расту.

Впрочем, сейчас если лень не будет, напишу развёрнутое мнение про сабж. А то вы тут как-то вяло дискутируете. =)

See trap? No, only trap see!

Наличие GC

Это откуда взяли?

Фон-Неймановским языкам не нужен никакой сборщик мусора

Никому из программистов не нужен.

Откуда вы только беретесь спорщики с реальностью? Вот брать и писать откровенную чушь. Откровенная 100% фигня, опровергаемая ральностью на каждом шагу от Gentoo до Github и Leetcode, от Yandex до Google.

У меня один вопрос вы реально так думаете или вы просто тролль который пишет откровенную фигню и радуется возмущению?

На заборе тоже написано, а там — дрова.

Да. Есть такое. Вы то сами статью прочитали? Или вы сразу коммент, без вникания в первоисточник.

Он имеет в виду настоящих программистов, а не всяких там, прости Господи, быдлокодеров.

Умный же скроллинг, это вообще когда при скроллинге рендерится даже не вся видимая часть, а только строчка которая должен появится в окне, а всё содержимое рендерится только при страничном перелистывании или инициализации. Откуда тут расти потреблению памяти?

Хотелось бы что бы оно так было, но, зачастую, оно не так. Вон из нашей практики. Есть часть большой программы, которая сравнивает контент двух файлов (этакий то-ли meld, то-ли KDiff3 по смыслу). Так кусок так написан, что при скроллинге программа выедает гига четыре и хочет больше. Потом память сдувается куда-то, но пиковое потребление очень большое. Писано на Це-шарпе, ака До-диезе. Я пока не могу сказать, это плохо написанная программа или отложенная работа GC.

Ещё один.

Если нас так много, может это не просто так? Ладно я был бы разрабом на Сях и возмущался, но я вообще не при делах и такое множество похожих языков, решающих почти одно и то же напоминает мне множество фреймворков для JS, которые только портят индустрию.

Раст даёт статические гарантии, а сабж — только рантайм-гарантии.

Решается одна задача безопасное обращение с памятью. Возможно разными методами.

Впрочем, сейчас если лень не будет, напишу развёрнутое мнение про сабж. А то вы тут как-то вяло дискутируете. =)

Уже неприлично дискуитировать больше. И так всё понятно.

Пусть затестит какую-то старую версию либс и покажет, как известные CVE испаряются на глазах.

А зачем создавать новый язык для исправления таких мелочей?

Если нас так много, может это не просто так?

Все просто. Люди не читают и пишут комменты. Настругана целая статья, снято целое видео, добавлены слайды в описание. Заходит очередной пользователь и спрашивает «А зачем?».

В первом абзаце статьи напиано зачем: Для того чтоб пользователям языка Си не надо было учить Rust для безопасной работы с памятью.

Прочитал, вам пересказал.

не трогай гошечку!

Недостаток Си в том, что он слишком низкоуровнев и концептуально староват, при этом это касается всех, кто на нём пишет. Нельзя прийти в язык и начать на нём писать какие-то «формошлёпские» приложения, не имея серьёзной базы и собственнописного рантайма для неё. То есть, язык очень медленно развивается. С одной стороны это понятно, а с другой стороны - можно было бы несколько важных вещей из того же C++ утащить почти за бесплатно, не портя общую концепцию. Многим нужен С++, но без заморочек вроде STL и не такой жирный как JAVA.

А вы только на одном Qt везде пишете? Я вот обладаю статистикой, что у большинства Qt-разработчиков вообще профдеформация касательно того, что в современном C++ творится.

Хотелось бы что бы оно так было, но, зачастую, оно не так. Вон из нашей практики…

Это следствие абстракций на абстракциях и фреймворков на фреймворках. Когда пишущий полагает, что фреймворк и абстракции всё сделают сами, и зачастую даже не представляет как это всё работает и на что может тратится память. В вебе это сплошь и рядом, например. Жабоскрипт утягивает миллион строчек из базы на сервере в виде JSON, и рендерит их полностью в HTML элемента, чтобы всего десять из них оказались видны в этом элементе. Ненуачо, браузер же скроет ненужное. А при каком-нибудь изменении одной строчки весь процесс происходит заново. Вот и сжирается вся возможная память. Да и сами браузеры точно так же себя ведут. Рендерят не тот кусок HTML, который нужно отобразить в данный момент, а всё целиком.

Так что это глобальная проблема, и похоже нерешаемая. Никакие GC или прочие штуки не помогут её решить.

Он имеет в виду настоящих программистов …

Больше похоже на то, что все, кто пишут на Python/JS/Go, автоматически, как водится, вычеркиваются из почетного ордена «настоящих программистов». В орден же «настоящих программистов» записываются только те, кто все пишет на Си, вручную манипулируя памятью к месту и не к месту.

Или какая-то подобная вариация споров с действительностью, a la Кроко style.

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

Из той же статьи.

Doing something to improve memory safety has become a matter of national security, supported by the White House, the Five Eyes intelligence agencies, federal law enforcement, and the US Cybersecurity and Infrastructure Agency, among others. Memory safety bugs account for about 75 percent of the CVEs used in zero-day exploits, according to Google. And about 70 percent of severe vulnerabilities in large codebases are attributable to such bugs.

Люди решают не ту проблему не теми средствами. Придумывают очередные memory-safe языки, а кодовая база остается той же. Да и руст полезно выучить для общей образованности.

Многим нужен С++, но без заморочек вроде STL

Есть люди, что пишут на С++ без исключений и std, делая все экспорты extern «C». Что всё равно менее портабельно чем Си, потому что компилятор норовит вставлять вызовы всяких странных функций из С++ рантайма. Если пишешь на С++, то не обязательно обмазываться всем, что там появляется с каждым новым стандартом. Тем не менее, большинство как раз желает обмазываться, так что я не понимаю о каких многих вы говорите.

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

Ну это со стороны ОС может быть сделано. Т.е. чтобы можно было установить абсолютный лимит памяти на приложение, и чтобы никакие fork’и и mmap’ы не позволялись если суммарный объём памяти запрошенный приложением и всеми его дочерними процессами (включая setsid’нутые) превышает лимит. Этого можно добиться через одно место в контейнере, но и контейнер не позволяет ограничить mmap файлов, чем и пользуются те же браузеры, например, чтобы сожрать всю память даже из лимитированного контейнера.

Да и руст полезно выучить для общей образованности.

Да вы правы. Rust выучить полезно. Но Rust это экзотика, а некое подмножество языка Си знают все: от математиков до схематехников. По этому для общего пользования делают безопасное подмножества языка Си, чтоб пользователи не перучивались.

бывший профессор компьютерных наук, принимавший участие в комитетах по развитию стандартов С и С++

Можно закапывать даже не тыкая

Я днём прочитал новость про сабж на опеннете и как раз думал, что вечером на ЛОРе обсудим :D

Я почитал в общих чертах про TrapC и Fil-C, и я не понял нишу для этих языков. На мой взгляд, это академические проекты без будущего. Объясню, почему я так считаю.

«Простой Си-подобный язык с легковесным рантаймом и сборкой мусора» уже существует и называется Go. Я думаю, усилиями Google Go уже занял все возможные ниши, где именно такой язык был востребован.

Если делать язык, который синтаксически похож на Си до степени смешения, но при этом имеет другую семантику — для этого нужно ответь на вопрос, а какую мы этим задачу вообще решаем. В чем смысл.

Я не вижу для этого причин кроме разве что чисто субъективной «у Си такой хороший синтаксис».

Но с моей точки зрения, синтаксис Си как раз не хорош. Хорош был именно сам язык как концепция и также набор компиляторов к нему, что позволило доминировать в определённой нише на протяжении долгого времени. В то время как конкуренты по полунизкоуровневому программированию оставались на этапе концептов или очень узкоспециализированных решений (Паскаль, Модула и т.п.)

При этом синтаксис Си местами это катастрофа (как местами и семантика), и терпеть его можно было как раз от того, что это была лингва-франка всея системщины, а не в силу преимуществ самого этого синтаксиса.

А теперь возвращаесь к анализу языков:

Выше по треду была упомянута дихотомия Оустерхаута.

На мой взгляд, существует язык, который относительно успешно умудряется сочетать в себе обе стороны дихотомии, расплачиваясь за это жирным рантаймом, но покрывая при этом очень большие области прикладного программирования, в том числе и гейм-дев. Это C#. Технически он не «скриптовый», но умудряется местами довольно эффективно покрывать часть этой ниши. До такого монстра TrapC очень далеко, и у них никак не могут пересекаться ниши.

Далее в скриптовой стороне дихотомии сейчас тотально преобладают JS и Python.

В «системной» стороне, кроме самого Си, ниши поделили C++, Go, и вот теперь еще — Rust.

Попытки создать Си-подобный язык с продвинутыми статическими гарантиями были давно, я помню несколько проектов начиная с 00-х. Но выстрелить в итоге смог только Rust, от остальных попыток сейчас даже названий никто не помнит.

Как по мне, этот новый ЯП просто некуда тут вставить. Нет запроса, который можно было бы удовлетворять.

А на что может быть запрос?

Я вижу два направления, где это возможно.

Первое.

Это язык, который «концептуально прост», но при этом имеет мощные средства типизации и/или метапрограммирования, компилируясь при этом в код с минимумом ран-тайм издержек. То есть ЯП, который попытается конкурировать с Си++ и Rust за счёт более «простого и ясного» кода без существенной потери выразительных средств (или даже с увеличением выразительности, чем чёрт не шутит). На самом деле, в этой нише постоянно возникают различные любительские проекты, которые пытаются эту задачу как-то решить. То есть у людей не только есть запрос, но и постоянно присутствует впечатление, что задача решаема. Что «можно почти так же — но проще». Так это или нет — покажет время.

Второе — более реалистичное. И где также идёт активная работа разных компаний.

Это развитие компиляторов самого Си. То есть задача не в том, чтобы сделать «ЯП похожий до степени смешений, но отличающийся». А сделать более мощные средства контроля семантики кода и аннотации этой семантики. Чтобы ворох UB, которые молча проглатывают современные компиляторы, можно было более эффективно ловить и контроллировать. Как в компайлтайме, так и в рантайме, в зависимости от того, что это конкретно за виды UB или ошибок. Чтобы в зависимости от потребностей разработчика, при отладке ПО всё это контролировалось опциями сборки или прагмами в самом коде.

И проблема сабжа здесь именно в том, что он — не Си. Он похож, но это другой язык. Он не устроит тех, кто хотел бы поддерживать и развивать кодовую базу на Си, но иметь при этом продвинутые средства контроля безопасности.

Семантика должна быть точной. Если программа является корректной в рамках семантики Си, она должна работать идентично в этом «продвинутом Си». Полумеры здесь бесполезны, когда речь идёт о поддержке огромных исторических кодовых баз.

И как это поможет снизить обеспокоенность федеральных служб США утечками памяти в существующем коде? :) Новое и на расте написать можно. :)

Проблема новых языков в том, что они — новые, что никак не влияет на существующую кодовую базу. Я вот тут три дня отлаживал свой ядерный код, как раз обращения по левым адресам памяти и всякие многочисленные strcpy. И проблемы у меня были алгоритмические. И хорошо, что ядро тупо падало и отбрасывало стек-трейс (и то не всегда успевало), я хоть видел где. И как мне в этом поможет руст или этот TrapC? Руст в ядре пока выглядит примерно никак, хоть он там и есть.

А вы только на одном Qt везде пишете?

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

ППКС!

Новое и на расте написать можно. :)

Что-то мы вокруг одного и того-же крутимся уже который комментарий. Можно написать на Rust, на Zig, на ODIN, на Nim, еще на Hoare. Только их мало кто знает, а Си знает весь инженерный состав.

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

В «системной» стороне, кроме самого Си, ниши поделили C++, Go, и вот теперь еще — Rust.

В эту вереницу ещё можно на правах аутсайдеров добавить Zig, V-lang и Hare. И они, внезапно, имеют куда больший шанс откусить что-то чем этот TrapC.

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

Уже есть такая задача: сборка проектов. Буквально сегодня положил билд-зиг рядом с вин32-пет-проджектом. Как по маслу.

Ну может быть. Выстрелит, тогда и посмотрим, куда попадет.