По окончанию перевода официальной версии TRPL или раст-бука (ссылка на русский вариант), я решил написать про свои размышления, наблюдения и встретившиеся сложности.
Перевод последней актуальной версии сделан на основе последней редакции из основного репозитория английского оригинала.
До перевода я в свободное время прочитал английский оригинал книг: TRPL и Rust-By-Example. Предыдущий русский перевод смотрел редко, так как он на тот момент местами серьезно устарел по содержанию. Мой предыдущий опыт складывается из пары десятков лет java backend R&D проектов разной направленности, от «кровавого enterprise» до стартап-ов, с чем и связана основная деятельность. От себя могу ответственно сказать, что действительно многие нюансы языка или другие детали после первого прочтения английской версии остались мной не замеченными. По этой причине я рекомендую попробовать хотя бы «пролистать» русский вариант. Если вы новичок в Rust вроде меня, то с большой вероятностью найдете в ней что-то не замеченное ранее. Если английский для вас «со словарем или около этого», если вы хотели бы познакомится с Rust, то тем более.
Перевод не идеален, потому что сам оригинал изобилует большим количеством длинных перегруженных, «сложных сочиненно-подчиненных» предложений. Я не берусь судить строго авторов, можно ли было написать проще? Наверное да..., но профессиональным переводчиком я не являюсь. В редких местах не всегда мотивированная сложность оригинала приводит к тому, что возможно некоторые предложения или их части выглядят слегка «инородными». Этого хотелось избегать, но может не везде удалось. Думаю, что таких мест не много в книге и что особенно важно они не влияют на главный смысл материала, имея второстепенный, вспомогательный характер. При переводе с одной стороны хотелось сохранить текст узнаваемый в оригинале (без фанатизма), с другой не потерять важные детали концентрируясь на главном, а с третей приблизить перевод к родному языку без «тяжелых англицизмов», но с более-менее понятной, устоявшейся терминологией, с четвертой добавить не всегда очевидные мини-пояснения, вплетая их в текст. Попробуйте держать оригинал под рукой для таких, надеюсь, редких случаев.
В общей сложности перевод занял около 7 месяцев, с начала октября 2019 до почти конца апреля 2020. Мной переводилось, поправлялось, вычитывалось порядка 100 страниц книги разного объема и сложности, от коротких, до очень длинных и сложных в конце. Делал в основном вечером, в выходные или праздники, когда позволяло свободное время. Перевод выполнялся на ресурсах проекта gitlocalize.com, который предоставляет возможности коллективного перевода. Но основным преимуществом этого ресурса, я для себя нашел «встроенные» возможности «машинного перевода» (от google?), плюс код gitlocalize позволяющий получить корректными тэги кода и разметки из оригинального текста. Чтобы перевести абзац достаточно кликнуть кнопку и получить текст «разной степени пригодности» без полного и ручного набора, сохраняющий необходимые разметки и тэги из оригинала. Это все экономило время, не смотря на «машинность» перевода. Переставить слова в более естественный порядок, поправить окончания, поменять поломанный смысл было быстрее, чем делать ручной набор, допуская неизбежные «очепятки». Это было настолько удобнее, что со временем я перестал пытаться вычитывать предыдущий русский перевод, который частично имелся в наличии. Причиной было то, что новый текст изменился по содержанию и/или по встроенной в текст разметке, так что его вычитывание и изменения занимали больше времени, чем если сделать машинный перевод абзаца со вполне корректной разметкой кода, внести в него необходимые исправления, причесать, поправить стилистику и т.д. По моему субъективному ощущению, я переделал или перевел с нуля от 70 до 85% текста, потому что часть вроде как готового, кем то ранее переведенного текста приходилось заново перечитывать и вносить точности из оригинала.
Коллективные возможности gitlocalize в данном случае пригодились меньше в силу малого числа участников перевода. Из хорошего — это что остается возможность использования репозитория для дальнейших правок и дальнейшей синхронизации при изменениях и дополнениях оригинала. Сам ресурс gitlocalize периодически переставал работать на разное время из-за не всегда успешных обновлений сайта и/или кода, но в общем это было «не смертельно», но приостанавливало перевод на время.
Зачем мне это было нужно? Можно считать это моим вкладом в open source. Около 20 лет назад я начал изучать и потом работать на новом и перспективном ЯП. С год назад я подумал на тему «куда дальше», обратил внимание на движение языков/компиляторов в сторону получения кода, как можно близкого к «двоичному», его native исполнения, где-то с GC (garbage collector), где-то почти без него. По итогу размышлений я начал искать в каком направлении можно приложить знания и умения «на перспективу» — Kotlin, Scala, Go, последним в списке был Rust. После небольшого ознакомления со списком, личный выбор стал очевидным. Стали понятны важные плюсы — обеспечение безопасности Rust, минусы в его сложности, высоком пороге вхождения, перспективы его развития и возможные ниши использования. Субъективно мне ЯП «зашел», он стал занимать мое свободное время для изучения и практики. Я считаю его универсальным ЯП, со временем планирую найти full-time вакансию на Rust, хотя рынок проектов на нем все еще достаточно мал по сравнению с остальными ЯП, особенно в части Enterprise решений. Субъективно могу говорить, что ЯП возможно все еще отчасти не до оценен. Можно заметить оправданный интерес «ИТ гигантов» к ЯП вроде Microsoft, немного Intel, но список использующих его в реальных проектах довольно не большой, официально порядка 150 компаний, что не много в глобальном плане.
Какие наблюдения появились за год неспешного освоения?
Вряд ли это язык для тех кто массу сил и своего времени уже вложил в c++, как это не парадоксально. Он им чаще не нужен по многим объективным и субъективным причинам, которые нет смысла обсуждать слишком подробно. Я бы произнес в слух определенный личностный «downgrade» в плане предыдущего опыта, у кого он был, на который не все могут решится и наследие «legacy» кода для больших компаний, хотя это не единственные причины. Субъективно, в Rust приходят в массе из ЯП «попроще», вроде Javascript, Python, Ruby, Java и т.д.
Невозможно переписать существующие проекты на Rust, это далеко не всегда нужно и далеко не целесообразно, хотя единичные, успешные примеры есть. По этим причинам, субъективно, это скорее ЯП для новых проектов.
Что меня мотивировало при переводе? Отчасти я начал перевод, а после «затянуло». Появился некоторый азарт и возможность видеть результат, абзац за абзацем, неделю за неделей. Еще был мотив сделать перевод для сына, студента первокурсника ИТ специальности, да и вообще для всех студентов, будущих возможных коллег. Чтобы они могли получить возможность начать изучение и сами получить представление о ЯП, добавлю так «сыну, одному из тысяч студентов данный перевод посвящается».
Разработка компиляторов сложное, долгое и дорогое удовольствие, но Rust развивается, цикл выпуска новых версий компилятора выдерживается, IDE хорошо подтянулись в помощи разработчику за последний год. Я как ни странно верю в большое будущее данного ЯП, что бы ни говорили про его «игрушечность». Да, разработка языка и инструментов Rust это не так легко и быстро, как этого иногда хотелось бы всем поклонникам Rust, но увы, разных ресурсов довольно часто на все не хватает — таковы реалии нашей жизни. Покидать «тапки или тухлые помидоры» можно в телеграмм чате для Rust переводов.
Комментариев нет:
Отправить комментарий