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

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

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

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

Товарищ, а в чём разница между скоростью и стабильностью производительности? Если вызов gc буквально фризит (с) всё приложение, значит, приложение тормозит. Глубинная причина тормозов мало волнует, волнуют тормоза.

Там ещё тихо и незаметно Safe C++ подступает.

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

Опять 25. Первый абзац перевели, пошли пересказывать и переводить дальше.

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

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

По заголовку вообще как lua, которому массивы с 0 сделали.

В детстве я тоже любил такие гусарские заскоки :)
А вот почему синтаксис повторять не следует, я не понял… Нафига переучиваться, я, например, уже старый стал и ленивый

И так, переводим третий абзац:

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

TrapC code resembles C/C++ code, but, according to Rowe, it’s memory safe. That is to say, its pointers cannot produce segfaults, buffer overruns, or memory leaks.

TrapC позволяет пользоваться таким элементом языка Си как указатели безопасно.

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

Такой подход не гарантирует безопасное использование указателей. Т.е. урезает инструментарий Си.

Зачем это нужно когда уже есть D? Его нужность тоже под вопросом.

Disney

TrapC

It’s a trap!

Нет! За трапами только на Тайланд!

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

Его очень не хватало в этой тройке: Hare Zig Trap.

Ну вот в ядре Линукса их до сих пор любят :)

Вот именно потому, что ты старый и ленивый (впрочем, я тоже) и привык писать на Си именно так, как обычно пишут на Си (см. выше как), то ты и на TrapC будешь писать так же по привычке. И будет тебе ?MON-F Trap to 4 вместо работающего кода.

Или хуже, привыкнешь писать на этом TrapC и потом на C будешь писать так же. И будет тебе Trap to 10 :)

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

Проблема X11 в том, что так и не удосужились стандартизировать виджеты (кнопки, контролы, treeview и пр.) на стороне сервера и создать соответствующий протокол

Есть Xt но его современные тулкиты не используют все равно.

Ты тот Xt видел? Страшно не стало? :)

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

ну трап же. В одном слове вся суть, пиндосский сленг в помощь.

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

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

WinAPI более хаотично, зато Xt  — очень большой. И что бы на нем что-то написать, то много писать приходилось. Я когда-то в прошлом веке пытался что-то лабать на мотифе, так проще было на его UILe (или как-это там называлось) описать все виджеты, а потом уже руками добавлять колл-беки.

В общем, АЦЦкий АдЪ это все было и девять толстенных томов описания :)

?MON-F Trap to 4

Муахаха! В точку!

пытался что-то лабать на мотифе

Motif/CDE task builder или как он правильно назывался, не помню… Накидываешь интерфейс мышой, генеришь код и вставляешь обработчики. Я им точно пользовался на Digital Unix.

Не, вот до этого я не дошел. Я вот на этом безобразии что-то делать пытался — https://www.oreilly.com/openbook/motif/vol6a/Vol6a_html/ch24.html

C+++ нинужжжен.

That is to say, its pointers cannot produce segfaults, buffer overruns, or memory leaks.

TrapC позволяет пользоваться таким элементом языка Си как указатели безопасно.

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

Это не «безопасность», это просто попытка похайпиться на известном названии Rust, чтобы … даже не знаю, «чтобы что». Нет реалистичных идей.

Ну да, там надо что-то козырное покурить, чтоб воспарить с этим делом на одной волне..

С точки зрения условной «Java», запись за границей буфера — это ошибка, и программист получит стек трейс.

С точки зрения TrapC, это просто no-op.

Я думаю, есть причина почему тотальное большинство разработчиков нескриптовых ЯП и часть разработчиков скриптовых ЯП предпочитают вариант условной Java.

И эта причина называется «неявное поведение».

Не получится продать это как замену Rust.

Это не три плюса, это скорее один знак вопроса.

Не, там как раз все просто. Описываешь текстом из чего состоит твое приложение, получается такой себе ini-файл со вложенностью, потом это компилируется и, даже, работает без единой строки твоего кода. Менюшки открываются, Alt-F4 работает и все такое прочее. А потом на каждый элемент типа надо колл-беки написать.

Потом эту идею в язык описания объектов Корбы втащили, потом... И далее по тексту.

По заголовку вообще как lua, которому массивы с 0 сделали.

Кстати.

local a = nil
a[10] = 42

В Lua такой код выдаст стек трейс.

Если я правильно понял посыл автора TrapC, то там такой код просто молча продолжит работать.

Блин, у меня горит от того, как позиционируется этот ЯП.

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

А разница в чём? При чём тут безопасность?

Тот же Zig интереснее выглядит.

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

Да, я имею ввиду программистов.

Больше похоже на то, что все, кто пишут на Python/JS/Go

А они программировать-то умеют? Они хотя бы односвязный список сделать смогут? Двоичное дерево поиска? Не говоря о более сложных структурах данных. А алгоритмы они знают? Хотя бы такую простую технику, как префиксное суммирование?

В орден же «настоящих программистов» записываются только те, кто все пишет на Си

