Если я правильно понял ваш вопрос, то любая LLM является именно такой нейронкой по определению. При этом важность информации для процесса извлечения определяет пользователь с помощью промпта. В статье мы это и делали, составляя промпт для суммаризации особым образом.
С минимальными модификациями приложения попробовал оба варианта. Для LLaMa-2 использовал llama.cpp через LangChain (модель llama-2-7b-chat.Q5_K_M - минимальная потеря качества после квантизации). Результаты:
GigaChat
LLaMa-2-7B-Chat
Не знаю, почему так попердолило LLaMa-2, возможно, я что-то фундаметально не так сделал.
GigaChat же:
Отказался суммаризировать чат по распознаванию речи, так как нашел в нем что-то из стоп-листа (в сообщениях ничего такого нет, проверил вручную).
Выдает очень посредственный результат для "испанского" чата вне зависимости от языка промпта. Посредственный в плане соответствия ответа нашему запросу.
В общем, с полтычка эти варианты не завелись. Я в будущем планировал переносить этот инструмент на локальную LLM на NVIDIA Jetson, так что может быть получится заставить работать что-то кроме GPT-4.
Главная цель этого инструмента - это как раз работа с короткоживущей информацией почти в реальном времени, поэтому для суммаризации всей истории он, конечно, не подойдет.
Насколько я понимаю, в индустрии поставленная вами задача решается обычно файнтюнингом LLM на базе знаний, с которой мы хотим работать, и реализацией RAG (Retrieval Augmented Generation), чтобы помогать LLM результатами семантического поиска по базе. Я думаю, что это вполне себе возможно автоматизировать, чтобы в инструмент можно было скормить любой чат (да что уж там, любой источник знаний в текстовом виде, архив новостного сайта например), а инструмент самостоятельно бы и затюнил LLM, и наполнил базу для RAG.
Касательно стоимости, кстати, согласен на 100%. Даже с игрушечным примером из демо видео (2 суммаризации 2 чатов в сутки с ~100-200 сообщениями в день) за OpenAI API набегало около 1$ в день, что уже много.
Мне кажется, и в этом выступлении, и в бурном его обсуждении здесь главную роль играет "абберация причастности": и господин Хуанг, и мы сами причастны к миру IT, поэтому мы фокусируемся исключительно на том, как дальнейшее развитие ИИ отразится на нашей области и на нас как на IT специалистах. Однако, в словах Хуанга слово "программирование" (хотя на самом деле он говорит о computer science) можно заменить буквально чем угодно: нет смысла учить иностранные языки, т.к. каждый теперь сам себе переводчик; нет смысла заниматься искусством, т.к. каждый теперь сам себе художник, видеомейкер, композитор и т.д.; нет смысла изучать юриспунденцию и законы, т.к. каждый теперь сам себе юрист с ChatGPT и так далее, и тому подобное. Можно даже пойти дальше: зачем вообще кому-либо в наше время получать образование за рамками умения читать и писать? Ведь любой ребенок справится с общением с ИИ в формате диалога, а уж ИИ знает и может все, причем намного лучше, чем человек!
Что я хочу показать этим аналогиями, так это не то чтобы даже абсурдность этого высказывания Хуанга, а скорее очень сильный bias, который, судя по острой реакции сообщества, есть и у нас с вами. Именно из-за этого bias-а его прогноз воспринимается так пугающе реальнистично. А на практике - ну что они, вообще всех, кроме чернорабочих заменят ИИ (да, you will own nothing and be happy)? Нет, конечно, а если и да, то в таком новом дивном мире потеря работы программистами будет явно наименьшей из бед.
Мир меняется, ленивых формошлепов на JS наверняка потеснит ИИ, и нужно следить за трендами и повышать квалификацию, но спрос на умных и творческих людей был, есть и будет всегда. А если так, то зачем волноваться?
В целом согласен, но MKL - это библиотека от самого вендора CPU, то есть, например, на процессорах AMD картина для описанных бенчмарков может быть качественно другой, не говоря уже про совсем отличное от x64 железо. С OpenBLAS же такого быть не должно.
Следование спецификации BLAS действительно много где развязывает руки в плане использования более быстрых реализаций от вендоров железа (Accelerate от Apple, BLIS от AMD, ArmPL от Arm и т.д.), но, как разобрано в этом посте от Modular, подход с платформо-специфичными реализациями, которые тюнились руками, очень плохо масштабируется, особенно для нейронок. В это собственно и заключается основной вывод статьи и, собственно, главная мотивация разработчиков языка: Mojo может и отстает в моменте, но потенционально он предоставляет намного более гибкий и масштабируемый подход для реализации вычислений.
Если кому интересно, эта статья раскрыта автором в его докладе на канале CS50. Стоит посмотреть, чтобы осознать насколько поверхностны и сама статья, и доклад. Кстати, о визионерских способностях автора многое нам расскажет то, что его не успевший толком развиться гениальный стартап был умножен на ноль анонсом GPT Store от OpenAI. Иронично, не правда ли?
Например, в компьютерном зрении, причем и при обучении нейронных сетей, и при их деплое. Дело в том, что на текущий момент не существует оптимальных реализаций PNG декодера на GPU (по очевидным причинам). В результате эта работа всегда происходит на CPU, превращая шаг декодирования входных изображений в bottleneck, так как в большинстве случаев и обучение, и инференс моделей происходит на GPU. Так, например, у NVIDIA есть специальная библиотека DALI, которая как раз и нужна, чтобы минимизировать накладные расходы на декодирования и препроцессинг изображений, и библиотека nvJPEG - реализация JPEG декодера для GPU.
Можно запросто обернуть реализацию на Wuffs в libpng-подобный API, никаких принципиальных ограничений для этого нет.
А насчет того, зачем и почему автор решил изобрести велосипед вместо того, чтобы оптимизировать имеющиеся реализации, так он это пытался пояснить в абзаце про попытки и перспективы пропатчить разные реализации:
libpng слишком сложен, чтобы его патчить.
zlib можно и нужно патчить, но это не очень сильно влияет на скорость декодирования PNG в целом из slow/fast декодирования строк.
Go и Rust можно пропатчить, но это не поможет проектам на C/C++, и memory safety в Go и Rust обеспечивается в том числе runtime механизмами, которые бьют по производительности и которые можно было бы в этой конкретной задаче не использовать совсем.
Кроме того, Wuffs - это не yet another PNG decoder, а инструмент для разработки быстрых и безопасных декодеров для любых форматов даных. Подробнее про это можно почитать в соответствующей части его документации.
Это отчасти раскрывается в абзаце "Почему нет смысла патчить libpng?". Насколько я понял, главная причина заключается в том, что в libpng очень много движущихся частей, которые сильно связаны друг с другом, то есть изолированно оптимизировать какой-то кусок не выйдет, и в итоге придется переписывать большую часть огромной библиотеки. Короче, легаси, как всегда.
Выше уже были комментарии о том, что "Архитектура компьютера" - это не учебник, а обзорная работа, которая отлично подходит для того, чтобы получить первичное представление о том, что вообще происходит в потрохах компьютера. Вы же это отрицаете, а ваша аргументация базируется всего на трех найденных неточностях/упущениях, каждое из которых относится к узкоспециализированным нишевым знаниям, до которых, как мне кажется, большинству читателей дела нет (хотя бы потому, что эти неточности составляют очень малую часть всего материала книги). Да, не очень хорошо, что автор продвигает свое видение некоторых технических моментов, но почему это обесценивает остальную часть материала?
обосновано на существенно более широком и глубоком представлении о предмете, чем привычная многим «доказательная база» «а вот у меня на ноутбуке» :-)
Так себе аргумент, если честно. Может для рядовых пользователей все таки важнее их личный опыт, а не стороннее, хоть и экспертное мнение?
А по существу — будучи более программистом, чем сисадмином, всегда отключаю своп, потому что в стандартной Убунте, например, при включенном свопе просто-напросто не отрабатывает OOM killer. В результате в ситуации пробуксовки (например, если компилируется что-то большое на всех ядрах) система зависает намертво, спасает только перезакгрузка.
В прицнипе, «лайвнесс» — это устоявшийся термин в области лицевой и голосовой биометрии, хотя ухо действительно может резать. Однако, из это же предметной области для термина есть синоним — "(анти)-спуфинг", который, на мой взгляд, несет в себе больше информации.
Меня больше смущают аббревиатуры типа СКО_ДОПОПБП и ВООПБП, для которых не дана расшифровка. Что же все-таки под ними подразумевается?
Сразу мимо… Даже в том же обсуждении -wlifetime для clang предлагали помечать код специальными аннотациями чтобы анализатор мог правильно исследовать время жизни.
Без подсказок со стороны программиста провести исчерпывающий анализ времен жизни невозможно — там существуют неоднозначности, которые должен как раз программист разрешать, расставляя атрибуты. В случае Rust это как раз привело к созданию lifetime синтаксиса.
Мне кажется или этот пассаж как раз таки равняет Раст и C++ с аннотациями?
Вообще-то этот «костыль» намного более выразителен, чем наследование. Может объясните мне его костыльность? Как по мне это еще более сильное разделение между данными и алгоритмами работы с ними, чем это есть в наследовании.
Не знаю насчет выразительности, но код читать тяжелее имхо. Вполне возможно, что у меня ООП головного мозга, но все-таки сознательно делать язык, который не следует общепринятым концепциям, просто так — это как минимум странно. Или быть может есть конкретная причина, почему Раст не реализует ООП?
Список из субьективного восприятия синтаксиса и крайне спорный момент насчет ООП это прямо таки список недостатков. Сильная аргументация, ничего не скажешь.
Я склонен считать, что эти моменты имеют место не только для меня. Кроме того, в вашем ответе объективности не больше. Самое объективное, конечно, это:
Может потому, что их получается писать легко и они при этом еще и работают хорошо?
Диссертация на тему «легко» и «хорошо» как метрики оценки трудоемкости разработки и качества ПО.
Каким конкретно анализатором и какими конкретно настройками этого анализатора мне добиться той же безопасности, которую даёт раст?
Выпишите, пожалуйста, список гарантий, подберем вам анализатор.
У меня
Может, я
у меня есть
Я писал
Пропускаем, не интересно. Не считаю нужным тратить время на спор насчет личных предпочтений.
Даже тут не соглашусь. Для систем, где важна формальная корректность, раст слишком слаб.
Согласен, я не совсем корректно употребил термин. Я видел ваши публикации про развлечения с Идрисом, и, честно говоря, я не считаю, что формальная корректность в таком виде нужна хоть кому-нибудь в индустрии. Я имел в виду больше что-то вроде бортовых систем, где главный показатель корректности — отсутствие гонок. Хотя вроде Раст в этом случае тоже ничего не гарантирует, но это все-таки лучше, чем словить UB из-за алиасинга.
Это два разных языка с двумя разными философиями и идиомами. Писать их через слешс странно. Вы же не пишете «C/C#»?
Не очень уместная придирка. Очевидно, что в этом контексте C и C++ идут в тандеме, так как Раст противопоставляется им обоим с одинаковой аргументацией.
Давайте попробуем разобрать статью и вообще феномен Раста по существу. На протяжении последних нескольких лет я наблюдаю крайне агресивный пиар Раста, и эта статья не исключение. Не могу сказать, с чем это связано, но можно привести ряд аналогичных ситуаций с другими языками, когда языки-«убийцы» не получали должного внимания (взять тот же Julia, например) со стороны сообщества, хотя определенно этого заслуживали.
Вот возьмем, например, главный козырь и киллер фичу Раста — безопасность по памяти, которую обычно противопоставляют отсутствию оной в C/C++. Но в связи с этим вопрос: а чем хуже C++ в связке с хорошим статическим анализатором, чем Раст? Ответ: ничем. Очередная статья очередного апологета Раста, который не имеет опыта разработки на C/C++, выдвигает по этому поводу следующий тезис:
Статический анализ упоминается, как еще одно возможное решение. Но статический анализ требует слишком много времени: его необходимо подключить к системе сборки. «Так что есть большой стимул не использовать статический анализ» — сказал Левик. «Если он не включен по умолчанию, он не поможет».
То есть человек всерьез утверждает, что внедрение статического анализа в CI и в повсведневную разработку слишком дорого по сравнению с обучением сотрудников новому языку.
Кстати об обучению новому языку: синтаксис Раста — это просто треш имхо. За 10 лет программирования на 5+ языках я такого не встречал ни разу. Пусть это субъективное мнение, но я готов поспорить, что ни одному программисту с мало мальски серьезным опытом промышленной разработки такой синтаксис не будет привычен. В этом, очевидно, стоит винить создателей языка. Но оставим в стороне синтаксис — в языке нет ООП. Даже с учетом критики ООП (вполне обоснованной, кстати) эта парадигма на сегодняшний день является де-факто стандартом в индустрии. Создавать в 21xx году язык, в котором наследование заменено костылем в виде трейтов — у меня этому нет объяснения.
Стоит отдать должное Расту — это хороший нишевый язык, который лучше, чем C, подходит для разработки систем, в которых на первом месте стоит формальная корректность. Но зачем писать на Расте микросервисы и тому подобное, да еще и агрессивно продвигать его в качестве 10/10 языка для таких задач? Ответа нет.
Это лишь малый список недостатков Раста, который позволяет поставить под сомнения главный тезис статьи. В общем резюме: с моей точки зрения, Раст конкретно пиарят, не совсем ясно только, кто за это платят. По факту это просто yet another programming language с претензиями. Кто сомневается в искусственно созданном ажиотаже вокруг языка, рекомендую к ознакомлению любопытную статью «Why the developers who use Rust love it so much». При внимательном прочтении можно увидеть все то же, чем грешит данная статья, да и вообще все статьи типа «раст — крута»: о преимуществах Раста перед C/C++, скорой смерти C/C++ и безопасности по памяти обычно громче всех кричат те, кто раньше писал фронтенд на Джаваскрипте (я утрирую, конечно, но суть ясна). Чего стоит только этот пассаж:
When I think of a “statically typed language”, I think of Java, or C#, or something like TypeScript.
Впрочем, Helm и ConfigMaps являются дополнительными опциями, поэтому вам не обязательно их использовать. Вы можете просто скопировать конфигурацию в образ Docker. Тем не менее, заманчиво пойти по этому пути и построить ненужные абстракции, о чём потом можете пожалеть.
Вынесение конфигураций из образа Докера вы называете ненужной абстракцией? Это что-то из рубрики вредных советов.
По-моему, автор не совсем правильно понимает понятие IT. Нельзя рассматривать IT как систему, которая как сказали бы математики, обособлена от окружающего мира и взаимодействует с ним как единое целое.
IT — это не один рынок, а множество, начиная от разработки мобильных приложений и заканчивая машинным обучением и IT-евангелистикой. Не говоря уже о том, что даже чистое программирование очень сильно разнится от области к области, и что, например, системный программист, и разработчик в области телефонии — это в общем-то разные профили, которые не сказать, что сильно пересекаются. При этом у квалифицированного и опытного специалиста мобильность по этим рынкам на порядок выше, чем у рядового «вкатывателя в IT».
Резюме: когда одна область будет насыщена кадрами, те, кто не успел запрыгнуть в этот поезд, просто запрыгнет в другой.
Напоследок стоит отметить, что, по моему опыту, «вкатыватели» испытывают очень большие сложности во время этого пресловутого «вкатывания», когда дело доходит до вещей чуть более сложных, чем laba3.exe и клепания сайтов, из-за образа мышления, который у тех, кто занимается программированием или смежными вещами более долго и серьезно, устроен совсем по-другому. Так что даже вопрос насыщения рынка из-за желающих ХАЙПАНУТЬ очень спорен.
Если я правильно понял ваш вопрос, то любая LLM является именно такой нейронкой по определению. При этом важность информации для процесса извлечения определяет пользователь с помощью промпта. В статье мы это и делали, составляя промпт для суммаризации особым образом.
С минимальными модификациями приложения попробовал оба варианта. Для LLaMa-2 использовал llama.cpp через LangChain (модель
llama-2-7b-chat.Q5_K_M- минимальная потеря качества после квантизации). Результаты:Не знаю, почему так попердолило LLaMa-2, возможно, я что-то фундаметально не так сделал.
GigaChat же:
Отказался суммаризировать чат по распознаванию речи, так как нашел в нем что-то из стоп-листа (в сообщениях ничего такого нет, проверил вручную).
Выдает очень посредственный результат для "испанского" чата вне зависимости от языка промпта. Посредственный в плане соответствия ответа нашему запросу.
В общем, с полтычка эти варианты не завелись. Я в будущем планировал переносить этот инструмент на локальную LLM на NVIDIA Jetson, так что может быть получится заставить работать что-то кроме GPT-4.
См. ответ в ветке выше: это уже будет другой класс задач, для решения которых нужно использовать другие подходы.
Главная цель этого инструмента - это как раз работа с короткоживущей информацией почти в реальном времени, поэтому для суммаризации всей истории он, конечно, не подойдет.
Насколько я понимаю, в индустрии поставленная вами задача решается обычно файнтюнингом LLM на базе знаний, с которой мы хотим работать, и реализацией RAG (Retrieval Augmented Generation), чтобы помогать LLM результатами семантического поиска по базе. Я думаю, что это вполне себе возможно автоматизировать, чтобы в инструмент можно было скормить любой чат (да что уж там, любой источник знаний в текстовом виде, архив новостного сайта например), а инструмент самостоятельно бы и затюнил LLM, и наполнил базу для RAG.
Касательно стоимости, кстати, согласен на 100%. Даже с игрушечным примером из демо видео (2 суммаризации 2 чатов в сутки с ~100-200 сообщениями в день) за OpenAI API набегало около 1$ в день, что уже много.
Мне кажется, и в этом выступлении, и в бурном его обсуждении здесь главную роль играет "абберация причастности": и господин Хуанг, и мы сами причастны к миру IT, поэтому мы фокусируемся исключительно на том, как дальнейшее развитие ИИ отразится на нашей области и на нас как на IT специалистах. Однако, в словах Хуанга слово "программирование" (хотя на самом деле он говорит о computer science) можно заменить буквально чем угодно: нет смысла учить иностранные языки, т.к. каждый теперь сам себе переводчик; нет смысла заниматься искусством, т.к. каждый теперь сам себе художник, видеомейкер, композитор и т.д.; нет смысла изучать юриспунденцию и законы, т.к. каждый теперь сам себе юрист с ChatGPT и так далее, и тому подобное. Можно даже пойти дальше: зачем вообще кому-либо в наше время получать образование за рамками умения читать и писать? Ведь любой ребенок справится с общением с ИИ в формате диалога, а уж ИИ знает и может все, причем намного лучше, чем человек!
Что я хочу показать этим аналогиями, так это не то чтобы даже абсурдность этого высказывания Хуанга, а скорее очень сильный bias, который, судя по острой реакции сообщества, есть и у нас с вами. Именно из-за этого bias-а его прогноз воспринимается так пугающе реальнистично. А на практике - ну что они, вообще всех, кроме чернорабочих заменят ИИ (
да, you will own nothing and be happy)? Нет, конечно, а если и да, то в таком новом дивном мире потеря работы программистами будет явно наименьшей из бед.Мир меняется, ленивых формошлепов на JS наверняка потеснит ИИ, и нужно следить за трендами и повышать квалификацию, но спрос на умных и творческих людей был, есть и будет всегда. А если так, то зачем волноваться?
В целом согласен, но MKL - это библиотека от самого вендора CPU, то есть, например, на процессорах AMD картина для описанных бенчмарков может быть качественно другой, не говоря уже про совсем отличное от x64 железо. С OpenBLAS же такого быть не должно.
Следование спецификации BLAS действительно много где развязывает руки в плане использования более быстрых реализаций от вендоров железа (Accelerate от Apple, BLIS от AMD, ArmPL от Arm и т.д.), но, как разобрано в этом посте от Modular, подход с платформо-специфичными реализациями, которые тюнились руками, очень плохо масштабируется, особенно для нейронок. В это собственно и заключается основной вывод статьи и, собственно, главная мотивация разработчиков языка: Mojo может и отстает в моменте, но потенционально он предоставляет намного более гибкий и масштабируемый подход для реализации вычислений.
Если кому интересно, эта статья раскрыта автором в его докладе на канале CS50. Стоит посмотреть, чтобы осознать насколько поверхностны и сама статья, и доклад. Кстати, о визионерских способностях автора многое нам расскажет то, что его не успевший толком развиться гениальный стартап был умножен на ноль анонсом GPT Store от OpenAI. Иронично, не правда ли?
Например, в компьютерном зрении, причем и при обучении нейронных сетей, и при их деплое. Дело в том, что на текущий момент не существует оптимальных реализаций PNG декодера на GPU (по очевидным причинам). В результате эта работа всегда происходит на CPU, превращая шаг декодирования входных изображений в bottleneck, так как в большинстве случаев и обучение, и инференс моделей происходит на GPU. Так, например, у NVIDIA есть специальная библиотека DALI, которая как раз и нужна, чтобы минимизировать накладные расходы на декодирования и препроцессинг изображений, и библиотека nvJPEG - реализация JPEG декодера для GPU.
Можно запросто обернуть реализацию на Wuffs в libpng-подобный API, никаких принципиальных ограничений для этого нет.
А насчет того, зачем и почему автор решил изобрести велосипед вместо того, чтобы оптимизировать имеющиеся реализации, так он это пытался пояснить в абзаце про попытки и перспективы пропатчить разные реализации:
libpng слишком сложен, чтобы его патчить.
zlib можно и нужно патчить, но это не очень сильно влияет на скорость декодирования PNG в целом из slow/fast декодирования строк.
Go и Rust можно пропатчить, но это не поможет проектам на C/C++, и memory safety в Go и Rust обеспечивается в том числе runtime механизмами, которые бьют по производительности и которые можно было бы в этой конкретной задаче не использовать совсем.
Кроме того, Wuffs - это не yet another PNG decoder, а инструмент для разработки быстрых и безопасных декодеров для любых форматов даных. Подробнее про это можно почитать в соответствующей части его документации.
Это отчасти раскрывается в абзаце "Почему нет смысла патчить libpng?". Насколько я понял, главная причина заключается в том, что в libpng очень много движущихся частей, которые сильно связаны друг с другом, то есть изолированно оптимизировать какой-то кусок не выйдет, и в итоге придется переписывать большую часть огромной библиотеки. Короче, легаси, как всегда.
Выше уже были комментарии о том, что "Архитектура компьютера" - это не учебник, а обзорная работа, которая отлично подходит для того, чтобы получить первичное представление о том, что вообще происходит в потрохах компьютера. Вы же это отрицаете, а ваша аргументация базируется всего на трех найденных неточностях/упущениях, каждое из которых относится к узкоспециализированным нишевым знаниям, до которых, как мне кажется, большинству читателей дела нет (хотя бы потому, что эти неточности составляют очень малую часть всего материала книги). Да, не очень хорошо, что автор продвигает свое видение некоторых технических моментов, но почему это обесценивает остальную часть материала?
Так себе аргумент, если честно. Может для рядовых пользователей все таки важнее их личный опыт, а не стороннее, хоть и экспертное мнение?
А по существу — будучи более программистом, чем сисадмином, всегда отключаю своп, потому что в стандартной Убунте, например, при включенном свопе просто-напросто не отрабатывает OOM killer. В результате в ситуации пробуксовки (например, если компилируется что-то большое на всех ядрах) система зависает намертво, спасает только перезакгрузка.
Меня больше смущают аббревиатуры типа СКО_ДОПОПБП и ВООПБП, для которых не дана расшифровка. Что же все-таки под ними подразумевается?
Не знаю насчет выразительности, но код читать тяжелее имхо. Вполне возможно, что у меня ООП головного мозга, но все-таки сознательно делать язык, который не следует общепринятым концепциям, просто так — это как минимум странно. Или быть может есть конкретная причина, почему Раст не реализует ООП?
Я склонен считать, что эти моменты имеют место не только для меня. Кроме того, в вашем ответе объективности не больше. Самое объективное, конечно, это:
Диссертация на тему «легко» и «хорошо» как метрики оценки трудоемкости разработки и качества ПО.
Пропускаем, не интересно. Не считаю нужным тратить время на спор насчет личных предпочтений.
Согласен, я не совсем корректно употребил термин. Я видел ваши публикации про развлечения с Идрисом, и, честно говоря, я не считаю, что формальная корректность в таком виде нужна хоть кому-нибудь в индустрии. Я имел в виду больше что-то вроде бортовых систем, где главный показатель корректности — отсутствие гонок. Хотя вроде Раст в этом случае тоже ничего не гарантирует, но это все-таки лучше, чем словить UB из-за алиасинга.
Не очень уместная придирка. Очевидно, что в этом контексте C и C++ идут в тандеме, так как Раст противопоставляется им обоим с одинаковой аргументацией.
Вот возьмем, например, главный козырь и киллер фичу Раста — безопасность по памяти, которую обычно противопоставляют отсутствию оной в C/C++. Но в связи с этим вопрос: а чем хуже C++ в связке с хорошим статическим анализатором, чем Раст? Ответ: ничем. Очередная статья очередного апологета Раста, который не имеет опыта разработки на C/C++, выдвигает по этому поводу следующий тезис:
То есть человек всерьез утверждает, что внедрение статического анализа в CI и в повсведневную разработку слишком дорого по сравнению с обучением сотрудников новому языку.
Кстати об обучению новому языку: синтаксис Раста — это просто треш имхо. За 10 лет программирования на 5+ языках я такого не встречал ни разу. Пусть это субъективное мнение, но я готов поспорить, что ни одному программисту с мало мальски серьезным опытом промышленной разработки такой синтаксис не будет привычен. В этом, очевидно, стоит винить создателей языка. Но оставим в стороне синтаксис — в языке нет ООП. Даже с учетом критики ООП (вполне обоснованной, кстати) эта парадигма на сегодняшний день является де-факто стандартом в индустрии. Создавать в 21xx году язык, в котором наследование заменено костылем в виде трейтов — у меня этому нет объяснения.
Стоит отдать должное Расту — это хороший нишевый язык, который лучше, чем C, подходит для разработки систем, в которых на первом месте стоит формальная корректность. Но зачем писать на Расте микросервисы и тому подобное, да еще и агрессивно продвигать его в качестве 10/10 языка для таких задач? Ответа нет.
Это лишь малый список недостатков Раста, который позволяет поставить под сомнения главный тезис статьи. В общем резюме: с моей точки зрения, Раст конкретно пиарят, не совсем ясно только, кто за это платят. По факту это просто yet another programming language с претензиями. Кто сомневается в искусственно созданном ажиотаже вокруг языка, рекомендую к ознакомлению любопытную статью «Why the developers who use Rust love it so much». При внимательном прочтении можно увидеть все то же, чем грешит данная статья, да и вообще все статьи типа «раст — крута»: о преимуществах Раста перед C/C++, скорой смерти C/C++ и безопасности по памяти обычно громче всех кричат те, кто раньше писал фронтенд на Джаваскрипте (я утрирую, конечно, но суть ясна). Чего стоит только этот пассаж:
Вынесение конфигураций из образа Докера вы называете ненужной абстракцией? Это что-то из рубрики вредных советов.
IT — это не один рынок, а множество, начиная от разработки мобильных приложений и заканчивая машинным обучением и IT-евангелистикой. Не говоря уже о том, что даже чистое программирование очень сильно разнится от области к области, и что, например, системный программист, и разработчик в области телефонии — это в общем-то разные профили, которые не сказать, что сильно пересекаются. При этом у квалифицированного и опытного специалиста мобильность по этим рынкам на порядок выше, чем у рядового «вкатывателя в IT».
Резюме: когда одна область будет насыщена кадрами, те, кто не успел запрыгнуть в этот поезд, просто запрыгнет в другой.
Напоследок стоит отметить, что, по моему опыту, «вкатыватели» испытывают очень большие сложности во время этого пресловутого «вкатывания», когда дело доходит до вещей чуть более сложных, чем laba3.exe и клепания сайтов, из-за образа мышления, который у тех, кто занимается программированием или смежными вещами более долго и серьезно, устроен совсем по-другому. Так что даже вопрос насыщения рынка из-за желающих ХАЙПАНУТЬ очень спорен.