Не понял, если просто добавить поле в структуру, то какое дублирование нужно? В метод конструктор в Self{} дописать поле?) И какие вы трейты собрались переписывать, когда в трейтах нельзя получить доступ к полю структуры?) Если вы имели ввиде переписывать имплементации, то это ничем не больше чем переписывать теже имплантации в любом ООП языке.
Да, это сторонняя библиотека, но там нет никакой магии и заковырок, всего 209 строчек кода. Работает она как раз за счёт того, что в Rust достаточно легко найти все места где может паниковать программа panic="unwind".
В расте есть такая же проблема, хоть и в меньшей степени. Вызываемая функция может неожиданно запаниковать, как я уже выше писал.
Это не совсем так, #[no_panic] может в рамках крейта доказывать, что указанная функции не паникует. А при сборке с LTO, и с учётом других крейтов (транзитивно).
Ну так не интересно, можно что угодно сделать безопасным если приложить достаточное количество усилий для безопасной эксплуатации этого.
Наверное всё же правильно говорить про базовый уровень безопасности - тот уровень который обеспечивается без вложения сил.
И если вы спорите с тезисом "C++ - самый небезопасный язык" то назовите какой язык из мейнстримных ещё более небезопасен? Если такого нет, то по определению C++ - самый небезопасный язык.
У меня был доклад про перенос достаточно оптимизированного cpu-bound кода с Python на Rust. И там был вывод: что можно получить 5x ускорения за счёт 5x времени разработки. Сейчас же с топовыми LLM-ками я получаю 5x ускорение в среднем за $1.5, и почти нулевыми затратами времени.
Мой опыт согласуется с вашими выводами. В принципе тоже самое можно было бы получить и при переносе на C/C++, но к Rust как-то доверия больше =)
Понятное дело, что многие мажутся этим про-ai/анти-ai хайпом, чтобы выглядеть как белые люди заграницей. Мол типо у нас тоже проблемы белых людей.
Но ИМХО на отечественной земле я не вижу проблем с недооценкой/переоценкой возможностей AI. Какого-то вайб-кодинг кэнсалинга или жёсткой принудиловки программирования с AI. Всё достаточно ровно.
Используйте WiFi и проводное подключение к провайдеру — белые списки (официально) планируются как промежуточное решение чтобы не убить сервисы во время блокировок.
Ща разберутся с мобильным интернетом, и возьмутся за витую пару. Чтобы сгонять за новыми пакетами в npm нужно будет разовое разрешение получать %)
Не понятно вообще какие угрозы предотвращают эти белые списки, кроме как не дать Васюну смотреть какого-нибудь Каца.
Ну так ИИ это не просто LLMка, а цикл с обратной связью. Где LLMка делает шаг, а обратная связь говорит решена проблема на этом шаге или нет. По сути то чем сейчас являются ии-агенты.
Пока Rust отлично компилируется, и имеет хорошую локальную выпуклость в терминах мат. оптимизации =)
Ну СИ лучше чем машкоды или ассемблер. Потом нам понадобится статический анализатор, в качестве валидатора кода первого эшелона на каждой итерации агента.
А чтобы максимально глубоко анализировать код нужно писать этот код в рамках определённых правил, и ещё сохранять некоторую мета-информацию в названиях переменных/типов/комментариях. А, чтобы агент умел писать в таком стиле нужна кодовая база в таком стиле для обучения.
И если мы будем дальше развивать рассуждение то придём к Rust =)
Должен, но не может в виду стохастической природы как обучения так и инференса текущих алгоритмов ИИ. Поэтом от ошибок в ИИ-писателях вряд ли удастся избавится.
А писать в машинных кодах ИИ не будет в ближайшем будущем потому что:
Где вы возьмёте данные для обучения, которые бы стыковали естественный язык и куски машинного кода? В том же обобьём как это сейчас есть для ЯП.
Машинный код не кросплатформенный и его разновидностей больше чем языков программирования. Возможно генерировать какой-нибудь LLVM IR имело бы больше смысла.
Комбинаторное пространство валидных программ в машкодах значительно больше размера пространства полезных програм. В случае с ЯП пространство валидных программ ближе пространству полезных программ. Просто нет смысла работать в большем пространстве.
Для LLM не нужны большие кодовые базы какого-то языка. LLM сейчас отлично обобщает, и достаточно кодовой базы, которая показывала бы нюансы использования языка. И то только в том случае если язык привносит какие-то до селе невиданные концепции.
Основная проблема создания новых языков, то что они должны решать проблему, которую другие языки не решают. Наличие нескучного синтаксиса как было раньше уже недостаточно.
Например Rust, с точки зрения ai-кодинга предоставляет: компилируемость, безопасность по памяти, потокобезопасность, отсутствие тяжёлого рантайма(GC) и zero-cost абстракции. Новый язык должен предоставлять всё это и ещё что-то сверху, иначе зачем он нужен?
Почему бизнес не жалуется/судится в РКН, Минцифры или Спортлото, что невозможно вести разработку?
Потому, что бизнесу это не мешает вести разработку.
А должно быть так. РКН ломает процессы бизнесу -> бизнес должен разбираться с государством.
Бизнес не хочет ни с кем разбираться и тем более с государством. Бизнесу проще предусмотреть возможности автономной работы. Отказоустойчивость бизнеса это база, даже для самого упоротого Кабан Кабаныча.
Примат работы и зарабатывания денег немного расстраивает. Это можно советовать вкатуну в 35+ лет, которому нужно максимально быстро восстановить денежный поток. Но школьнику/студенту советовать подобное это подрезать крылья, и обрекать на посредственное существование в мире программирования.
Но стоит перейти на Rust или Haskell — и появляются логические промахи: неправильная работа с заимствованием, пропущенные граничные случаи. Иногда модель просто не знает синтаксических изменений, вышедших после её обучения, и упускает новые возможности, даже идеально подходящие к задаче.
Ну нет же. LLMка запущенная в агентом режиме с обратной связью от компилятора и линтера почти не делает таких наивных ошибок. Она банально не отдаёт результат пока код не начнёт компилироваться, и не будут устранены все ворнинги линтера(если установлено такое условие).
На моей практике тот же CODEX пишет пишет почти идеально на Rust. Другое дело, что он как джин, который старается вывернуть против темя любую недосказанность в поставленной задаче. Но это уже скилл ишью.
Модель не может ответить на вопрос «корректен ли этот код» — у неё попросту нет инструмента для такого суждения.
Опять же, мне кажется более правильная абстракция это не наивная аппроксимация, а алгоритм мат. программирования. Где LLMка это "интеллектуальный" шаг оптимизатора, а компилятор, линтер, тесты и валидация человеком(работа в реальном мире) это оракул который говорит насколько мы хорошо решаем задачу.
В такой постановки я не вижу причин почему в случае значительного усиления первых трёх барьеров (компилятор, линтер, тесты) к человеку уже придёт задача валидации с которой он просто когнитивно не способен справится, и соответственно станет не нужен.
Да, есть недочёт в мапинке языков между источниками. Если FreePascal отнести к Delphi/Pascal, то последний перестанет исключаться из-за недостаточного упоминания в источниках. В след. версии исправлю.
Не понял, если просто добавить поле в структуру, то какое дублирование нужно? В метод конструктор в
Self{}дописать поле?)И какие вы трейты собрались переписывать, когда в трейтах нельзя получить доступ к полю структуры?) Если вы имели ввиде переписывать имплементации, то это ничем не больше чем переписывать теже имплантации в любом ООП языке.
И где же тут Rust будет медленнее? В худшем случае будет одинаковая производительность.
Да, это сторонняя библиотека, но там нет никакой магии и заковырок, всего 209 строчек кода. Работает она как раз за счёт того, что в Rust достаточно легко найти все места где может паниковать программа
panic="unwind".Это не совсем так,
#[no_panic]может в рамках крейта доказывать, что указанная функции не паникует. А при сборке сLTO, и с учётом других крейтов (транзитивно).Citation needed.
Лучше сказать, что выполняешь "просьбу" и "выполнять" просьбу.
Ну так не интересно, можно что угодно сделать безопасным если приложить достаточное количество усилий для безопасной эксплуатации этого.
Наверное всё же правильно говорить про базовый уровень безопасности - тот уровень который обеспечивается без вложения сил.
И если вы спорите с тезисом "C++ - самый небезопасный язык" то назовите какой язык из мейнстримных ещё более небезопасен? Если такого нет, то по определению C++ - самый небезопасный язык.
У меня был доклад про перенос достаточно оптимизированного cpu-bound кода с Python на Rust. И там был вывод: что можно получить 5x ускорения за счёт 5x времени разработки. Сейчас же с топовыми LLM-ками я получаю 5x ускорение в среднем за $1.5, и почти нулевыми затратами времени.
Мой опыт согласуется с вашими выводами. В принципе тоже самое можно было бы получить и при переносе на C/C++, но к Rust как-то доверия больше =)
Понятное дело, что многие мажутся этим про-ai/анти-ai хайпом, чтобы выглядеть как белые люди заграницей. Мол типо у нас тоже проблемы белых людей.
Но ИМХО на отечественной земле я не вижу проблем с недооценкой/переоценкой возможностей AI. Какого-то вайб-кодинг кэнсалинга или жёсткой принудиловки программирования с AI. Всё достаточно ровно.
Это всё больше похоже на какую-то БЛМ тряску.
Ща разберутся с мобильным интернетом, и возьмутся за витую пару. Чтобы сгонять за новыми пакетами в npm нужно будет разовое разрешение получать %)
Не понятно вообще какие угрозы предотвращают эти белые списки, кроме как не дать Васюну смотреть какого-нибудь Каца.
Для начала можно просто не брать языки и их фреймворки из правкой части диаграммы =)
Ну так ИИ это не просто LLMка, а цикл с обратной связью. Где LLMка делает шаг, а обратная связь говорит решена проблема на этом шаге или нет. По сути то чем сейчас являются ии-агенты.
Пока Rust отлично компилируется, и имеет хорошую локальную выпуклость в терминах мат. оптимизации =)
Ну СИ лучше чем машкоды или ассемблер. Потом нам понадобится статический анализатор, в качестве валидатора кода первого эшелона на каждой итерации агента.
А чтобы максимально глубоко анализировать код нужно писать этот код в рамках определённых правил, и ещё сохранять некоторую мета-информацию в названиях переменных/типов/комментариях. А, чтобы агент умел писать в таком стиле нужна кодовая база в таком стиле для обучения.
И если мы будем дальше развивать рассуждение то придём к Rust =)
Должен, но не может в виду стохастической природы как обучения так и инференса текущих алгоритмов ИИ. Поэтом от ошибок в ИИ-писателях вряд ли удастся избавится.
А писать в машинных кодах ИИ не будет в ближайшем будущем потому что:
Где вы возьмёте данные для обучения, которые бы стыковали естественный язык и куски машинного кода? В том же обобьём как это сейчас есть для ЯП.
Машинный код не кросплатформенный и его разновидностей больше чем языков программирования. Возможно генерировать какой-нибудь LLVM IR имело бы больше смысла.
Комбинаторное пространство валидных программ в машкодах значительно больше размера пространства полезных програм. В случае с ЯП пространство валидных программ ближе пространству полезных программ. Просто нет смысла работать в большем пространстве.
Для LLM не нужны большие кодовые базы какого-то языка. LLM сейчас отлично обобщает, и достаточно кодовой базы, которая показывала бы нюансы использования языка. И то только в том случае если язык привносит какие-то до селе невиданные концепции.
Основная проблема создания новых языков, то что они должны решать проблему, которую другие языки не решают. Наличие нескучного синтаксиса как было раньше уже недостаточно.
Например Rust, с точки зрения ai-кодинга предоставляет: компилируемость, безопасность по памяти, потокобезопасность, отсутствие тяжёлого рантайма(GC) и zero-cost абстракции. Новый язык должен предоставлять всё это и ещё что-то сверху, иначе зачем он нужен?
Потому, что бизнесу это не мешает вести разработку.
Бизнес не хочет ни с кем разбираться и тем более с государством. Бизнесу проще предусмотреть возможности автономной работы. Отказоустойчивость бизнеса это база, даже для самого упоротого Кабан Кабаныча.
Примат работы и зарабатывания денег немного расстраивает. Это можно советовать вкатуну в 35+ лет, которому нужно максимально быстро восстановить денежный поток. Но школьнику/студенту советовать подобное это подрезать крылья, и обрекать на посредственное существование в мире программирования.
Ну нет же. LLMка запущенная в агентом режиме с обратной связью от компилятора и линтера почти не делает таких наивных ошибок. Она банально не отдаёт результат пока код не начнёт компилироваться, и не будут устранены все ворнинги линтера(если установлено такое условие).
На моей практике тот же CODEX пишет пишет почти идеально на Rust. Другое дело, что он как джин, который старается вывернуть против темя любую недосказанность в поставленной задаче. Но это уже скилл ишью.
Опять же, мне кажется более правильная абстракция это не наивная аппроксимация, а алгоритм мат. программирования. Где LLMка это "интеллектуальный" шаг оптимизатора, а компилятор, линтер, тесты и валидация человеком(работа в реальном мире) это оракул который говорит насколько мы хорошо решаем задачу.
В такой постановки я не вижу причин почему в случае значительного усиления первых трёх барьеров (компилятор, линтер, тесты) к человеку уже придёт задача валидации с которой он просто когнитивно не способен справится, и соответственно станет не нужен.
А разве агентный LLM не уровнял все языки в тайм-ту-маркет? У меня LLMка одно и тоже время тратит на фичу в Python и в Rust. ┐( ˘_˘ )┌
Да, есть недочёт в мапинке языков между источниками. Если FreePascal отнести к Delphi/Pascal, то последний перестанет исключаться из-за недостаточного упоминания в источниках. В след. версии исправлю.