Чем, по вашему мнению, является язык программирования Rust в 2026 году?

Какие-то слишком простые «приложухи». Наверно, их и на C++ левой пяткой без ошибок написать можно.

Сначала хотел написать, что надо было к строке приводить. Но потом подумалось: с хрена ли порядок вызовов должен меняться? Он определён, слева направо.

Можно и на C++, че нет-то, когда да?

Ява/сишарп он тоже не заменит, потому что его главный козырь - лучшая безопасность памяти - не срабатывает. Ява/сишарп уже десятилетиями именно поэтому и выбирают и именно поэтому они смогли уже отъесть свой кусок у с++.

Если у тебя половина программы на Си++, а половина на Яве, то приходится жутко извращаться переводя одни классы в другие. Если же у тебя половина на небезопасном Расте, а половина на безопасном, то всё доступно сразу.

Если программа целиком на Си++ или целиком на Яве, выигрыша от перевода на Раст практически нет.

без обид - полистай HOPL I II III IV

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

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

фактически ща за счёт эффекта широкой базы и в целом большей вовлечённости с детства среди кодеров шире привычные навыки - в отличии от дедовских «битв за каждый байт»

прикол именно в том что именно по причине экономическим качество массовых языков программирования снижается ибо это не академия а массовое производство

дык Сяшка всегда среднеуровневый переносимый(в смысле что все процы по сути достаточно одинаковы что бы транслятор структур исполнения в опкоды целевой машины было бы не сложно) асм был

другие среднеуровневые языки отчего то вымерли али остались в очень обособленных ареалах обитания

но заменить C, по моему мнению, он в полной мере не в состоянии.

Так уже меняет. АМД внедряет, Невидия тоже хочет, Гугл в полный рост в андроид тащит, в ядре Rust уже вполне всерьёз. Так что вопрос скорее где Си пока ещё не получается заменить?

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

А в современном мире чаще всего требуется писать сложные программы, а сложную логику проще писать на Rust'е. При этом сложно не заметить Borrow Checker.

способом отъема открытого инструментария из рук кибер-трудящихся

в смысле что все процы по сути достаточно одинаковы что бы транслятор структур исполнения в опкоды целевой машины было бы не сложно

Процессоры как раз могут сильно отличаться: ISA, модель памяти, набор регистров, векторные расширения, порядок байт, атомики, правила выравнивания и бог знает что там еще.

В чем именно Си более «ассемлерный» по сравнению с Rust? Что в нем есть такого, что позволяет его называть «переносимым ассемблером»? И почему это он вдруг стал переносимым асмом, когда у него своя абстрактная машина, типы, правила aliasing, lifetime объектов и UB, а компилятор волен генерировать что угодно, лишь бы сохранить семантику языка? В чем отличие от любого другого языка тогда? От Zig, от Rust, от тех же C++?

Ты гонишь, полно там Сишки, копать-неперекопать.

Ой да ладно! Сложные программы? Давно ты LSM дерево обрабатывал? Или пытался обойти CAP в большом кластере? Большинство кода это примитивное: достать структуру из базы или из POST, немного переделать по детерминированной бизнес логике, передать дальше.

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

Ну да, еще Сократ говорил, что нынче молодежь не та. Когнитивные способности слабо корелируют с инструментом, поскольку сложные вопросы возникают с использованием любого языка и платформы. Что касается дедовских битв за байт, то в ряде случаев они вполне себе на месте (в том числе и на Rust), но ограничены рынком: в большинстве случаев нет экономической необходимости с этим возиться.

Сцуко! Почему все думаю, что на ASM писать сложнее? Это довольно просто, хоть и медленно.

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

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

и оставляя в стороне нюансы возможной идиократии факт буквальный что сейчас снижаються эдак последнии века полтора массовые критерии к объёму матана который достаточен для получения аттестата зрелости ;)

ибо именно благодаря массовому прогрессу в технологиях снижаются требования их пользователям :)

Да. Все это есть.

Там все просто: в режиме unsafe Rust - это просто Си. Без unsafe - Си без возможности разыменовать левый указатель. В обоих режимах добавлена крутая система типов (похожая на Haskell), но кому она не нравится, могут не пользоваться.

Ну так я об этом и говорю. Ты сам сейчас описал 90% индустрии как «достать из базы и передать дальше». Это простые программы, для которых Rust и Borrow Checker избыточны.