Не обязательно. Есть некоторое количество более-менее адекватных языков общего назначения. К таковым можно отнести C, C++, Pascal, ObjectPascal и т.п. Они все ужасны, но С в данном случае, вероятно, наименьшее из зол.

, вручную манипулируя памятью к месту и не к месту.

Программирование машины Фон-Неймана, это написание инструкций для работы с памятью. Без работы с памятью нельзя реализовывать структуры данных. А без структур данных нельзя составить нормальную программу.

По-иоему, в отношении D вопросов уже не осталось. Есть один один весьма любимый здесь категоричный ответ.:)

А они программировать-то умеют?

Я просто оставлю это здесь:

Запуск тестов

Есть Xt но его современные тулкиты не используют все равно.

Ну это же то же самое что и какой-нибудь FLTK или GTK. Нашлёпка на Xlib на стороне клиента а не server-side widgets с соответствующим протоколом для клиентской стороны.

Интересно, что сделали кучу всяких странных расширений X protocol’а, а хотя бы минимальным набором server-side виджетов так и не занялись. Причём отрисовку виджетов на стороне сервера можно было бы легко улучшать и развивать, не меняя при этом ничего в приложениях. В приложениях остались бы только сообщения типа «создай кнопку в окне с windowID по координатам x,y c текстом test и размером w, h», обработка событий от этих виджетов и посылка сообщений для управления ими. А сервер бы рисовал хоть минимализм как в Xaw, хоть современную плоскоту с прозрачностью и тенями, хоть блескучую выпуклость. Уж не говоря о шрифтах там и пр. И всё это работало бы с дичайшей скоростью по сети, до которой всяким RDP и VNC как до луны.

А так с развитием графики на компах в итоге получилось что ради рюшечек приходится гонять через сокет пиксмапы кнопочек и полей ввода или вообще работать мимо X-сервера.

А они программировать-то умеют? Они хотя бы односвязный список сделать смогут? Двоичное дерево поиска?

Знают. Умеют. Это часть собеседования в любую крупную компанию, есть такой сайт Leetcode - где готовятся к собеседованиям решая алгоритмические задачи, в основном на Python.

Хотя бы такую простую технику, как префиксное суммирование?

Послушайте. Не позорьтесь. Толи вы придуриваетесь, толи вообще дальше LOR не бываете.

разрывами фанбоев дыряшки доволен

«Современный X11» — это веб.

Клиент-серверный, с «виджетами» на стороне «дисплейного сервера». Как заказывали.

Причём отрисовку виджетов на стороне сервера можно было бы легко улучшать и развивать, не меняя при этом ничего в приложениях. В приложениях остались бы только сообщения типа «создай кнопку в окне с windowID по координатам x,y c текстом test и размером w, h», обработка событий от этих виджетов и посылка сообщений для управления ими. А сервер бы рисовал хоть минимализм как в Xaw, хоть современную плоскоту с прозрачностью и тенями, хоть блескучую выпуклость. Уж не говоря о шрифтах там и пр. И всё это работало бы с дичайшей скоростью по сети, до которой всяким RDP и VNC как до луны.

Не получится. Любому небанальному UI нужны элементы с кастомной отрисовкой.

А банальному UI пофиг, на чем и как рисоваться.

А так с развитием графики на компах в итоге получилось что ради рюшечек приходится гонять через сокет пиксмапы кнопочек и полей ввода или вообще работать мимо X-сервера.

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

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

Это не правда. segfault, Segmaentation fault - ошбика обращения к памяти на запрещенный или несуществующий адрес. Такая ошибка происходит из-за недочетов в арифметике указателей.

Так я про этот TrapC. Автор декларирует отсутствие сегфолтов.

Так я про этот TrapC. Автор декларирует отсутствие сегфолтов.

Теперь понятно.

Знают. Умеют. Это часть собеседования в любую крупную компанию, есть такой сайт Leetcode - где готовятся к собеседованиям решая алгоритмические задачи, в основном на Python.

Во-первых, список в питоне это ни разу не список как структура данных. Во-вторых, попробуйте взять чуть более сложную структуру данных, например кольцевой список. И тут уже для большинства Python/JS/Go «специалистов» все...

А теперь я оставлю здесь это))

ГПСЧ кросс-платформенно

Ты вообще тему читал?

«Специалист» поплыл? А что так?

С точки зрения условной «Java», запись за границей буфера — это ошибка, и программист получит стек трейс.

TrapC это не Java, это форк диалекта Си c дополнительной степенью защиты. В середине статьи они беседуют как проверять границы массива за минимальное время.

И эта причина называется «неявное поведение».

На то это и Си, а не Pascal.

Не получится продать это как замену Rust.

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

Во-первых, список в питоне это ни разу не список как структура данных.

Перестанье позориться. Сходите на Leetcode, почитайте задачи.

Мне просто интересно, что ты пытаешь этим сказать? В теме обсуждалась возможность платформонезависимо инициализировать ГПСЧ без опоры на время с точностью до секунды. Пришли к выводу, что не получится это сделать гарантированно. Какое это имеет отношение к структурам данных или алгоритмам?