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