На Rust'е пишут совсем другой класс программ. Такие как jless, eza, yazi, fish 4, Wezterm, Niri, ripgrep, bat, bottom, difftastic, git-delta, bookokrat, elio, helix,... и т.д.

Конечно, на Rust'е можно писать программы и попроще, тем более если программисту так удобнее. Но в этих случаях Borrow Checker, действительно, можно и не заметить.

А вот в задаче «достать структуру из БД» Rust рулит за счет плагинов компилятора. Ты просто описываешь struct, и она УЖЕ досталась из БД, без единой строчки кода.

Я в том плане, что он позволяет решать те же задачи, что и Java / C#, получая на выходе более эффективное решение. Так-то понятно, что писать на этих языках в разы проще и удобней.

Чёт пост, полный брехни. Есть и governance, и RFC, и всякие ответственные команды, принимающие решения, даже фаундейшен есть.

Так это и есть базарная модель. Базар - это не анархия, а децентрализованное открытое сообщество, в котором решения принимаются через обсуждение и одобрение большинством авторитетных участников.

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

Путаете язык и инфраструктуру. Инфраструктура, на мой взгляд, у Rust неудачная, но это проблема не его, а современной модели разработки ПО вообще, потому что точно так же ситуация обстоит и с NPM, и с pip, и со всем остальным. Недостатком языка я это не считаю.

Нет. Жава и шарпы построены на сборщике мусора, они на порядок проще чем любой язык с ручным / прекомпилированным контролем памяти.

Опять подмена понятий. Если следовать подобной логике, то Rust на много порядков сложнее C и абсолютно точно не может быть его заменой. Я же имел в виду, что Rust великолепно подходит для тех задач, для которых создавались Java и C#, позволяя получать на выходе заметно более эффективные решения.

Бывает, с другими ЯП поддерживающими ООП, но почти везде оверхед больше чем у C++. Множественное наследование зло и пользоваться им в C++ плохо (обычное нормально). Но судя по всему у раста таки не бывает (ни одной игры и нормального GUI фреймворка на нём нет, а значит проблема таки в его ООП, которого нет. На СИ тоже можно ООП пытаться городить, GTK так и делает, да и в ядре линукса тоже, но это не настоящий ООП).

Хорошо что тебя настоящие системы не пускают разрабатывать. А у РКН ТСПУ программируй как хочешь.

Java и C# намного лучше

Да, это так. Но не везде виртуальная машина годится.

все стараются уйти от OOP в пользу DOD

Очередная мода, не более. А некоторым людям всё же надо работу работать. Тем более DOD и с OOP вполне себе нормально работает, это не взаимоисключаемые сущности, как думают некоторые дурачки с двумя-тремя извилинами.

многосортные алгебы :( на ООП

[libastral]
Наоборот, HKT эмулируемый на OOP это гораздо большее зло для DOD, чем голый OOP
[/libastral]

Очень спорное утверждение. Как считать эффективность. Рантайм? Если мы говорим о десктопном приложении, которое большую часть времени ждет ответа пользователя, то прирост эффективности будет околонулевой. Эффективность разработки при этом упадет.

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

многосортные алгебы

Многосортные алгебры это АТД, а АТД это основа ООП. Реляционные СУБД это тоже многосортные алгебры. Давай поглядим, на чём же такие СУБД написаны?

Postgreesql пожалуй единственная БД на C, где выбрали C не из соображений (надо для совместимости и встраивания, что актуально для sqlite). Всё, остальное написано на C++, Java, C#, т.е. ООП во все поля.

Нет. Он не все проверки выключает.

Как в ржавом рефакторинг делают? Есть у него элегантные методы написания гуя или это очередной GTK ООП?

Множественное наследование есть? Или всё костылять через композицию? Так посмотреть яп сделан для защиты [s]олимпиадников[/s] школоты выстрелить себе в ногу. Они же не смогут отличить, где нужна композция, а где множественное наследование. Давайте запретим ООП и множественное наследование. Чтобы детки лоб не расшибли.

Кто-нибудь сделает яп для работы? Или слишком мелкий рынок, экономически не выгодно?

• В Rust рефакторинг делается нормально, и во многом лучше, чем в динамических языках. Те же «cargo fix» и «cargo clippy --fix» автоматически правят множество вещей.
• GUI в Rust пока объективно слабее, чем в C#/Java/JS, однако есть поддержка таких тулкитов как egui, iced, slint, Dioxus, Tauri, Qt и GTK.
• Множественного наследования классов в Rust нет, как и в Java, C#, Kotlin, Swift. Вместо этого - трейты и композиция.
• Rust используется в продакшене: Cloudflare, AWS (Firecracker), Dropbox, Discord, Meta, Microsoft (Windows-компоненты), Linux kernel, Android.

Те же «cargo fix» и «cargo clippy –fix» автоматически правят множество вещей

Сразу видно человека не понимающего о чём идёт речь. Я не удивлён.

как и в Java, C#, Kotlin, Swift

Перечисление очередного УГ. Впрочем, некоторым из этого списка можно простить, что они угэ. Так сказать ветераны индустрии всё-таки.

Rust используется в продакшене

А если Петька в колодец прыгнет, ты тоже за ним?

А если Петька в колодец прыгнет, ты тоже за ним?

Да, таковы тенденции в вайбкодинге :)

