Comments 29
Вы какой язык пытаетесь улучшить C, C++? И улучшить в чем? Синтаксис, скорость, безопасность, совместимость или что-то еще?
Rust: просто существует.
Единственный недостаток Раста - это порог входа (хотя, может, и преимущество - кому как).
Начать кодировать C можно просто прочитав по диагонали первую главу - в сущности это язык, котоым должен был бы быть бейсик. А вот с Растом такой фокус не выйдет -- ровно потому, что он дает намного больше чем тут запрашивалось. К примеру, тут не запрашивалась асинхронность и многопоточность - это встроено в Раст. Начинаете сразу путаться со ссылками, с константыми и не константными, и не врубаетесь за что от нас хотят столько клонов.
Начать кодировать C можно просто прочитав по диагонали первую главу
На мой взгляд, это обманчиво. Синтаксис у С может и простой, но чтобы писать нормально вам понадобится изучить кучу всего сверх - зазубрить список ub, следовать различным best practices, помнить кучу различных тонких мест, четко следить за множеством неявных конструкций типа кастов и тд. Это не говоря о разных стандартах и система х сборки, что по сути отдельный язык в нагрузку.
Начать кодировать C можно просто прочитав по диагонали первую главу - в сущности это язык, котоым должен был бы быть бейсик.
Если цель написать Hello world то да. Но уже на втором шаге:
порядок объявления функций важен
на ровном месте словили UB
типы не типы
веселуха с заголовками
веселуха с указателями
на ровном месте словили UB
на ровном месте словили UB
сломали память
из стандартных структур данных только массив, строк нет а числовые типы вам вообще ничего не обещают, удачи с подключением библиотек
В то время как в Rust порог действительно высокий, но явный. Основная сложность - побои и оскорбления со стороны компилятора. Если программа собралась - она будет работать. Плюс Rust современный и следовательно и стандартная библиотека богатая, и проект собирать не сложно и подключать библиотеки просто и не нужно думать как тип или библиотека будет себя вести на этой системе.
Я думаю нет простых системных языков. Разница просто в чем сложность.
Память, скорее, сломали при первой же попытке работе с нею
Это надо быть совсем безнадежным.
Речь же про C. А там - достаточно пройтись в цикле по строке как массиву, промахнувшись в счётчике на единицу - и вот влезание в чужую область памяти. Пока изучал как программировать в такое наступал даже не знаю сколько раз.
Или выделить памяти на нуль-терминейтед строку, забыв учесть хвостовой нуль, но потом попытаться его в строку всё же запихать.
Или попытаться разыменовать переданный в функцию указатель, передав по ошибке неициализированный, когда только учишься с ними работать.
Или начать разбираться "что за зверь void* и что он даёт?" и вместо char* его как int* обходить...
В стародавние времена могло даже и не упасть. А могло сходу ребутнуться, по классике. (но да, это скорее "UB по порче памяти", чем просто порча памяти)
Rust показывает явно сложность программирования.
C, Go внешне просты, но держатся на такой дисциплине что у растоманов волосы на ж шевелятся.
Единственный недостаток Раста - это порог входа
Ничто не мешает вайбкодить, даже на расте.
... и дай бог ему здоровья и удачи. Оба ему еще неоднократно понадобятся. Особенно когда в коммунити фанатов в разы больше, чем мастеров.
С институтских пор меня напрягала одна особенность компиляторов - почему функция должна быть обязательно описана ДО её вызова. Почему нельзя вставить вызов вот здесь и сейчас, а саму функцию написать позже в конце файла.
Насчёт альтернатив C я поспорю, ведь есть Rust, Zig. Но вот задумка языка интересная.
У меня нет директив для инклюдов или импортов. На мой взгляд, такое лучше настраивать в конфигурации проекта, а не в каждом файле
Возможность инкрементальной компиляции (когда при изменении одного файла мы пересобираем не весь проект а только зависящие от него файлы) лучше заложить с самого начала, потом добавлять будет больно. И как раз для этого импорты и нужны.
Упомяну до кучи ещё одну большую боль C/C++ - это макроподстановки (#define). Они очень сильно портят жизнь IDE, усложняют автоматический рефакторинг.
В то же время, макроподстановки имеют широкое применение для конфигурирования проекта, и не только.
Для нового языка как минимум нужно предложить какие-то решения на замену макроподстановкам. Что-то для compile-time настроек.
И даже что-то, частично заменяющее кодогенерацию (например, в D пытались реализовать миксины). Хотя подозреваю, что любая кодогенерация опять испортит рефакторинг. В общем, это непростое дело.
В наше время язык программирования скорее должен быть заточен под LLM...
Каким он должен быть? Не знаю. Наверно, производительным, как Rust. Надёжность Rust, в т.ч. статическая типизация, похоже (по некоторым отзывам), и для LLM полезна. Хотя, наверно, LLM могли бы использовать и что-то типа ассемблера (могут, но не знаю, насколько это будет эффективно для больших проектов). Есть плюс и в интерпретируемости Python - LLM очень легко пишут скрипты для проверок своих гипотез, и лучше, когда скрипты выполняются мгновенно. Возможно, такой "следующий" язык будет трудночитаемым для человека, но легкочитаемым для ИИ.
Возможно, проблема в том, что разработчики любят чрезмерно экспериментировать, мечтая придумать что‑то лучшее. […]
Каким должен быть идеальный язык? В моем представлении идеальный системный язык должен быть классическим и простым. Чтобы потом не возникало сожалений о каких‑то сомнительных решений. И конечно же, чтобы каждый мог за час разобраться в нем.
Мне кажется или вы в своем дизайне сделали все да наоборот? И поэксперементировали и ушли от классики и простоты.
Вот если бы вы сделали точь в точь Си, но поправили ошибки, которые описали вначале. Вот тогда это было бы “классически” и “просто” и: каждый мог за час разобраться в нем
Разве вы не сделали то, за что осуждали другие языки? Поэкспериментировали. Во многом получился язык похожий на Java/Kotlin, но с добавлением ваших наработок или идей.
Также, раз уж мы продумываем "идеальный системный язык", то важным аспектом будет backend составляющая. Как язык управляет памятью, как предотвращает use-after-free? Раз уж вы используете классы, наверняка нужны будут деструкторы, операторы копирования и movement-а. Подобных вопросов еще очень много может быть, системные языки очень сложные и обязывают иметь четкую модель компилятора.
Не поймите меня неправильно, я не стараюсь осудить. Наоборот я очень рад что вы заинтересовались созданием языков программирования. Просто пытаюсь сказать, что делать сразу "идеальный" язык требует продумывания очень многих аспектов.
Единственное, что у меня можно было бы назвать эксперементальным - это аспекты. Многие другие языки выглядят гораздо более экспериментальными. Управление памятью - ручное. Конструкторов и деструкторов - нет. Возможно стоило бы добавить операторы для явного копирования и перемещения, но, мне кажется, в Си и без них хорошо. В любом случае, я не планирую реализовывать эти идеи.
Моё представление об идеальном системном языке программирования