Почему бизнес не жалуется/судится в РКН, Минцифры или Спортлото, что невозможно вести разработку?
Потому, что бизнесу это не мешает вести разработку.
А должно быть так. РКН ломает процессы бизнесу -> бизнес должен разбираться с государством.
Бизнес не хочет ни с кем разбираться и тем более с государством. Бизнесу проще предусмотреть возможности автономной работы. Отказоустойчивость бизнеса это база, даже для самого упоротого Кабан Кабаныча.
Примат работы и зарабатывания денег немного расстраивает. Это можно советовать вкатуну в 35+ лет, которому нужно максимально быстро восстановить денежный поток. Но школьнику/студенту советовать подобное это подрезать крылья, и обрекать на посредственное существование в мире программирования.
Но стоит перейти на Rust или Haskell — и появляются логические промахи: неправильная работа с заимствованием, пропущенные граничные случаи. Иногда модель просто не знает синтаксических изменений, вышедших после её обучения, и упускает новые возможности, даже идеально подходящие к задаче.
Ну нет же. LLMка запущенная в агентом режиме с обратной связью от компилятора и линтера почти не делает таких наивных ошибок. Она банально не отдаёт результат пока код не начнёт компилироваться, и не будут устранены все ворнинги линтера(если установлено такое условие).
На моей практике тот же CODEX пишет пишет почти идеально на Rust. Другое дело, что он как джин, который старается вывернуть против темя любую недосказанность в поставленной задаче. Но это уже скилл ишью.
Модель не может ответить на вопрос «корректен ли этот код» — у неё попросту нет инструмента для такого суждения.
Опять же, мне кажется более правильная абстракция это не наивная аппроксимация, а алгоритм мат. программирования. Где LLMка это "интеллектуальный" шаг оптимизатора, а компилятор, линтер, тесты и валидация человеком(работа в реальном мире) это оракул который говорит насколько мы хорошо решаем задачу.
В такой постановки я не вижу причин почему в случае значительного усиления первых трёх барьеров (компилятор, линтер, тесты) к человеку уже придёт задача валидации с которой он просто когнитивно не способен справится, и соответственно станет не нужен.
Да, есть недочёт в мапинке языков между источниками. Если FreePascal отнести к Delphi/Pascal, то последний перестанет исключаться из-за недостаточного упоминания в источниках. В след. версии исправлю.
А там в подвале написано: Sources: TIOBE, PYPL, Languish, Benchmarks Game. Ещё хочу добавить techempower и какой-нибудь LLM-frendly рейтинг типо MultiPL-E или HumanEval-X.
Мне надоел корявый TIOBE и низкая позиция Rust =). Поэтому я сделал свой агрегированный рейтинг с маджонгом и гейшами по методу голосования Шульце: langrank.hexq.ru (лежит на Cloudflare поэтому может понадобится VPN, репка)
Уже 3 года использую nightly версию для разработки петпроектов(https://github.com/hexqnt), и некоторых рабочих, и ни разу не было проблем с обратной совместимостью по компилятору. Даже переход с 2021 edition на 2024 не потребовал усилий. В 99% случаев если, что-то перестанет работать при обновлении компилятора, то оно вам об этом сообщит - скрытого отказа не будет.
Я пользуюсь Error Lens (или аналогами), и хочу видеть сообщения об ошибка/ворнингах сразу при вводе кода. Зачем пользоваться медленным ПО когда можно пользоваться быстрым?)
По мотивам вашей сводной таблицы В Rust порядок вычисленя аргументов слева на право. Ваш пример f(x++, x) в Rust либо не валиден если x ссылка (невозможно единовременно иметь мутабельную и немутабельную или две мутабельные ссылки на одну переменную) или будет две копии, которые будут вычисляться слева на право, но потом в LLVM их порядок вычисление может быть оптимизирован(если не меняет наблюдаемое поведение программы).
Как вы ошибку сделанную в unsafe блоке собираетесь исправлять в safe коде?) Вы путаете место проявления ошибки и собвстенно место где эта ошибка допущена.
Это какой-то кочующий из комента в комент миф про сложность написания односвязные/двусвязных списков на Rust. В unsafe Rust они пишутся также как в С/С++ просто с чуть большим "ритуальным бойлерплейтом" (который в хорошей реализации списков на С/С++ тоже будет).
Потому, что бизнесу это не мешает вести разработку.
Бизнес не хочет ни с кем разбираться и тем более с государством. Бизнесу проще предусмотреть возможности автономной работы. Отказоустойчивость бизнеса это база, даже для самого упоротого Кабан Кабаныча.
Примат работы и зарабатывания денег немного расстраивает. Это можно советовать вкатуну в 35+ лет, которому нужно максимально быстро восстановить денежный поток. Но школьнику/студенту советовать подобное это подрезать крылья, и обрекать на посредственное существование в мире программирования.
Ну нет же. LLMка запущенная в агентом режиме с обратной связью от компилятора и линтера почти не делает таких наивных ошибок. Она банально не отдаёт результат пока код не начнёт компилироваться, и не будут устранены все ворнинги линтера(если установлено такое условие).
На моей практике тот же CODEX пишет пишет почти идеально на Rust. Другое дело, что он как джин, который старается вывернуть против темя любую недосказанность в поставленной задаче. Но это уже скилл ишью.
Опять же, мне кажется более правильная абстракция это не наивная аппроксимация, а алгоритм мат. программирования. Где LLMка это "интеллектуальный" шаг оптимизатора, а компилятор, линтер, тесты и валидация человеком(работа в реальном мире) это оракул который говорит насколько мы хорошо решаем задачу.
В такой постановки я не вижу причин почему в случае значительного усиления первых трёх барьеров (компилятор, линтер, тесты) к человеку уже придёт задача валидации с которой он просто когнитивно не способен справится, и соответственно станет не нужен.
А разве агентный LLM не уровнял все языки в тайм-ту-маркет? У меня LLMка одно и тоже время тратит на фичу в Python и в Rust. ┐( ˘_˘ )┌
Да, есть недочёт в мапинке языков между источниками. Если FreePascal отнести к Delphi/Pascal, то последний перестанет исключаться из-за недостаточного упоминания в источниках. В след. версии исправлю.
А там в подвале написано: Sources: TIOBE, PYPL, Languish, Benchmarks Game. Ещё хочу добавить techempower и какой-нибудь LLM-frendly рейтинг типо MultiPL-E или HumanEval-X.
Мне надоел корявый TIOBE и низкая позиция Rust =). Поэтому я сделал свой агрегированный рейтинг
с маджонгом и гейшамипо методу голосования Шульце: langrank.hexq.ru (лежит на Cloudflare поэтому может понадобится VPN, репка)Уже 3 года использую
nightlyверсию для разработки петпроектов(https://github.com/hexqnt), и некоторых рабочих, и ни разу не было проблем с обратной совместимостью по компилятору. Даже переход с 2021 edition на 2024 не потребовал усилий. В 99% случаев если, что-то перестанет работать при обновлении компилятора, то оно вам об этом сообщит - скрытого отказа не будет.Сказано же ERA5, можно спокойно скачать с https://cds.climate.copernicus.eu/datasets/reanalysis-era5-land?tab=overview
Я пользуюсь Error Lens (или аналогами), и хочу видеть сообщения об ошибка/ворнингах сразу при вводе кода. Зачем пользоваться медленным ПО когда можно пользоваться быстрым?)
По мотивам вашей сводной таблицы
В Rust порядок вычисленя аргументов слева на право. Ваш пример
f(x++, x)в Rust либо не валиден еслиxссылка (невозможно единовременно иметь мутабельную и немутабельную или две мутабельные ссылки на одну переменную) или будет две копии, которые будут вычисляться слева на право, но потом в LLVM их порядок вычисление может быть оптимизирован(если не меняет наблюдаемое поведение программы).Как вы ошибку сделанную в unsafe блоке собираетесь исправлять в safe коде?) Вы путаете место проявления ошибки и собвстенно место где эта ошибка допущена.
Это какой-то кочующий из комента в комент миф про сложность написания односвязные/двусвязных списков на Rust. В unsafe Rust они пишутся также как в С/С++ просто с чуть большим "ритуальным бойлерплейтом" (который в хорошей реализации списков на С/С++ тоже будет).
Юмор это тащить пол гигабайта окружение и занимать в памяти сотни мегабайт, чтобы дёрнуть api =)