Есть у него элегантные методы написания гуя или это очередной GTK ООП?

Вроде, есть Qt ООП.

Rust выбирают за его сильные стороны. Впрочем, если кто-то их не видит или не осилил, то это не проблема Rust'а.

Lisp и Python тоже далеко не все сразу оценили, продолжая писать на Фортране, Перле и C/C++. История порой то и дело повторяется.

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

Допустим есть задача, для которой точно известно, что имеются библиотеки на языке Си. И у нас стоит выбор - раст, или си++. Что делать в си++ -совершенно понятно. По идее -понятно и в раст. Это всякие томл, билд и, наконец extern в коде (вместо простого ifdef, а там и cmake разьерется). Но что делать, если мы имеем дело с достаточно большим и общирным фреймворком на си, который еще и надо с cmake собирать отдельно? А если в этом фреймворке для каждой его библиотеки еще и свой, отдельный cmake? А что делать если, к примеру, в том-же фреймворке идет динамическая замена системных библиотек вроде подстановки собственной версии time.h вместо системной? Как раст разбирается со случаеми, когда мы в 1 проекте используем 2 разные библиотеки на Си (или си++ - тут не важно), у которых есть 2 одинаковых h файла?

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

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

Что такого Си может чего Rust не может? Спрашиваю как человек, который программировал на двух языках и в том числе контроллеры.

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

я правильно понимаю, что твои программы для микроконтроллеров на раст пестрили конструкциями вроде unsafe? И, если нет, то хоть скажи, что они тогда делали :)

Вопрос не в том, что один язык может, а чего он не может. Вопрос в том, на каком уровне он это может. потому как вопрос: «Что такого Си может чего Rust не может?» можно и перефроазировать: «Что такого ассемблер может, чего си не может» :)

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

Уточнил формулировку вопроса, чтобы было понятно, что речь именно про ЯП, а не про игру.

«…с М. А. Берлиозом, впоследствии покойным…». И это не удовлетворило автора. Пришлось применить третью редакцию, а та оказалась еще хуже первых двух: «…Берлиозом, который попал под трамвай…» — а здесь еще прицепился этот никому не известный композитор-однофамилец, и пришлось вписать: «…не композитором…»

я правильно понимаю, что твои программы для микроконтроллеров на раст пестрили конструкциями вроде unsafe? И, если нет, то хоть скажи, что они тогда делали :)

Конечно с ним, НО! Ты например маппишь структуру на память по указателю внутри unsafe, а дальше то работаешь в safe и не мучаешься часами ища баги, которые rust не допускает. Все unsafe можно хранить в одном месте - HAL. А если HAL готовый от сообщества, то в целом пишешь только safe код. И если что-то сломалось, то оно в одном месте, а не размазано по проекту. Он тупо удобнее Си ИМХО. И да в рантайме можно сделать так что Си будет давать те же гарантии безопасности, что и Раст, НО нет статических гарантий безопасности. Даже если ты будешь с Си использовать статанализатор, то там будет эвристика, а не 100% гарантия на уровне компиляции.

