Привет, разработчик! Я Данил Щуцкий (CutCode) backend PHP developer, одержимый своим делом! На этом канале публикую свои мысли и истории из личного опыта.
Youtube: https://www.youtube.com/@CutCodeRu
ЛС: @leeto_telegram
Post #109
1.12K
Rust язык будущего? Строгость побеждает?
Думаю, многим я уже успел надоесть с ИИ-разработкой, но я снимаю и пишу только о том, что со мной происходит прямо сейчас. Реальность такая, какая есть.
Небольшие наблюдения, которые я сделал при активной разработке с LLM. К сожалению, как фанат и адепт PHP, я всё чаще задумываюсь о выборе языка — и чуть позже вы поймёте почему.
Если планировать выбор стека вместе с LLM, то в 90% случаев вам предложат Python или JS, в крайнем случае — Go. В целом последние проекты у меня и варьировались в этом стеке. Если взять Python и JS (это касается и PHP), то, на мой взгляд, они НЕ подходят для работы с LLM, а LLM рекомендует их в первую очередь потому, что обучалась в основном на них. Но это гибкие языки со свободой, а значит — с непредсказуемыми сюрпризами в рантайме. Это боль. Сложная экосистема — тоже боль и лишний контекст.
Я не верю, что выживет язык, которому нужно сверху обмазаться кучей инструментов для проверки качества, создавая лишний шум в коде. Выживет язык с нативной строгостью, у которого в коробке есть весь набор инструментов для контроля качества и поведения.
Понимая это, я решил попробовать Rust. Зная его строгость и богатый набор инструментов «из коробки» — чуть меньше, чем у Go, но через Cargo добавить форматер и линтер проще некуда на старте конфигурирования. LLM меня отговаривала, но я протестировал теорию на двух проектах. Это нативные десктопные приложения: одно — набор серверов, на которых можно быстро воспроизводить готовые рецепты и ставить Docker, Git и прочий джентльменский набор; второе — приложение, которое воспроизводит воркфлоу дистилляции идеи с дальнейшим проходом по пайплайну и получением документации по системному дизайну, UI, оценке аудитории и всему, что требуется на старте (оба на скринах).
И знаете что? В процессе я не столкнулся ни с одним фиксом логики. Просто ноль. Язык строгий, и уже на уровне линтера и предварительной компиляции LLM видит все проблемы, фиксит их в цикле и выдаёт рабочий вариант.
Из проблем был только UI: неудобно делать скрины, закидывать их агенту и просить фиксить в цикле. Я уже ленив для такого, поэтому, не отходя от кассы, тоже на Rust написал MCP https://github.com/lee-to/peekscreen, который делает скрин окна приложения (можете юзать при разработке десктоп приложений). В итоге LLM в цикле не косячит по логике, сразу фиксит UI, перепроверяет себя — и я получил два работающих, аккуратных приложения.
Я никого не пытаюсь триггерить своими открытиями, просто делюсь мыслями в процессе. Возможно, они ещё изменятся, но это то, что происходит сейчас. Чему-то я радуюсь, а что-то меня немного пугает.
Ещё больше моих наблюдений и открытий о работе с LLM вы сможете увидеть и услышать на нашем с Олегом Мифле воркшопе — https://app.leadteh.ru/w/fnp4S.
Добро пожаловать в новый мир.
Думаю, многим я уже успел надоесть с ИИ-разработкой, но я снимаю и пишу только о том, что со мной происходит прямо сейчас. Реальность такая, какая есть.
Небольшие наблюдения, которые я сделал при активной разработке с LLM. К сожалению, как фанат и адепт PHP, я всё чаще задумываюсь о выборе языка — и чуть позже вы поймёте почему.
Если планировать выбор стека вместе с LLM, то в 90% случаев вам предложат Python или JS, в крайнем случае — Go. В целом последние проекты у меня и варьировались в этом стеке. Если взять Python и JS (это касается и PHP), то, на мой взгляд, они НЕ подходят для работы с LLM, а LLM рекомендует их в первую очередь потому, что обучалась в основном на них. Но это гибкие языки со свободой, а значит — с непредсказуемыми сюрпризами в рантайме. Это боль. Сложная экосистема — тоже боль и лишний контекст.
Я не верю, что выживет язык, которому нужно сверху обмазаться кучей инструментов для проверки качества, создавая лишний шум в коде. Выживет язык с нативной строгостью, у которого в коробке есть весь набор инструментов для контроля качества и поведения.
Понимая это, я решил попробовать Rust. Зная его строгость и богатый набор инструментов «из коробки» — чуть меньше, чем у Go, но через Cargo добавить форматер и линтер проще некуда на старте конфигурирования. LLM меня отговаривала, но я протестировал теорию на двух проектах. Это нативные десктопные приложения: одно — набор серверов, на которых можно быстро воспроизводить готовые рецепты и ставить Docker, Git и прочий джентльменский набор; второе — приложение, которое воспроизводит воркфлоу дистилляции идеи с дальнейшим проходом по пайплайну и получением документации по системному дизайну, UI, оценке аудитории и всему, что требуется на старте (оба на скринах).
И знаете что? В процессе я не столкнулся ни с одним фиксом логики. Просто ноль. Язык строгий, и уже на уровне линтера и предварительной компиляции LLM видит все проблемы, фиксит их в цикле и выдаёт рабочий вариант.
Из проблем был только UI: неудобно делать скрины, закидывать их агенту и просить фиксить в цикле. Я уже ленив для такого, поэтому, не отходя от кассы, тоже на Rust написал MCP https://github.com/lee-to/peekscreen, который делает скрин окна приложения (можете юзать при разработке десктоп приложений). В итоге LLM в цикле не косячит по логике, сразу фиксит UI, перепроверяет себя — и я получил два работающих, аккуратных приложения.
Я никого не пытаюсь триггерить своими открытиями, просто делюсь мыслями в процессе. Возможно, они ещё изменятся, но это то, что происходит сейчас. Чему-то я радуюсь, а что-то меня немного пугает.
Ещё больше моих наблюдений и открытий о работе с LLM вы сможете увидеть и услышать на нашем с Олегом Мифле воркшопе — https://app.leadteh.ru/w/fnp4S.
Добро пожаловать в новый мир.
- 👍 10
- 🔥 8
- ❤ 2
- 🏆 1
