Transcription
Меня зовут Дэниел Зук. Я, э-э, мейнтейнер Rust SDK в Sentry, и я хочу рассказать вам, почему я считаю Rust идеальным языком для "vibe coding". Итак, общепринятое мнение о том, какой язык использовать для агентного кодинга или "vibe coding", как бы вы это ни называли, э-э, Rust, вероятно, не является одной из первых вещей, о которых вы думаете. Э-э, вы знаете, возможно, вы думаете, что, знаете, вероятно, ChatGPT имеет хорошее представление о том, какой лучший язык для агентного кодинга, учитывая, что он сам является своего рода агентом. И он бы сказал вам, что нет единого языка номер один, э-э, но что Python, вероятно, является лучшим языком, э-э, а сильным номером два, как он сказал, JavaScript и TypeScript, когда я его спросил. Э-э, и я думаю, что это, по крайней мере, по моему опыту, довольно верно, хотя я бы поменял порядок, потому что, э-э, TypeScript, кажется, стал лучшим выбором для агентного кодинга в последнее время. И, э-э, даже есть эта статья с GitHub, которая вышла, я полагаю, в конце прошлого года, и в ней говорится, что ИИ, как они думают, подтолкнул TypeScript к первому месту э-э среди языков на GitHub по количеству контрибьюторов, по крайней мере. Э-э, так что они знают, что TypeScript — это язык номер один, и они сильно подозревают, что это связано с тем, что люди используют его для разработки с помощью ИИ. Но почему эти языки, Python, TypeScript, JavaScript, так идеальны для "vibe coding"? Э-э, по крайней мере, согласно этому, своего рода общепринятому мнению. Итак, прежде всего, это распространенные и знакомые языки. Э-э, так что это, это, это обычно языки, которые вы бы изучали, если бы начинали программировать с нуля. Так что они легки для людей, и они также кажутся легкими для LLM. Существует также множество фреймворков, библиотек и примеров. Э-э, так что это полезно, если вы создаете что-то новое с нуля, конечно, вы можете строить на основе чего-то. И знаете, это полезно для людей, это также полезно для агентов. Они быстро создаются и запускаются. Это динамические языки. Они интерпретируемые, по крайней мере, JavaScript и Python. TypeScript, возможно, есть какая-то легкая компиляция в JavaScript или что-то в этом роде, но довольно легко просто запустить его и посмотреть, что он делает, а затем итерировать на этом. И, э-э, особенно для агентов, поддержка типизации полезна, чтобы агент не злоупотреблял типами. Э-э, но, э-э, да, есть тип "any", который немного подрывает это в TypeScript и типизированном Python, но, знаете, в целом, эти языки, LLM, сами модели довольно хорошо выводят исполняемый код с первой попытки, потому что эти языки просты, э-э, и они налагают мало ограничений. Так что я думаю, что из-за того, что LLM просто хорошо пишут на них, люди переходят на эти языки. Э-э, но я думаю, что многие люди, по моему опыту, не задаются вопросом, хотим ли мы вообще оптимизировать это, верно? Э-э, классические языки "vibe coding" легко писать для моделей, но хорошо ли это вообще? Мой аргумент заключается в том, что важность того, чтобы языку было легко писать для модели, преувеличена. На самом деле, я бы даже сказал, что в некоторых случаях плохо, что эти языки легко писать для моделей. Э-э, динамичная и гибкая природа языков — это то, что делает его легким для агента или для LLM, я должен сказать, для написания JavaScript, Python, TypeScript. Э-э, но эта же гибкость также делает его очень легким для совершения ошибок. Иногда даже очевидных ошибок, иногда менее очевидных ошибок. Добавление типизации — это полезное ограничение, но оно помогает лишь до определенной степени, э-э, потому что оно дает вам только типовую безопасность, и к тому же это не очень сильная типовая безопасность, э-э, в TypeScript или Python. И это, конечно, проблема, потому что LLM подвержены ошибкам. Они всегда будут подвержены ошибкам, потому что они по своей природе недетерминированные системы. Так что, надеюсь, в будущем они станут лучше совершать ошибки реже, но я не думаю, что это когда-либо исчезнет полностью. И поэтому, так же, как самые умные люди совершают ошибки, и нам нужно защищаться от человеческих ошибок, нам также придется защищаться от ошибок LLM. Один из способов, которым люди часто это делают, особенно в традиционных языках "vibe coding", — это добавление тестов. Это огромная помощь, но есть много проблем с тем, чтобы полагаться только на тесты и агентов для проверки кода. Во-первых, знаете, если вы не умеете составлять запросы для агента, он часто пишет тесты после реализации, и тогда вы просто тестируете детали реализации, не тестируя поведение должным образом. Даже с разработкой, управляемой тестами, тесты обычно могут доказать некорректность только тогда, когда они не проходят, потому что практически невозможно протестировать каждую возможную комбинацию входных данных. Во многих случаях вы не можете доказать, что каждый ввод дает правильный вывод. И, конечно, если LLM генерируют тесты, они могут совершать ошибки при написании этих тестов, и то же самое относится к агентам для проверки кода. А затем, скорее на философском уровне, верно? Мы все знаем, что AI означает искусственный интеллект, но есть эта книга под названием Nexus, которую я недавно прочитал, и я очень рекомендую ее всем, кто еще не читал. Она от автора Юваля Ноя Харари. Он историк, и у него есть своего рода уникальный взгляд на искусственный интеллект. Так он обсуждает человеческие информационные сети, начиная с каменного века, через книгопечатание, интернет и до нынешних LLM, верно? Э-э, и он считает, что LLM уникальны, потому что это первый раз, когда у нас есть что-то нечеловеческое, способное производить человеческий язык. И, э-э, один момент, который он приводит и который действительно запомнился мне, это то, что ему не нравится, что A в AI означает "artificial" (искусственный), потому что это преуменьшает, насколько LLM и другие технологии ИИ отличаются от того, как думают люди, и на самом деле он предпочитает называть это "alien intelligence" (инопланетный интеллект). Э-э, потому что внутренние механизмы их мышления на низком уровне отличаются от нашего. LLM предсказывают токены, которые поступают в потоках, и это очень мощный механизм мышления, но это не то, как мы думаем. И мой вывод здесь в том, что сбои могут быть совершенно неожиданными для нас. И я уверен, что если вы когда-либо кодили с помощью ИИ, у вас могла возникнуть ситуация, когда вы получили код, который выглядел очень хорошо. Возможно, у него были осмысленные имена переменных, хорошие комментарии и так далее. Но когда вы присмотритесь, что-то может быть не так. Например, может быть тонкий баг, или он может полагаться на какую-то эвристику, когда вы можете проверить фактическую вещь более надежно и в некоторых случаях проще. Так что вам действительно нужно быть осторожными с этим с э-э, разработкой на основе LLM и технологий агентов, верно? И это подводит меня к закону Мерфи, который гласит, что все, что может пойти не так, в конечном итоге пойдет не так, верно? Так что, если вы используете язык без детерминированных защитных механизмов, даже если вы применяете человеческую проверку, э-э, проверку агентом, хороший процесс тестирования, если у вас нет чего-то, что является абсолютным детерминированным барьером против этого, в конечном итоге у вас будут сбои. И в таких языках, как JavaScript, Python, TypeScript, где таких защитных механизмов часто не хватает, сбои будут происходить чаще, верно? Э-э, и это подводит меня к Rust, языку со множеством ограничений. Э-э, итак, для тех из вас, кто ничего не знает о Rust или не очень много о нем знает, немного базовой информации. Это компилируемый язык. Он разработан с учетом безопасности и производительности. Он стремится быть таким же быстрым, как C и C++, но при этом быть безопасным в плане памяти, типобезопасным, э-э, и, по сути, иметь такой строгий компилятор, что если код компилируется, вы можете быть достаточно уверены, что многие типы ошибок отсутствуют в вашем коде. Э-э, и это происходит потому, что компилятор обеспечивает соблюдение инвариантов, таких как типовая безопасность, безопасность памяти, параллелизм и т. д. Э-э, и язык старается быть очень дружелюбным к новичкам. Так что сам Rust, я думаю, люди, которые с ним не сталкивались, будут иметь такое представление, что он очень продвинутый, но они стараются сделать язык легким для изучения. Ошибки компилятора дают много информации о том, что пошло не так и как исправить проблему. И поэтому они предоставляют много контекста, и, конечно, это очень полезно, когда AI-агенты компилируют код Rust, сталкиваются с ошибкой и затем должны ее исправить. Итак, как я уже упоминал, в Rust есть много гарантий безопасности, верно? Э-э, первое, о чем стоит упомянуть, это то, что типовая безопасность строгая. Вы не можете обойти ее с помощью какого-либо типа "any" или непроверенного приведения. Нулевая безопасность — это еще одна большая вещь, если вы пришли из других языков. Нет универсального нулевого значения. Если вы хотите иметь опцию или тип, который может быть пустым, вы должны явно определить его как опциональный тип, и компилятор заставит вас всегда проверять, существует ли значение, прежде чем вы получите доступ к внутреннему значению. И бесстрашный параллелизм, который, я думаю, очень мощный, и он, по сути, означает, что компилятор Rust проверяет, если у вас есть какой-либо многопоточный код, что любые данные, которыми обмениваются потоки, делаются безопасным для потоков образом. И это лишь небольшой список. Есть так много других вещей, которые обеспечивает компилятор Rust, но я просто хочу привести вам быстрый пример бесстрашного параллелизма, потому что я думаю, что это действительно мощно. Итак, вот небольшой пример кода. По сути, у нас здесь счетчик, который начнется со значения ноль, и мы создадим здесь 100 потоков. Э-э, и каждый раз мы будем брать счетчик и добавлять единицу к этому внутреннему значению. Так что, когда все эти потоки завершатся, вы ожидаете, что значение будет 100. Теперь здесь есть проблема, а именно, что э-э, эти типы здесь предназначены для э-э, обмена изменяемыми данными, но только в пределах одного потока. Они не синхронизированы для э-э, безопасного доступа из нескольких потоков. Э-э, так что в языке, таком как TypeScript, что-то вроде этого может скомпилироваться, может запуститься, и тогда вы заметите проблему только тогда, когда время от времени будете получать значение, отличное от 100, верно? И это может быть, особенно если это небольшая часть в большом приложении, очень трудно отладить, где происходит эта гонка данных. Но в Rust это просто не компилируется. Вы получите ошибку компиляции, и она будет гласить: "Ошибка: Future не может быть безопасно отправлен между потоками. Э-э, этот future, так что этот маленький асинхронный блок здесь, э-э, не является send." А "send" означает только безопасный для отправки между потоками, и это не так. Так что эта ошибка не очень полезна, но если вы прокрутите вниз в сообщении об ошибке, оно объяснит дальше. И это то, что будет действительно полезно вашему AI-агенту, потому что оно говорит: "О, значение здесь, это значение счетчика, которое было захвачено, не является send. Оно имеет тип RC RefCell i32, и это не send." И поэтому, если ваш AI-агент, когда он просто компилирует ваш проект, получит эту ошибку компиляции, он сможет немедленно изменить это на потокобезопасный тип, которых в Rust предостаточно. Э-э, так что, конечно, все эти э-э, ограничения имеют свою цену. Rust сложнее для LLM получить правильно с первой попытки, потому что им нужно следовать так много правил. Но я думаю, что это хорошо. Э-э, это потому, что код пишут не только LLM. Мы помещаем LLM в AI-агента. Он находится в цикле. Он может делать вещи автономно. И AI-агенты очень хорошо подходят для того, чтобы компилировать свой код, проверять любые сбои, а затем идти и исправлять их. И каждая ошибка компиляции э-э, потенциально является багом, которого вы избегаете в своем производственном коде. Так что, э-э, и с компилятором Rust, как я иногда слышу, люди жалуются, что время компиляции медленное. Но я гарантирую вам, что это быстрее, чем позволить AI-агенту проверять ваш код, и он может даже не найти всех ошибок, которые гарантированно найдет компилятор Rust. Я все равно думаю, что вам следует использовать его, конечно, но хорошо иметь этот э-э, дополнительный элемент безопасности, я думаю. И, конечно, это спонсируемый доклад, и я из Sentry, так что это небольшой маркетинговый слайд. Э-э, вам стоит попробовать нас, если вы еще этого не сделали. Этот QR-код даст вам 3 месяца бесплатно нашего бизнес-плана. Э-э, у нас есть функции мониторинга агентов. У нас есть стенд внизу. Заходите. Не стесняйтесь задавать вопросы о Sentry, или если вы хотите поговорить со мной о докладе, вы также можете зайти, и я буду рад пообщаться. Спасибо.