Это как у моего пожилого родственника, есть пассат б3 1991 года, ездит без проблем, кушает топлива мало, запчасти дешевые. А у другого родственника новая современная машина. Могут обе машины решать задачи? Да. Будет новая удобнее? Да. Есть плюсы в старой? Да. Но нет смысла сейчас покупать авто 1991 года. Так я и ощущаю разработку на Си

А по существую имею заявить, что раст бессмысленно сравнивать с:

• C, вся суть которого – работа с raw памятью (тут сошлюсь на Линуса нашего Торвальдса), это ассемблер на стероидах.

• C++, т.к. в расте нет ни полноценного ООП, ни исключений, убожество какое-то. «Раст ничего не проверяет, он просто ограничивает возможности.» (c) (linux.org.ru). И к слову, в современном C++ вполне себе можно в безопасную работу с памятью вообще без проблем – достаточно писать на нём в идиоматическом прикладном стиле.

• жавой – по той же причине, что и с C++: ни ООП, ни исключений.

В общем, просто ещё один недо-язык. (Мало ли их было.) Лично мне нафиг не нужный, т.к. лично для меня он ничего нового-существенного не привносит, а привычных удобств лишает.

ни одной игры

с чего бы? есть

потому что приоритет у индексации и постфиксного инкремента одинаковый.

Нет, не поэтому, а потому что в операторе присваивания не специфицировано, что считается первым: rvalue справа, или адрес переменной слева.

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

Но ты забываешь еще один момент, который, как раз и связан с тем самым «удобством», про которое ты писал. Это просто тонны кода библиотек на си. Я вот чуть выше позадавал несколько вполне конкретных рабочих вопросов, касающихся именно этих аспектов. И - тишина, как на кладбище.

тем не менее, у меня вопрос. что делать в таких вот случаях? переписывать? тратить кучу времени на то, чтоб переписать то, что совершенно точно и четко работает годами, только ради того, чтоб было «модно молодежно»? А кто будет за это платить? Ты примерно прикидывал, во сколько реальных денег обойдется переписывание библиотеки на си (которая стоит заметить и так работает защшибись) на раст? А потом ее сопровождение? А если разработчики раст, как то утром решать что-то «подправить»? Это не риторические - это рабочие обычные вопросы. В случае с разными диалектами Си\Си++ я просто могу определить - каким стандартом я пользуюсь - и все. это просто. а что с раст?

теперь про автомобили. и сравнение с яп. понимаешь. вот есть бентли… ему, к примеру, уже лет 20. и есть новая киа. с конвеера. угадай - где комфортнее и больше наворотов, не говоря уже про надежность? :)

А кого они переписали?

так она на расте изначально написана

- Единственный язык кроме Ada, который относится к проблеме алиасинга всерьёз
- Язык с интересным ресёрчем вокруг него (см. работы на https://iris-project.org/)
- Язык с немалым количеством проблем, включая таки экосистему пакетов
- Язык, на котором вполне можно программировать вместо того, чтобы брать сишку или плюсы
- И да, таки рабочий инструмент

тем не менее, у меня вопрос. что делать в таких вот случаях? переписывать?

Когда я начинал программировать на Rust где-то в 2018-м, экосистема действительно была очень сырой и найти подходящую либу было достаточно сложно. Сейчас спустя 8 лет ситуация стала значительно лучше. Но сколько расту лет? 15? А сколько лет С++? 43? Естественно, что приходиться мириться с биндингами и всякими врапперами вокруг С\С++ библиотек. Часть вещей переписывают на раст всякие коммюнити и ситуация становится еще лучше. Но я бы не ожидал в ближайшие 10-15 лет полного отказа от биндингов С++. И да, это косвенно влияет на безопасность программ снижая гарантии до возможностей С\С++ кода.

Но с другой стороны, а где Rust не догнал С++ по библиотекам? HPC и научные вычисления, игры, GUI. По сравнению с Си ситуация еще лучше для Rust, там отставания только касательно ядер ОС и специфичных либ для всякого старья.

Но вот хороший пример КМК переписывания на раст - это rgrep, значительно быстрее grep и архитектурно лучше.

Я бы точно не назвал Си - бентли =) У Вас видимо какая-то особенная любовь? Или боязнь отказаться от него?

Фреймворки определяют языки. Хотите фреймворк для C++ - пишите на C++ и не заморачивайтесь. Rust для других задач.