Rust прекрасен для определенных целей. Но подумайте дважды перед тем как внедрять его в стартап, который должен быстро развиваться.
Я очень долго думал писать ли мне этот пост или нет, потому что я не хочу начинать или быть вовлеченным в холивар про языки программирования (чтобы сразу расставить все точки над "i": Visual Basic самый лучший язык программирования на свете). Но уже несколько людей спрашивали меня про мой опыт с Rust и должны ли они использовать его в своих проектах. В общем, я хочу поделиться своими наблюдениями, какие я вижу достоинства и недостатки Rust в стартапах, когда скорость разработки и легкость масштабирования команды очень важны.
Я хочу сразу сказать, что я фанат Rust за определенные вещи, которые он умеет. Это пост не про то, какой Rust плохой как язык программирования или о чем-то подобном. Я хочу поговорить о том, что использование Rust почти наверняка приведет к нетривиальной потере скорости разработки, которая может оказаться главным препятствием быстрого развития проекта. Взвесьте основательно стоят ли все достоинства Rust этих потерь.
С самого начала, я должен подчеркнуть: Rust очень хорош в том, для чего он создан. Если вашему проекту нужны конкретные преимущества Rust (высокопроизводительный язык системного программирования, строгая типизация, отсутствие необходимости в сборщике мусора и.т.д) тогда Rust - это прекрасный выбор. Но я думаю, что Rust часто используется в ситуациях, где он не очень-то и подходит. И разработчикам приходится платить высокую цену за эту сложность языка, не получая при этом реальной ощутимой выгоды.
Мой основной опыт с Rust связан с работой с ним чуть более двух лет в предыдущем стартапе, в котором я участвовал. Это был облачный SaaS продукт. Его более-менее можно считать общепринятым СRUD приложением: множество микросервисов, которые предоставляют REST и gRPC API для базы данных, плюс еще некоторые бэкенд микросервисы (разработанные на Rust и Python). Основная причина, почему был использован Rust - это потому что двое основателей компании были экспертами в нем. Со временем наша команда очень сильно возросла в численности (примерно раз в десять). Также сильно возросли размер и сложность самой кодовой базы.
Со временем, с ростом количества членов команды и кодовой базы я чувствовал, что мы начинаем платить слишком большую цену за использование Rust. Процесс девелопмента иногда буксовал, разработка новых фич занимала намного больше времени, чем изначально планировалось. И команда чувствовала реальный удар по производительности из-за решения использовать Rust. Переписка кода на другой язык в долгосрочной перспективе непременно могла бы решить эту проблему, но чрезвычайно трудно найти столько времени на переписку кода. Так что мы как бы застряли на Rust, только если мы вдруг не решили бы стиснув зубы переписать весь код.
Если же Rust такой прекрасный, почему же он нам не подходил?
у Rust крутая кривая обучения
За всю свою карьеру я успел поработать со многими языками программирования, и за некоторыми исключениями, со всеми современными (С++, Go, Python, Java и т.д.). Все они очень похожие в смысле своих основных концепций. Каждый язык имеет свои особенности, но обычно дело стоит за усвоением пары ключевых принципов. В конце концов довольно быстро можно выйти на продуктивную работу. C Rust придется познакомиться с совсем новыми идеями, такими как: время жизни (lifetimes), владение (ownership) и borrow checker. Это незнакомые концепции для подавляющего большинства разработчиков, работающих с другими языками программирования. Получается довольно крутая кривая обучения даже для опытных программистов.
Некоторые эти "новые" идеи конечно существуют в других языках, особенно в функциональных, но Rust приносит их в мейнстрим и поэтому они новы для многих начинающих в Rust.
Несмотря на то, что со мной на проекте были одни из самых умных и опытных программистов, с которыми мне когда-либо приходилось работать, мы часто сталкивались с проблемой, когда не ясно, какой же именно должен быть канонический способ сделать правильно, по-Rustовски. Как понять эти загадочные ошибки компилятора, или понять как работают ключевые библиотеки. Мы даже начали устраивать еженедельные собрания, а-ля "учим Rust", чтобы помочь делиться знаниями. Это все начало ощутимо тормозить общую продуктивность команды. Моральный дух команды тоже падал, потому что все чувствовали что скорость разработки замедляется.
Для сравнения, как выглядела адаптация нового языка в моей команде в гугле. Команда, в которой я работал, была первая, которая полностью перешла с С++ на Go. И это заняло не больше порядка двух недель пока целая команда из 15 разработчиков стала довольно комфортно чувствовать себя программируя на Go. C Rust даже через месяцы каждодневной работы даже мечтать о таком не приходится. Почти ни один человек в команде, не мог чувствовать себя полностью компетентным в Rust. Некоторые коллеги даже признавались мне, что их часто смущало, когда приходилось столько времени тратить на разработку, намного больше, чем изначально планировалось, в основном борясь с проблемами в Rust.
Есть и другие способы решать проблемы, которые пытается решить Rust
Как я отмечал выше, сервис, который мы разрабатывали был довольно простым CRUD приложением. Ожидаемая нагрузка на сервер должна была бы быть не больше пары запросов в секунду максимум в течение всего срока службы этой конкретной системы. Сервис был фронтом для довольно сложной системы, обработка данных в которой могла занимать целые часы. Таким образом наш сервис совсем не мог быть "бутылочным горлышком": узким местом в производительности. Не было и особых опасений, что язык типа Python не сможет обеспечить хорошую производительность. Не было и особой потребности в безопасности или параллелизме, помимо того, с чем должен иметь дело любой веб-сервис. Единственная причина, по которой мы использовали Rust, заключалась в том, что первоначальные авторы системы были экспертами в Rust, а не потому что язык особенно подходил для создания такого рода сервисов.
Для Rust безопасность намного важнее продуктивности программиста. Для многих ситуаций это действительно очень хороший компромисс. Например, когда вы разрабатываете ядро операционной системы, или для встроенных систем с ограниченной памятью. Я прагматик. Я бы предпочел, чтобы моя команда тратила некоторое время на дебаггинг какой-то случайной утечки памяти или какой-то другой баги, чем если бы все в команде страдали от четырехкратного падения производительности из-за использования языка, разработанного таким образом, чтобы полностью избежать этих проблем.
Как я упоминал выше, команда в которой я работал в гугле создала сервис полностью на Go, который со временем вырос до поддержки более 800 миллионов пользователей и поддерживающий примерно в четыре раза больше запросов в секунду чем поиск гугла на своем пике. Я могу сосчитать по пальцам одной руки, сколько раз мы сталкивались с проблемой, вызванной системой типов Go или сборщиком мусора за годы создания и запуска этого сервиса. По сути, проблемы которых Rust создан избегать, можно решить другими способами - хорошим тестированием, хорошей системой код-ревью и хорошим мониторингом. Конечно, не все проекты могут позволить себе такую роскошь, поэтому я могу предположить, что Rust может быть хорошим выбором в каких-то других ситуациях.
Вам будет тяжело нанимать Rust разработчиков
За время моей работы в этой компании мы наняли массу людей, но только двое или трое из 60+ человек, имели реальный опыт работы с Rust. Это было не из-за того, что мы не пытались искать разработчиков Rust. Их просто не было (точно по такой же причине мы не решались нанимать людей, которые хотели кодить только на Rust, поскольку я думаю, неправильно ожидать в условиях стартапа, что выбор языка и других технологий должен быть строго-настрого предопределенным). Эта нехватка талантов со временем изменится, поскольку Rust станет более популярным, но строить проект вокруг Rust, предполагая, что вы сможете нанимать людей, которые уже его знают, кажется рискованным.
Еще один второстепенный фактор заключается в том, что использование Rust почти наверняка приведет к расколу между людьми в команде, которые знают Rust, и теми, кто его не знает. Поскольку для этого сервиса мы выбрали "эзотерический" язык программирования, другие программисты в компании, которые в противном случай могли бы помочь в разработке фич, в отладке багов и т.д., в основном не могли помочь, потому что они не могли разобраться в кодовой базе Rust. Это отсутствие взаимозаменяемости в команде может стать настоящей проблемой, когда вы пытаетесь развивать продукт быстро и использовать объединенные сильные стороны всех членов команды. По моему опыту, людям обычно несложно переключаться между такими языками, как С++ и Python, но Rust достаточно нов и достаточно сложен, и он создает препятствия для совместной работы людей.
Незрелые библиотеки и документация
Эта проблема, которая (я надеюсь!) со временем будет решена, но по сравнению, скажем, с Go, библиотеки и экосистема документаций Rust невероятно незрелы. Преимущество Go заключалось в том, что его разрабатывала и поддерживала целая специальная команда гугла до того, как он был зарелизен, поэтому документация и библиотеки была достаточно отшлифованы. Для сравнения, Rust уже давно ощущается как что-то еще не совсем завершенное (work in progress, так сказать). Документации для многих популярных библиотек довольно неполные и часто приходится читать исходный код данной библиотеки, чтобы понять, как ее использовать.
Апологеты Rust в команде часто оправдывались: "async/await все еще довольно новые понятия" или "да, документации для это библиотеки не хватает". На раннем этапе мы совершили огромную ошибку, начав использовать Actix в качестве веб-фреймворка для нашего сервиса. Это решение привело к огромной боли и страданиям, поскольку мы столкнулись с багами и проблемами, глубоко запрятанными в самой библиотеке, которые никто не мог понять, как исправить (честно говоря, это было несколько лет назад, и, возможно, сейчас ситуация улучшилась).
Конечно, такая незрелость на самом деле характерна не только для Rust, но она представляет собой своего рода налог, который ваша команда должна платить. Неважно, насколько хороша документация и туториалы по вашему языку, если вы не можете понять как использовать библиотеки на нем (если, конечно, вы не планируете писать все с нуля).
Rust очень усложняет прототипирование
Я не знаю, как у других, но когда я начинаю работать над новой задачей, обычно у меня нет с самого начала всех необходимых типов, апишек и других мелких деталей. Я обычно набрасываю простой и грязный код, пытаясь проверить какую-то базовую идею и проверяя, верны ли более или менее мои предположения о том, как все должно работать. Сделать подобное, скажем, в Python чрезвычайно просто, потому что вы можете довольно свободно играться с типами и особо не заморачиваться тем, что какие-то куски кода полностью поломаются, пока вы проверяете вашу идею. Позже вы просто сможете вернуться и привести все в порядок, исправив все ошибки и написать все тесты.
В Rust такая "черновая разработка" чрезвычайна сложна, потому что компилятор может и будет жаловаться на каждую чертову вещь, которая не проходит проверку типов и времени жизни - как это и было специально задумано. Это прекрасно работает, когда вам сразу нужно создать окончательную версию продукта, но совершенно бесполезно, когда вы пытаетесь что-то быстро собрать на коленке чтобы проверить идею или разобраться в каких-то деталях кода. Макрос unimplemented! полезен до поры до времени, но все же требует, чтобы все проверки типов прошли прежде чем вы сможете все это скомпилировать.
Что действительно кусается, так это когда вам нужно изменить сигнатуру какого-то глобального интерфейса. Вы можете завязнуть в часовой подготовке, где вы меняете каждое место, где используется тип, только для того, чтобы увидеть, осуществима ли ваша первоначальная идея или нет. А затем переделывать всю это работу, когда вы понимаете, что вам необходимо что-то еще изменить.
Где Rust хорош?
Определенно есть вещи, которые мне нравятся в Rust, и фичи Rust, которые я хотел бы видеть в других языках. Match синтаксис просто великолепен. Option, Result и Error трейты действительно очень мощные инструменты. А оператор ? элегантный способ обработки ошибок. У многих этих идей есть аналоги в других языках, но подход к ним в Rust особенно элегантен.
Я бы абсолютно точно использовал Rust для проектов, которым нужен высокий уровень производительности и безопасности и для которых я не очень бы беспокоился о необходимости быстрой разработки быстрорастущей командой. Для персональных проектов или очень маленьких (скажем, 2-3 человека) команд Rust, скорее всего, подойдет. Rust - отличный выбор для таких проектов как модуль ядра, прошивки, игровые движки, и т.д., где производительность и безопасность имеют первостепенное значение, а также в ситуациях, когда может быть сложно провести действительно тщательное тестирование перед релизом.
Окей, теперь, когда я достаточно разозлил половину читателей, я думаю, сейчас самое подходящее время, чтобы объявить тему моей следующей статьи: почему nano - лучший текстовый редактор. Увидимся в следующий раз!
Комментарии (31)
Px2
09.12.2022 07:39-13Как вы яхту назовёте, так она и поплывёт. Чего хорошего можно ожидать от языка с названием Ржавый?
Ржавые болты не всегда можно выкрутить, иногда их приходится срезать, высверливать и нарезать новую резьбу.
Vasyutka
09.12.2022 08:32+5Вообще довольно пугающая история :). Выбрать специфический язык и стек для стартапа. В стартапах всегда нехватка всего: ресурсов, времени. Да просто людей искать сложно. Грубо говоря специфический стек уменьшает компетенцию команды из-за меньшего охвата. А компетенция - это то чего не хватает в первую очередь всегда :))).
Mingun
09.12.2022 08:58+10Вообще похоже на плач менеджера. Пара увлеченных людей сделала проект на расте, он выстрелил, пришел менеджер и начал жаловаться, что людей на дальнейшую поддержку и развитие не найти
JekaMas
09.12.2022 10:11+1Откуда вывод про "выстрелил"? Судя по cv автора https://www.mdw.la/ и информации про компанию - https://www.crunchbase.com/organization/xnor-ai она мертва с 2020 года.
Lewigh
09.12.2022 10:09+7Интересно, какое следующее озарение придет автору оригинальной статьи? Что писать frontend на С не лучшая идея? Затрагивая данную тему мне кажется нужно было бы обсудить актуальную тему самодурства основателей стартапа, которые вместо того чтобы подобрать инструмент согласно потребностям и возможностям, решили в игрушки поиграть. Причем вместо Rust можно подставить любую модную но не подходящую для задачи технологию. Но нет, откроем людям правду что оказывается язык программирования в основном предназначенный для системного программирования не очень подходит для написания crud приложений.
Pastoral
09.12.2022 11:09+3Ребята не смогли превратить "крутую кривую" в механизм объективной оценки кадров и саморазвития. Эффективных менеджеров которым нужно хотя бы одно из этого - не видел.
Alexrook
09.12.2022 11:12+1Не понял, почему в пример приводится Go. Ведь там компилятор тоже любит «жаловаться» и не всегда быстро можно отыскать нужную и подходящую библиотеку. Если необходимо быстрое прототипирование, то возможно, надо смотреть вообще в сторону самых популярных динамически типизированных языков. А если уж стартап выстрелит, тогда потратиться на его перевод полностью или частично на уже осознанно и тщательно выбранный технологический стек.
143672
11.12.2022 19:07+2После компилятора раста компилятор go выглядит как интерпретатор js на фоне компилятора go
domix32
09.12.2022 11:34+1Мне кажется резкий перевод команды из 15 человек на новый язык - одна из причин боли. Насколько крута кривая обучения, настолько медленным по идее должно быть и раскатывание языка по команде. Ну и прагматичность как-то вас подвела в плане использования мощных штук типа актикса.
inv2004
09.12.2022 13:47+2Я всегда жаловался на скорость разработки на Rust. И мой опыт, в целом, соответствует опыту в статье. Правда у меня был большой pet-проект, на расте я писал его около двух лет, после очередной борьбы (https://t.me/inv2004_dev_blog/28 https://t.me/inv2004_dev_blog/29) наконец-то плюнул и решился сменить язык. Но, главное удивление, я понимаю что в голове уже были некие дорожки по этому проекту, но переписывание всего функционала параллельно улучшая, заняло ТРИ НЕДЕЛИ, три недели и два года, Карл!
mayorovp
09.12.2022 15:07+4Что-то ни в одной вашей истории не понятно на что вообще жалоба.
Чем вам помешало разделение чанков, что пришлось аж сервер менять?
Где вы в
mongodb::Cursorвообще увидели ссылку, да такую что её аж пинить пришлось?inv2004
09.12.2022 15:25Нужен был подсчёт чанков, пришлось патчить hyper: https://github.com/hyperium/hyper/pull/2087
Ws на actix-web оказалось неподъёмной задачей
Там надо было хранить и коллекцию и курсор/итератор. Получается циклическая структура
mayorovp
09.12.2022 15:52+6Нужен был подсчёт чанков, пришлось патчить hyper: https://github.com/hyperium/hyper/pull/2087
Вам нужна была хрень. Чанки http имеют семантику потока байт, а не потока сообщений. Нет никакой причины, по которой получателя в принципе должен волновать вопрос сколько чанков ему пришло. Собственно, вам об этом и написали:
Intermediaries (proxies and gateways) may re-interpret the chunked encoding, so this isn't reliable. Additionally, HTTP2 and 3 don't use chunked encoding.
Понимаете, это не библиотека виновата, и не Rust, это протокол HTTP так работает!
Всё, что требовалось — это натравить потоковый парсер json на поток байт в асинхронном цикле. Это делается куда быстрее чем те несколько недель, которые вы упоминали в истории.
Там надо было хранить и коллекцию и курсор/итератор. Получается циклическая структура
О каком цикле речь?
Да, Cursor ссылается (через Arc) на Collection, но Collection же на Cursor не ссылается… В чём проблема просто положить их рядом двумя полями?
inv2004
09.12.2022 16:39Люблю такие бесплатные советы. Жаль вас не было в раст-чате когда я там спрашивал, потому как вы, очевидно, опытнее чем 1000+ человек оттуда.
Но, напишу еще раз, в первом случае надо или делать свой протокол, либо переходить на ws, хотя проблема только в отсутствии одного метода. Причём тут json и каким образом он потоковый вообще? Дело не в http, ведь хайпер умеет обрабатывать чанками
А второе - вы не проходите их вместе, по причине что я описал выше
mayorovp
09.12.2022 18:48+6Честно говоря, не понимаю почему всем так нравятся чаты. Там, конечно, попытаются помочь (если это не чат по линуксу), но вы можете просто не пересечься во времени с кем-то знающим ответ. Что, видимо, и произошло.
SO, форумы или списки рассылки выглядят куда более надёжными. Я, например, периодически на ru.SO наведываюсь. Но период бывает большой, да — неделю прождёте запросто.
Дело не в http, ведь хайпер умеет обрабатывать чанками
То, что хайпер умеет (точнее, умел) обрабатывать чанками — это иллюзия. Такая же, как приём TCP пакетами. И проблема именно в этом.
Json же тут при том, что у вас (цитата) Server sends several jsons: one per http-chunk. И эти самые джейсоны у вас склеиваются при приёме сплошным потоком. А потоковый парсер позволит выцепить из потока json-сообщения без предварительного чтения всего потока в память.
А второе — вы не проходите их вместе, по причине что я описал выше
Не пройду куда? Вот я написал следующий код, и он скомпилировался:
use mongodb::{Collection, Cursor, bson::Document, options::FindOptions, error::Error}; pub struct MyIterator<T>(Collection<T>, Cursor<T>); impl<T> MyIterator<T>{ pub async fn new(collection: Collection<T>) -> Result<Self, Error> { let cursor = collection.find( Document::default(), FindOptions::default() ).await?; Ok(Self(collection, cursor)) } }
inv2004
09.12.2022 16:50Чтобы не быть голословным, если хотите, я восстановлю тот код с циклическими ссылками и сделаю минимальный пример. Если вы сделаете за час - я вам оплачу этот час, если нет - то вы мне . потому что писать слова в чате типа "просто заворачиваешь один поток в другой", здорово конечно, но часто в реальности не так просто
mayorovp
09.12.2022 18:53+1Код я вам привёл выше, бесплатно.
inv2004
09.12.2022 19:18Я даже не уверен что вы разобрались в датах сообщений и взяли тот монго-крейт, который был актуален на момент того что я написал
mayorovp
09.12.2022 19:59+8Ваши сообщения без VPN не открываются, это сильно мешает подробно разбираться. Однако, раз вы настаиваете, я всё же скомпилировал код с версией 1.2.5, которая вышла за три недели до вашего второго сообщения:
use mongodb::{Collection, Cursor, bson::Document, options::FindOptions, error::Error}; use serde::{Serialize, de::DeserializeOwned}; use std::fmt::Debug; pub struct MyIterator<T: Serialize + DeserializeOwned + Unpin + Debug> (Collection<T>, Cursor<T>); impl<T: Serialize + DeserializeOwned + Unpin + Debug> MyIterator<T>{ pub async fn new(collection: Collection<T>) -> Result<Self, Error> { let cursor = collection.find( Document::default(), FindOptions::default() ).await?; Ok(Self(collection, cursor)) } }Пришлось добавить несколько ограничений, но в остальном никаких изменений.
indestructable
09.12.2022 15:44+4По моему личному опыту, разработка CRUD на Rust (Actix Web, SqlX, Postgres) была в среднем равна по скорости разработке на Node.JS и Typescript (хотя и разрабатывал я его в одиночку). В однотипном (и достаточно простом, чего уж) коде, коим является CRUD, проблемы и ошибки достаточно однотипны, и сильной просадки по скорости разработки не было.
Ощущения от разработки на Rust, конечно, совершенно другие, чем от Typescript, почти нет мелких досадных ошибок типизации (хотя и на Тайпскрипте их не очень много, по сравнению с чистым Джаваскриптом, не представляю, как люди нем пишут), основные ошибки - в логике программы. Хотя код получается более объемным.
Cheater
09.12.2022 15:59+6Странные ребята. Переходят на экзотический язык во имя личных пристрастий. Бизнес за такое бьёт по рукам очень сильно. У меня на работе есть определённая свобода в выборе стека технологий для команды, но даже при своём пристрастии к Rust я никогда не выберу его для прода вместо например C++ в команде, пишущей на плюсах, потому что это означает гемор с обучением, наймом разработчиков в будущем, плюс непрерывные траты усилий в код-ревью "чтобы люди с опытом в C++ не писали на Rust как на C++", плюс ряд прочих проблем, по большей части нетехнических.
Но раз уж команда авторов взялась делать всё на расте, непонятно откуда эти проблемы с возросшим временем разработки. Не знаю как в крудостроении, но у нас 90% времени занимают бесконечные обсуждения поведения, и только 10% написание кода, причём кода в стиле достаточно туповатого ООП, который будет выглядеть плюс-минус одинаково что на C++ что на Rust что на Python, и потребует примерно одинакового времени реализации на различных языках. Возможно они полезли в асинхронщину.
По сравнению, скажем, с Go, библиотеки и экосистема документаций Rust невероятно незрелы. Преимущество Go заключалось в том, что его разрабатывала и поддерживала целая специальная команда
Всё там прекрасно документировано. У Rust Foundation тоже выделенная команда тех. писателей и та же std и ряд стандартных крейтов документированы ими вдоль и поперёк. Подозреваю, что автор в основном пользуется крейтами и продуктами третьей стороны, тем же Actix, он хочет чтобы всё было документировано на том же уровне?
VCheese
09.12.2022 17:31+6В Rust такая "черновая разработка" чрезвычайна сложна, потому что компилятор может и будет жаловаться на каждую чертову вещь, которая не проходит проверку типов и времени жизни - как это и было специально задумано.
Я только изучаю Rust, параллельно разрабатывая свой небольшой проект. Даже имея такой маленький опыт, могу с уверенностью сказать, что в Rust ничего не заставляет использовать обобщённые типы, указатели, их времена жизни и т.п.. Делая прототип, я везде использовал .unwrap(), чтобы не тратить время на обработку ошибок, всюду, где ругался компилятор, передавал объекты через .clone(), а дженерики вообще не нужны, если у меня всюду один f64. Когда все тесты написаны, то можно спокойно заняться мытьём полов, избавляясь от грязного кода, заняться продумыванием системы типов и обработкой ошибок. В этом плане я не заметил ухудшения своей производительности по сравнению с Питоном с его "игрушечной" типизацией.
ReDev1L
10.12.2022 23:10+1Даже в растбуке написано - перфомансом занимайтесь когда будете понимать что он вам нужен, а сейчас достаточно clone() =)
Akuma
09.12.2022 18:46+3Поддержу. Опыт работы с web на Rust, в частности с actix ужасен. Это прям "не его". После Go-шных миллионов веб-библиотек (не говоря о стандартной) этот скудный выбор и откровенно неудобные решения...прям брр.
Пару месяцев назад (т.е. исключаем незрелость) я на нем не смог сделать даже обработку array значения из query string (a[]=1&a[]=2&a[]=3). Ну вот просто не работает (судя по SO, не у меня одного). Компилируется и втихаря всегда возвращает пустой массив. Пришлось просто сплитить строку по запятым (благо у меня простые значения).
В ту же копилку загрузку файлов на actix. Таких ужасных примеров/документации я очень давно не видел, это прям жесть. Хотя, казалось бы, очень простая задача для веб-фреймворка.
catlion
09.12.2022 18:53+4За время моей работы в этой компании мы наняли массу людей, но только двое или трое из 60+ человек, имели реальный опыт работы с Rust. ... мы не решались нанимать людей, которые хотели кодить только на Rust
За что боролись - на то и напоролись.
Revertis
09.12.2022 20:46Но я думаю, что Rust часто используется в ситуациях, где он не очень-то и подходит.
Ну да, большинство чуть что сразу асинками думает. А ведь можно на том же Расте писать код как на Java, без всяких асинков, которые как раз из-за красно-синих функций усложняют проекты. И прототипировать на Расте можно очень эффективно, главное юзать нормальные IDE, а не nano :)
klimkinMD
11.12.2022 09:40Основная причина, почему был использован Rust - это потому что двое основателей компании были экспертам в нем.
Во-первых, хорошо, что не в Ассемблере.
С другой стороны, может основная цель стартапа и была в том, чтобы проверить гипотезу о возможности создания продукта целиком(!) и сразу(!) на Rust (со всеми "пирогами": найм, обучение, ...). Просто, автор был не в курсе. Статьи и обсуждения, это -- одно, а личный опыт -- другое.
SaemonZixel
11.12.2022 23:16+1Реальный, практической опыт применения Rust в растущей компании - это весьма ценная вещь. Лично я теперь буду лучше ориентироваться когда и какой язык лучше применять. Спасибо за статью!)
Cerberuser
"Just be careful"?
Моя собственная практика показывает, что ещё больнее может укусить, если не изменить какое-то место, где используется тип (потому что оно просто проскочило мимо внимания). Впрочем, возможно, именно для прототипа это не страшно, потому что он всё равно кусается постоянно, чисто в силу изменяющихся требований.