На чем написан rust игра
История RUST //История разработки // как все начиналось?
Сегодня мне хотелось бы рассказать вам историю одной замечательной многопользовательской игры в жанре Survival/Sandbox. Которая была придумана из-за спора двух друзей — геймеров, а в будущем коллег и основателей компании FacePunch. История игры, которую все в одно время хейтили, а в другое любили. Историю разработчиков, которые не опускали руки и шли к своей цели. Интересно? Ну тогда погнали)
Rust — это многопользовательская игра в жанре Survival/Sandbox. Разработка была запущена британской независимой студией FacepunchStudios в 2013 году.
Непосредственными авторами и создателями игры являются: Гарри Ньюман — основатель и владелец студии FacePunch, более известен по своему проекту Garry’sMod. И Маурино Берри — близкий друг Гарри.
Релиз состоялся в Steam: 11 декабря 2013 года.
Началось все с того, что в 2013 году разработчики проводили много времени играя в DayZ. Именно во время игры в неё Маурино сказал Гарри, что сможет сделать более лучшую «версию» этой игры. Гарри не стал возражать, после чего буквально за 6 месяцев они получили первый рабочий прототип игры. В большинстве своём игра была сделана кустарно, код писался на коленке, многие модели элементов (оружие, животные) были куплены в магазине Unityassetstore, а те модели что небыли куплены — сделаны на скорую руку. В то время игра буквально состояла из недочётов, багов и «дыр» как в геймплее, так и в коде, однако уже тогда игра имела свою любящую немногочисленную аудиторию.
Изначально игра открыто позиционировалась как клон DayZ, но постепенно она отдалялась от своего «корня» и в конечном итоге стала уникальным и самодостаточным проектом.
Первый прототип игры был браузерным, люди играли в него используя UnityWebPlayer. Продавали игру ключами через старый официальный сайт old.playrust.com (ныне отключен). С ростом числа аудитории, разработчики выпустили клиент игры, что так или иначе говорило о проектном росте.
Со временем игра очень сильно преобразилась. 1 ноября 2013 года разработчики подняли новый сайт — playrust.com, после чего все логи обновлений и новости публиковались уже там.
Пара слов о ранних порах игры:
Мало кто знает, но раньше металл плавили в кострах, отображение одежды на персонажах отсутствовало — даже без одежды персонаж выглядел как солдат в военной форме.
Конечно со временем разработчики устраняли баги, но на их место приходили новые.
Тем на менее тогда были свои плюсы, например полностью отсутствовали читеры.
Т.к. аудитория тогда была ещё относительно мала — делать платные читы не имело смысла, ведь покупать их бы всё равно никто не стал, а бесплатные делать просто никто не хотел.
Игра не смотря на всю свою примитивность была крайне атмосферная и хардкорная, сохранить свой дом в целостности было очень сложно. Чтобы понять суть, посмотрите это старое видео.
Стоит упомянуть, twitch.tv и youtube.com поспособствовали огромному приливу аудитории, стриммеров и летсплееров по игре становилось всё больше и больше, и как следствие число купивших игру росло.
Однако так называемый «стартовый пак» аудитории пришёл от Гарри Ньюмана, который уже тогда имел популярность за счёт своего проекта Garry’smod.
Небольшое примечание: тогда игр в подобном жанре было очень мало, исключая DayZ и DayZmod на базе Армы, единственное что приходило на ум — майнкрафт. Именно успех Rust воодушевил множество геймдевов разрабатывать игры в жанре «Песочница-выживание».
Релиз Rust в Steam состоялся 11 декабря 2013 года, до этого момента игра распространялась только через официальный сайт. Когда разработчики добавили игру в магазин Steam, они не рассчитывали на огромный прирост аудитории, ведь основной костяк уже давно играл и ничего сверхъестественного в игру добавлено не было. Но внезапно, на старте продаж в Steam, Rust буквально за 2 недели купили 150 000 человек, позже число покупателей увеличилось до 500 000.
А по прошествии 2-х месяцев было продано 1 миллион копий игры.
21 февраля 2014 года (через 2 месяца после релиза) Rust заработал своим создателям 40% от общей прибыли Garry’sMod за 9 лет продаж (примерно 20+ миллионов долларов), а продажи только продолжали расти. Без комментариев.
Это стало прецедентом, игра в состоянии EarlyAccess (ранний доступ), сделанная мягко говоря как попало, полностью обеспечивает себя и студию, гарантируя финансовую независимость себе и будущим проектам студии.
Кстати говоря, именно в феврале 2014 года Rust был на пике своей популярности, рекорд онлайна — 58 973 человека одновременно. Представляете масштаб происходящих тогда событий?
В январе 2014 года Rust стал самой продаваемой игрой на платформе Steam и держался на этой позиции довольно долго.
Все были в состоянии недоумения, «КАК ТАК?» Логично, люди пишут бизнес-планы, подключают спонсоров, набирают команды разработчиков по 20 человек, работают годами. А тут 2 парня за 7-8 месяцев сделав «это» получают результат, к которому многие идут десятилетиями (например сам Гарри Ньюман со своим Garry’smod).
Всё было грустно и весело одновременно, разработчики открыто заявляли — они не готовы к такому результату. Как говорил сам Гарри, план был таков: запускаем продажи, набираем 20-30 тыс. игроков и тихим сапом разрабатываем игру в течении нескольких лет, постепенно наращивая аудиторию (как и было с Garry’smod). Но тут случилось непредвиденное экономическое «чудо».
Каково это? Хорошо ли получить золотую медаль на старте марафона? На самом деле разработчики не сильно радовались, помимо прибыли они получили огромный груз ответственности и о планах «Медленно, но верно» можно было забыть, надо было срочно что-то думать и делать.
Чем же игра являлась тогда?
После релиза разработчики активно начали переделывать косметическую составляющую игры: новое небо, трава, также были потуги добавить на карту реки и озёра.
Кроме того они пытались вносить изменения и в геймплей: револьвер, кровати, решётки на окна, «прочность предметов» и возможность их починки.
В конечном счёте разработчики начали строить планы по отходу от жанра «Зомби-выживание», первым шагом стало удаление из игры этих самых зомби и добавление вместо них «красных» волков и медведей, которые по факту были такими же зомби. Сделали это для того, что бы игру перестали сравнивать с другими играми с «зомби и пушками», ведь раст был не таким. Зомби в Rust, как таковые не играли никакой роли в геймплее, в отличии от других «подобных» игр. Сам Гарри писал, что «красные животные» лишь временная мера, «В будущем всё будет ребят» говорил он вкратце.
Даже запустил эпичный опрос с вариантами того, что игроки хотели бы видеть в качестве NPC. Чего там только не было, и роботы, и динозавры, и магические существа.
Казалось, что осталось совсем чуть-чуть и игра начнёт преображаться быстро и стремительно и ведь тогда всё только об этом и говорило…
Но там где есть бочка мёда, обязательно найдётся пару ложек дёгтя, которые испортят всю бочку без остатка.
1. Читы, создатели которых получили хороший стимул для работы. Фактически Rust для них стал золотой жилой, игра была не качественная, код был кривой, движок был уязвимый, защиты от читов окромя VAC не было совсем. Ну и тут понеслось. Видов читов было столько, что их даже все и не перечислишь, «за ваши деньги любой каприз» как говорится. Разработчики приняли бой и начали войну с читерами, которая почти сразу закончилась безоговорочной капитуляцией разработчиков.
Цитата Гарри Ньюмана:
Мы хотим создавать игру, а не античит для игры.
Несмотря на постоянные баны — все сервера так или иначе были с читерами (в том числе официальные), несмотря на множество способов их обнаружения — умелые чито-делы придумывали новые способы обхода защиты.
Тогда найти сервер без читеров было невозможно и, даже если вы таковой найдёте, не было гарантии, что сейчас не зайдёт читер с ноклипом и не заруинит десяток другой домов, включая ваш. Однако, главной проблемой разработки игры были не читеры.
2. Игра, точнее её код, который был очень плох. Попытавшись продолжить разработку на старом коде, разработчики поняли, что он ни на что не годен, по словам разработчиков, с таким кодом двигаться дальше было невозможно. Гарри не стеснялся в выражениях называя его говно-кодом. Исправляя баг — получали два, устраняя 1 эксплойт, всплывало ещё три, процесс разработки напоминал «сизифов труд», мало того что проблемы не уходили, так ещё и времени на работу уходило несоизмеримо больше, чем требовалось + никакого удовольствия от процесса, всё это так или иначе привело к «перезапуску», который нам с вами известен как текущая — стабильная версия игры.
После долгих мучений разработчиками было принято решение полностью перезапустить игру, и начать делать её с нуля. Основой для новой версии стала экспериментальная ветвь (Experimentalbranch), которая изначально предназначалась для «экспериментов» с игровой механикой.
Началось всё естественно с написания нового кода. Выглядело это примерно так:
И это ещё не самая первая версия, в самой первой вообще ничего не было кроме стартового кита с топором и квадратного острова.
В то время Legacy версия продолжала функционировать и многие даже понятия не имели, что разработку их любимого старого Rust’а остановили и приступили к созданию нового.
Будущее выглядело мутным, команда разработчиков не росла в числе, для наблюдателей всё двигалось медленно и казалось, что в ближайшие 3 года игру можно не ждать, с чего собственно и поднимались восстания в разделе отзывов Steam «верните деньги!».
Конечно подобные отзывы писали люди не просвещённые, перед тем как покупать игру с пометкой «Ранний доступ», надо знать, что игра может выходить в бету и релиз ещё очень долго (а в некоторых случаях не выйти вообще).
Во всём случившемся был один и единственный плюс — свобода действий разработчиков и огромное пространство для творчества, чем разработчики и воспользовались начав экспериментировать с геймплеем игры.
Для начала решили добавить вид от 3-го лица, как выяснилось «просто посмотреть» (позже его убрали), также решили сделать процедурно-сгенерированную карту — карта, которая будет генерироваться с помощью скриптов и алгоритмов, создавая на каждом сервере свою уникальную карту. Многие писали «Но ведь „машинная“ карта никогда не сможет стать лучше „ручной“, машина не сможет сделать действительно атмосферные пейзажи и создать поистине красивую карту» в чём-то они были правы, однако Андре показал, что правильно настроенная «машина» тоже немножко умеет в дизайн ландшафта. В конечном итоге разработчики всё-таки решили сделать образец карты вручную, но от процедурных карт не отказались. В финале разработчики обещали дать возможность любому серверу сделать свою собственную карту. Да и в принципе наладить работу Workshop’а со всеми вытекающими последствиями. Помимо этих нововведений, было добавлено ещё очень много всего, чем в Legacy и не пахло.
Во время работы над новой версией игры, разработчики изо дня в день подвергались травле со стороны сообщества, все твердили одно и тоже «Старый раст доделывайте! Нам там всё нравится, вот только пару багов исправьте и читеров уберите», объяснить им, что их просьбы были мягко говоря идиотскими было сложно, поэтому разработчики просто начали вести «Еженедельный блог разработки», в котором еженедельно отчитывались о проделанной работе. Самый первый был написан 28 марта 2014 года, в котором Гарри подробно описал, почему же ничего не обновляется в старой версии.
Из недели в неделю игра развивалась и результат работы есть, кто бы что не говорил.
Изучив Dev-блоги в хронологическом порядке — только глупец не заметит проектного роста и относительное ускорение разработки игры. Что уже говорить содержании блогов «тогда» и сейчас.
И вот, после не короткого рассказа мы можем сравнить две версии игры.
То какой раст мы видим сейчас, это долгий и насыщенный путь разработчиков, показывающий, что несмотря на хейт со стороны, своим желанием и упорством можно достичь небывалых высот. Но расслабляться разработчикам еще рано. К великому сожалению раст, как и любая другая популярная игра, имеет изъяны в виде читеров и макроссников.
Я надеюсь, что этот формат видео вам понравился и прошу вас оценить это видео лайком или дизлайком и конечно же перейти по ссылочки в описании на мой канал. Там много чего вкусненького и интересного.
Всем удачи и пока!)
Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
Rust — это язык системного программирования, создатели которого уделили внимание трем вещам: параллелизму, скорости и безопасности. И хотя Rust считается молодым языком программирования — его первая стабильная версия вышла в 2015 году — он разрабатывается уже более десяти лет.
Сегодня мы бы хотели заглянуть в прошлое и рассказать историю языка Rust, показать, как изменились его функции и возможности за время разработки и привести конкретные примеры внедрения этого ЯП на практике.
Личный проект (2006–2010)
Технология из прошлого, которая призвана спасти будущее от самого себя
— Грэйдон Хор (Graydon Hoare), разработчик Rust
Это одна из цитат Грэйдона Хора, которую озвучил Стив Клабник (Steve Klabnik) из команды разработчиков проекта Rust во время своей презентации на конференции ACM в 2016 году (слайды к презентации вы можете найти по ссылке, а для того, чтобы перемещаться между слайдами, используйте стрелки на клавиатуре). Эти слова хорошо отражают тот факт, что Rust — не революционный язык, имеющий передовые функции. Он просто включает в себя множество рабочих методов из «старых» языков (в том числе C++), повышая их безопасность.
Занимаясь языком, Грэйдон установил определенные правила. Он отмечал, что в первую очередь необходимо уделять внимание семантике языка, а работа над синтаксисом — это последнее дело. Поэтому в ранней реализации Rust ключевые слова были не длиннее пяти символов — язык был «кратким» и использовал такие операторы, как log, ret и fn.
Например, первый код на Rust, который увидел свет, выглядел так:
Как отмечает Стив Клабник, со временем это ограничение было снято: часть ключевых слов «удлинили», например, ret превратился в return, а часть заменили совсем. Для сравнения, в современной реализации языка вывод строки «Привет, мир!» выглядит так:
Также за время эволюции часть концепций и ключевых слов языка была убрана. Когда над языком работал Грэйдон, Rust был объектно-ориентированным и использовал оператор obj для описания объектов. Сейчас как таковое ООП языком не поддерживается, но Rust дает возможность реализовать многие его понятия с помощью абстракций.
Rust также работал с функциями параметрического полиморфизма. Концепции обобщенного программирования в языке сохранились и сейчас (оформление кода вы можете найти в этом документе), однако десять лет назад для обозначения типа параметров использовались квадратные скобки:
Самостоятельно над Rust Грэйдон работал на протяжении четырех лет. За это время ему удалось воплотить в жизнь примерно 90% задуманных функций (часть из которых имела довольно грубую реализацию). Среда для выполнения кода была завершена на 70%. Всего за это время Хор написал 38 тыс. строк кода для компилятора на OCaml.
Переход к Mozilla (2010–2012)
Я не считаю, что у языка должны быть какие-то главные особенности.
Он должен состоять из набора понятных и надежных модулей, которые хорошо «работают» в комбинации друг с другом
— Грэйдон Хор (Graydon Hoare), разработчик Rust
По прошествии четырех лет, Грэйдон решил показать свой прототип менеджеру в Mozilla. В компании проявили интерес к проекту, поскольку искали инструмент для перестройки стека браузера на более простых технологиях, чем C++. Поэтому в компании создали команду (во главе с Грэйдоном) для работы над Rust, который стал основой браузерного движка Servo.
Тогда движок Mozilla не мог полноценно работать с мультиядерными системами, поскольку имел однопоточные схемы обработки контента. Например, однопоточными были функции формирования содержимого окна и запуска JavaScript. Rust позволил разделить код рендеринга на мини-задачи, выполняемые параллельно и экономящие ресурсы центрального процессора.
Кроме ускорения работы за счет распараллеливания операций, Rust позволил повысить защищенность браузера. На тот момент Firefox был реализован на C++ и содержал 4,5 млн строк кода. C++ — это «точный» язык программирования, требующий повышенного внимания к деталям, поэтому ошибки программистов могли приводить к возникновению серьезных уязвимостей. Задачей Rust стало снижение влияния человеческого фактора с помощью компилятора.
В 2010 году разработчики языка сменили используемый до этого компилятор OCaml на компилятор, написанный на Rust. В 2011 году Грэйдон опубликовал сообщение о том, что компилятор сумел успешно «собрать» сам себя, а в 2012 команда Rust объявила о релизе альфа-версии компилятора — его документация была не полной, а скорость создания билда оказалась далека от идеальной, однако он уже поддерживал большинство функций языка и кросс-компиляцию.
Годы typesystem (2012–2014)
Наша целевая аудитория — «разочарованные разработчики C++»
В этот момент Грэйдон отошел от работы над Rust и переключился на другие проекты. Как рассказывает Стив Клабник, после этого система управления стала более «распределенной». Была сформирована федеративная структура, в которой за изменения, вносимые в разные части проекта, отвечала отдельная группа разработчиков.
Команда продолжила расти, и в ней стали появляться люди, разбирающиеся в сложных системах типов. Поэтому началось активное развитие typesystem, и все больше аспектов языка выносились в библиотеки.
Например, на ранних этапах Rust был реализован «сборщик мусора» (GC — Garbage Collector), который Грэйдон внедрил для повышения защищенности памяти. Однако потом разработчики пришли к выводу, что они могут обеспечить тот же уровень надежности с помощью системы типов, и от GC отказались.
Это решение также сказалось на системе указателей, используемой в Rust. До удаления «сборщика мусора» в языке было три основных указателя:
Период с 2012 по 2014 год — это время, когда сообщество Rust начало обретать форму. В нем образовалось три больших «лагеря»: пользователи C++, пользователи скриптовых языков и функциональные программисты. Их экспертиза повлияла на язык — постепенно он стал сочетать в себе парадигмы функционального и процедурного программирования.
В марте 2014 года также был сформирован RFC-процесс, который использовался для представления значимых изменений в языке. Решение строилось по образу и подобию Python PEP, и сейчас в нем сделано 3 тыс. коммитов. Причем в RFC попадает любое изменение, даже вносимое разработчиками. По правилам команды Rust, никто не может вносить крупные изменения, не обсудив решение с сообществом.
Релиз (2015)
Мы не знаем наверняка, что из этого получится
В начале 2015 года была выпущена версия Rust 1.0 Alpha. В ней стабилизировали ядро языка, развили систему макросов, и, наконец, закрепили за целочисленными типами int и uint названия isize и usize. В начале второго квартала того же года Rust 1.0 перешел в бету — к этому моменту репозиторий crates.io имел 1700 крэйтов (структурная единица компиляции), а количество скачиваний из репозитория превысило один миллион.
В мае 2015 года состоялся официальный релиз — Rust 1.0. Это ознаменовало начало стабильности. С этого момента все вносимые изменения должны были иметь обратную совместимость, что позволило использовать Rust в реальных проектах. Он начал находить применение в таких сферах, как game dev, веб-разработка и разработка операционных систем.
Переход в продакшн (май 2016)
Если язык хорош лишь в чем-то одном, то это — провал
В 2015 году площадка StackOverflow провела опрос среди разработчиков, в котором их попросили отметить, с какими языками программирования они работали и с какими хотели бы познакомиться. Тогда Rust занял третью строчку рейтинга. Однако годом позднее он переместился на первое место — 79% пользователей изъявили желание продолжить работу с ним.
Один из резидентов Hacker News назвал главными достоинствами языка прозрачность и простоту документации. Другие пользователи также отмечали открытость и доброжелательность Rust-сообщества, которое всегда готово помочь с изучением особенностей ЯП.
При этом многие разработчики решают продолжить работу с этим языком из-за его механизмов безопасности. Как сказал один из пользователей Reddit: «Программирование на Rust — это как паркур со страховкой и в защите; иногда это выглядит странно, но вы можете делать многие трюки, не боясь сломать себе что-нибудь».
С момента релиза стабильной версии Rust начался период его полноценного использования в продакшн. Одной из первых компаний, которые применили Rust в своем проекте, стала Mozilla. Часть «внутренностей» Firefox 45 для Linux были переписаны на Rust, а начиная с версии Firefox 47, Rust-код присутствует и в версии для Windows. Их Project Quantum, анонсированный в октябре 2016 года, также имеет в своем составе компоненты Servo.
Rust используется и в Dropbox — на этом ЯП написано ядро их продукта. Компания Dropbox создала свое новое облачное хранилище Magic Pocket, в которое перенесла информацию с Amazon S3. Изначально оно было реализовано на языке Go, но при больших нагрузках проблемой становилось высокое потребление памяти и низкая предсказуемость поведения кода на Go. Для решения этих проблем был частично задействован Rust.
В прошлом году использовать Rust для обработки пакетов JavaScript начали в npm. Rust помог исключить задержки в системе, работающей с 350 миллионами пакетов в день. Специалист службы поддержки npm Эшли Уильямс (Ashley Williams) рассказывала об опыте использования Rust на конференции RustFest в Украине. Видео вы найдете по ссылке.
Rust также используем и мы в компании Bitfury. На этом языке программирования реализован наш фреймворк для создания блокчейнов Exonum. Впервые мы представили платформу на конференции RustFest 2017, где показали её возможности и провели воркшоп, на котором продемонстрировали работу сервиса по созданию криптовалют (краткое руководство о том, как создать криптовалюту на Exonum вы можете найти здесь).
Реализация на Rust оказалась кстати при работе со смарт-контрактами. Благодаря этому умные контракты Exonum имеют большую производительность, чем контракты Ethereum (или Fabric). Код платформы полностью открыт и лежит в репозитории проекта на GitHub.
Rust также находит применение в сфере информационной безопасности. Такие проекты как Tor уже переносят часть кода на Rust.
В целом, сегодня Rust в своих продуктах используют 105 компаний. Полный их список (в котором также отмечена и Bitfury Group) можно найти на странице Friends of Rust на официальном сайте. И количество компаний, создающих программные продукты на Rust, постоянно увеличивается, чему разработчики языка очень рады.
Ржавеем дальше. Как появился Rust и можно ли на нём WEB?
Моя предыдущая статья про rust вызвала положительную реакцию и большое количество обсуждений о том что да как с rust. Мне исключительно приятно видеть что вам понравился этот материал.
В комментариях я встретил много вопросов типа «А можно ли использовать rust для WEB?» Лаконичный ответ таков: «Можно». Можно и brainfuck использовать, если хочется. Нужно ли? Скажем так, brainfuck для WEB использовать категорически не стоит. А вот rust – тут надо понимать что именно делает rust и каковы его цели. Для того чтобы это понять мы должны погрузиться в компилятор и разобраться в устройстве процессоров. Под катом вы найдёте глубокий заныр в историю того как появился rust и поймёте что это такое и когда его нужно использовать а когда можно и на «ноде запилить».
Акт номер 0, Вступление
Ок. Мне довелось обучать программистов вот уже как 10 лет. Я видел разный народ. Кто-то приходил ко мне с вопросами о том, как компилятор оптимизирует код с поддержкой MMX в процессоре, а кто-то спрашивал, можно ли скомпилировать код на Java в С#. Разница между первыми и вторыми – это понимание того как работает процессор.
В этот момент большинство из тех кто учился программировать по ютубу просматривая видео из серии «Как скачать генератор to-do list на node.js, React, brew, JSX, Pug, LESS за 10 секунд» начинают убегать. Не бойтесь. Я попытаюсь всё объяснить по-человечески. Конечно, есть на хабре и те, кто могут открыть бинарный файл в HEX, посмотреть на 7а 45 4с 46 01 01 01 00 и сказать: «Да этож линуксовский бинарник!» Таким не обязательно читать дальше.
Акт номер 1: Процессор
Всё начинается с процессора. Когда вы достаёте себе новый Intel Core i9 из коробки и смотрите на инструкции которые к нему прилагаются, вы найдёте пару страниц описания того как запилить новый камень на маму. Но вот настоящие инструкции к процессору вы в коробке не найдёте.
На сайте Intel вы всегда можете слить свежую копию мануала. Качайте на здоровье, он бесплатный. В нём 50 мегабайт и 5000 страниц. Ого. Ага. Процессор—это достаточно сложное устройство. Это только часть мануалов по процессору. Скачать можно больше.
Хорошо, заставить вас прочитать книгу в 5000 страниц будет не просто. Я буду говорить упрощениями.
Что такое процессор? Это компонент который выполняет арифметические, логические и другие команды ввода-вывода. Процессор это основной компонент в вашем компьютере.
Как заставить процессор выполнить команду? Передать процессору на вход код этой команды и параметры, которые вам нужны.
Процессоры обычно оснащены регистрами. Это определённый набор ячеек памяти который находится очень близко к ядру и позволяет процессору выполнять манипуляции с этими ячейками. Операции могут быть арифметическими и логическими. В процессорах интеловской архитектуры регистры обычно называют буквами по порядку.
Ок, то есть сейчас мы можем записать что-то в AX, прибавить к этому то что в BX, сравнить это с каким-то числом, и если результат сравнения был больше чем это число, перепрыгнуть в другой участок программы. Так раньше писали программы.
В дополнение ко всему этому процессор может запросить данные из оперативной памяти. С точки зрения процессора память очень медленная. Посему можно запросить данные из памяти и поместить их в кеш. (Которого на современных процессорах от 2х до 32х+ мегабайт). Кеш он быстрее оперативной памяти, но всё же медленный.
Хорошо, мы можем получать данные, изменять их и сохранять их в памяти. Если мне надо выполнить одну операцию сложения в каждой ячейке памяти в объёме 1 мегабайт, то есть это я должен выполнить эти команды (1x1024x1024) 1,048,576 раз? Да. Миллион раз. Процессор, работающий на частоте 2 гигагерца выполняет примерно 2,000,000,000 команд в секунду. То бишь, это миллион раз ему можно сделать 2000 раз в секунду. Неплохо.
Но со временем задачи становятся более и более сложными, и процессоры усложняются с этими задачами. Что если мне надо сделать эту операцию миллиард раз в секунду? Например современная игра в разрешении 4к выводит на экран 33,177,600 пикселов. Это надо выводить 60 раз в секунду. 33,177,600×60 = 1,990,656,000. Хаха. Это почти два миллиарда пикселов в секунду. А для того чтобы всё это обработать потребуется чуть больше чем просто прибавлять и отнимать значения из ячеек регистров. (На самом деле с видеоиграми всё становится ещё интереснее, потому что нынче над этой картинкой будет работать не только процессор, но и, понятное дело, видеокарта, которая содержит в себе кучу этих процессоров).
Ладно, вопрос понятен, как сделать так, чтобы процессор выполнял ещё больше инструкций в одну единицу времени? Создатели процессоров начали добавлять различные примочки типа SSE. Это набор инструкций который ускоряет воспроизведение видео. (Вернее ускорял. SEE это древняя технология. Сейчас, в большинстве случаев, видео занимается видеочип. Но SEE остались). Что можно делать с этими инструкциями? Ну, например, можно запихнуть сразу 16 значений в определённые 16 регистров и выполнить одну команду на всех 16ти за один такт. Удобно.
Современные процессоры имеют дополнительные модули для работы с видео, шифрованием, нейронными сетями и так далее. Таких примочек – пруд пруди. Посему и мануал на 5000 страниц.
Ну так вот, мы теперь примерно знаем как можно прочитать значения из памяти, как можно ими манипулировать и как положить всё это обратно. Но мы ничего из этого не можем передать пользователю. Да и получить от пользователя это мы тоже не можем.
На помощь приходят прерывания. Это специальные команды процессора, которые позволяют остановить выполнение программы и заняться чем-нибудь другим. Есть на хабре замечательная статья «О работе ПК на примере Windows 10 и клавиатуры». Эта статья в мельчайших деталях рассказывает о том, как сигнал от клавиатуры попадает в память где до него может добраться процессор. По такому же методу процессор может записать данные в видеопамять, и видеоадаптер нарисует эти данные на экране.
Всё просто, чики-пуки, правильно? Ага. Мы только что видели опкоды команд для одного кристалла Intel. А есть ещё, например, процессоры компании AMD. У них основной набор команд практически такой-же как у Intel, но вот примочки у них были свои. А есть ещё и другие процессоры, в которых набор комманд полностью отличается от того, что мы видели в Intel. Пример тому – мобильные процессоры. У них и архитектура другая.
То есть, если ты хочешь писать программу на опкодах, то тебе её придётся писать для каждого процессора, на котором эта программа будет запускаться. Что, удобно? Не очень. Да, это достаточно ресурсоёмко. Сидеть и запоминать эти опкоды и пихать их в процессор? Неужели кто-нибудь может запомнить всё это? (Я могу поспорить, что определённый процент хабравчан тут усмехнётся и начнёт вспоминать эти опкоды).
Акт номер 2: Ассемблер
Ладно, не боись. Всё это решили за тебя ещё в древности. Уже в 60х годах знали, как с этим разобраться. Для начала, почему бы не заменить численные опкоды чем-то более человекочитаемым? Например, использовать mov вместо 0x06. Так появился первый ассемблер. Программа на ассемблере выглядит вот так:
Ещё одна полезная фича компилятора это оптимизация вашего кода под определённый процессор. Например, если компилятор собирает программу под Intel, то он может автоматически заменить более простые и медленные конструкции, которые ты использовал в своей программе, более сложными командами под процессор Intel или AMD или что ты там используешь.
Основной плюс такого подхода заключался в том, что одна и та же программа написанная на ассемблере могла быть собрана для разных процессоров. То есть тебе не надо было всё переписывать заново. Победа!
Но как бы не был хорош такой подход, писать на ассемблере всё ещё занудно. Посему древние решили всё это упростить и улучшить и начали заниматься разработкой языков программирования. Один особо примечательный язык, который начал свою жизнь в 60х до сих пор живёт и процветает и по сей день это С.
Акт номер 3: Сиииии и Сипипииии
Чем же С был так хорош? Ну, давайте заменим определённые последовательности ассемблеровского кода более удобочитаемыми командами. Например, если мы хотим сравнить два числа и выполнить разный код по результатам этого сравнения, то мы можем заменить это
Ваш код становится намного более удобочитаемым. Плюс мы все знаем, что считывать данные с клавиатуры и писать данные на экран это то, что практически всякая программа будет делать по умолчанию. Посему мы можем написать стандартную библиотеку команд, которые будут доступны каждому, кто пишет на С.
После всего этого мы передаём нашу текстовую программу компилятору, который собирает эту программу в объектный файл. Этот объектный файл передаётся linker (линкеру), который прикручивает ваш код куда надо.
Так, стоп, а это откуда здесь взялось? Куда чего надо прикручивать? Так, ты в своём коде использовал printf? Да, использовал. Код printf это часть стандартного набора команд. Этот код – функция, которая была скомпилирована в отдельный объектный файл. Когда ты эту функцию вызываешь надо чтобы твой программный код заставил процессор прервать выполение твоей программы, выяснить, где в памяти находится printf, выставить регистр исполняемой команды процессора в определённое значение и вызвать нужное прерывание, чтобы процессор бросил твою команду и ринулся выполнять printf. После выполнения процессор должен вернуться к твоей программе. Опять прыгание по памяти и всё такое.
Писать всё это руками было бы очень муторно, но линкер решает эти проблемы. Он собирает все объектные файлы (куски исполняемой программы) в один большой исполняемый бинарник. Выясняет все имена функций и проставляет все адреса в памяти как надо. Тобишь всё складывается воедино линкером и он выдаёт тебе в руки один исполняемый файл. Ты его клик-клик и программа запускается!
Чем же так хорош С? Тем что он был достаточно прост, стандартен и позволял быстро писать программы не заморачиваясь тем, как работает ваш процессор. Компиляторов (обычно под этим понимается компилятор+линкер) для С было написано столько, что ныне их уже не счесть. С всегда был стандартным языком. В нём точно говорится, что если в программе написано if то в итоге код должен делать такое-то ветвление. (А если в программе написано봎볈볬, то твой код должен выпускать демонов из ноздрей.) Посему, если вы написали программу для своего любимого, на тот момент компьютера PDP-11, то её можно было бы скомпилировать и на нынешнем Intel Core i11.
Ух ты! Вот тут у нас и появляется концепт программы, которая пишется не для определённого процессора, и даже не для определённой операционной системы. Такую программу можно запустить на всём что под руку попадётся, главное чтобы у вас в руках был компилятор.
И компиляторы были и есть. Их в С более 50ти популярных. Просто утопия. Типа того. На самом деле, не всё ТАК уж прям утопично. Код, написанный для 32х битных систем может скомпилироваться, а может и не скомипилироваться на 64х битных системах. А вот код который дёргает 64х битные функции точно рухнет на 32х битных системах. Это ещё что. Windows, unix и MacOS имеют разные подсистемы управления памятью. Что-то может заработать на маке и выдать замечательное приветствие на винде:
Ну, эти проблемы в С решили. У нас есть система под названием makefile. Это программный комплекс который управляет процессом компиляции. Когда файлов у вас в проекте сотни и последовательность компилирования может меняться, когда надо сделать так чтобы система собиралась по-разному на Windows и Unix или проверяла, если сборка делается на 64х разрядном компьютере, вы пишите makefile.
Всё это становится очень утомительным. В добавок ко всему, С хорош в написании функций, но вот мы-то работаем с объектами. Посему пришлось писать улучшенную версию С, которая называется С++. Плюсы позволили создавать тръу ООП программы с классами, бллк-джеком и куртизанками. (Уж простите меня на ужасное утрирование. Разница между С и С++ достойна не то что отдельной статьи, можно будет и книгу написать. Но статья-то про rust, так что мы будем опускать детали.)
Акт номер 4: Ява и дотнет
Акт номер 5: Яваскрипт
Но тут можно пойти ещё дальше. Зачем компилировать код вообще? Почему бы просто не выполнять инструкции одна за другой? Так и сделали. Так появился javascript.
Код не компилировался вообще. Каждая строка программы последовательно читалась одна за другой и выполнялась как есть. Всё это было вообще шикарно. Никакой мороки с компиляторами, процессорами и оптимизацией. Код просто выполняется.
Но, со временем, мы начали понимать, что javascript должен не только выполняться, но выполняться быстро. Посему программу, которая запускает ваш скрипт начали пилить. Всё это началось с войны браузеров в далёких 2000х. Тогда самым-самым браузером был Internet Explorer 6. Он победил всех. На сцену вышли Mozilla и Google. Началась война. Все боролись за скорость работы сайтов. Javascript начал компилироваться для ускорения производительности. Появились движки для javascript. V8, движок из Google Chrome, в итоге победил всех и вся. Осталось дождаться, когда Firefox переключится на него и вторую войну браузеров можно считать закрытой.
После этого какой-то умелец взял V8 и запилил на нём Node.js. Зачем запускать javascript в браузере? Можно и без браузера. Научился писать на скриптах – пиши на них и серверную часть.
В итоге у нас появилась новая платформа. Вам, как разработчику, вообще чихать на процессор, который установлен на клиенте. Вам чихать на размер экрана и операционную систему. У вас есть доступ к странице, на которой всё это запускается и всё! Победа. Один код запускается на абсолютно разных машинах с максимальной скоростью.
Конечно, компьютеры становятся мощнее и мощнее с каждым годом, и если в 1990х мы могли рассчитывать только на 8,000,000 операций в секунду, то в 2010 мы уже говорили о 3,000,000,000 в секунду. А сейчас мы хоть и опустились до 2,000,000,000, но зато у нас у всех под капотом по 8-16 ядер, которые выполняют эти операции одновременно, да ещё и видеоадаптер, который дополняет всю эту армию вычислительных машин. Так что, по большому счёту нам на скорость начхать. Какая разница если мы получим данные и покажем их на экране за 25 миллисекунд или за 250 миллисекунд? Пользователь всё равно не заметит разницы.
Так и есть. Только это в ваших бизнес-приложениях он не заметит разницы. А вот если вы пишете игру, то разница между 25-ю и 250-ю миллисекундами очень даже заметна. Просто жесть как. Посему приходится выбирать.
Акт номер 0x00000000: Память
Хорошо, мы видели историю того, как изменялся подход к написанию программ и почему он изменялся. Единственный момент, на который мы не смотрели – это память. Этот момент является очень важным.
В древности ваша программа (в большинстве случаев) запускалась на процессоре как полновластный владелец всей системы. Вы могли обратиться к любому участку памяти, писать и читать из этого участка памяти и делать что вздумается. Этот подход был прост и ужасен. Вы могли в любой момент изменить память, которой пользовалась другая программа на компьютере. Решили сохранить в памяти огромную картинку с разрешением 320х240? Упс! Неправильно прописанный указатель переписывает содержание функций операционной системы, и вместо красивого изображения вы получаете полное зависание системы (если повезёт, если не повезёт, можно заодно и диск отформатировать).
Вирусы в те стародавние времена писались только так. Почему бы не перехватить функцию в DOS, которая пишет данные на диск? Да проще простого! Перехватывай. Диски стирались, криптовались и чего только не делались. Делов-то.
Со временем разработчики процессоров начали бороться с этим кошмаром путём усложнения модели работы с памятью. С 1985х в процессоры начали встраивать новый «защищённый режим» работы с памятью. Вместо того чтобы позволять каждой программе работать с памятью напрямую, программе предоставлялся интерфейс, для того чтобы запросить виртуальную память и работать с этой памятью. Память была виртуальной, потому что эта память не гарантировала выдачу вам блоков RAM с шестой по девятый. Вы просили систему дать вам полкило памяти, вы её получали. Когда ваша программа писала в эти полкило памяти, операционная система уже разбиралась что с этой памятью делать. В какой конкретно чип в RAM эти ваши данные положить. А если вы этими данными не пользовались, то система могла их и сбросить в Swap.
Самое главное, ваша программа получала свой виртуальный адрес, а система гарантировала, что никакая другая программа в этот кусок памяти писать не будет. В том числе система гарантировала, что другие программы в вашу память писать не будут. Всё работало просто замечательно:
Вся эта беготня с памятью создала необходимость управления этой памятью. Ваша программа на C должна получить память, обращаясь к операционной системе. Система вам эту память выдаст. А может и не выдать. Результат зависит, но скорее всего, будет такой вот:
После того как вы эту память получили вам нужно её «инициализировать», то бишь записать туда начальные значения переменных, которые вам нужны. Иначе вы могли получить кусок памяти, в которой валялся какой-то мусор.
Оффтоп: У Буратино было пять яблок. Он съел два. Сколько яблок осталось у Буратино? Думаете три? Фиг вам. 32764! Память кто будет инициализировать при работе с переменными?
А теперь самое прикольное – каждый раз, когда вы попросили у системы память, эта память будет оставаться вашей, пока не будет сделано одно из двух: либо вы эту память отдадите системе обратно, либо вы завершите программу, и тогда вся ваша память освободится.
Что же, это просто, так ведь? Если попросили полкило памяти, то и отдайте полкило памяти. Делов-то. А что если вы попросили полкило памяти и отдаёте её обратно кусками по 10 килобайт? И вот, 2 куска в самом конце не отдали (забыли, поставили неправильный знак сравнения в цикле и последние два куска остались за вами). А потом вы попросили ещё полкило, то есть теперь ваша программа занимает 520 килобайт. И опять отдаёте её кусками и 2 куска не отдали? Теперь у нас 40 лишних килобайт. Результат:
Такая штука называется утечкой памяти. И, в результате, вы сидите в 4 утра с красными глазами перед отладчиком и орёте благим матом «Ну где эта с_ка течёт?»
А ещё есть один прекрасный трюк, как насчёт того, чтобы попросить память у системы, а потом удалить указатель на эту память? В таком случае вы эту память и вернуть обратно не сможете. Результат?
А ещё можно обратиться к памяти по адресу 0x00000000 (нулевой адрес). Результат?
Короче вы поняли. Работа с памятью требует тщательного планирования и правильного управления. Любой программист на С и С++ обязательно проверит каждую функцию запроса памяти и убедится в том, что ничего нигде не течёт. Чем сложнее становится проект, тем сложнее эту память проверять. Появляются другие инструменты проверки. Например, знакомая каждому хабровчанину PVS-Studio. Статический анализатор, который может половить баги памяти в вашей программе.
Программист, помни, работа с памятью – это очень тяжёлая ответственность. Ладно. Это всё решили в Яве и Дотнете.
Акт номер 0xFFFFFFFF: Meet Garbage Collector
Автоматический сборщик мусора! Зачем вообще программисту выделать память? Почему бы просто не сделать так – когда он создаёт переменную, пусть платформа сама возьмёт память с полочки. А когда переменная больше не нужна (программист выкинул все указатели на эту переменную) то отдельная программа которая запускается параллельно с вашей программой, называемая сборщик мусора, возьмёт и сотрёт эти данные из памяти.
Всё просто прекрасно и хорошо. Но… Проблема в том, что сборщик мусора не всегда так уж и хорош и может создать ситуации, когда мусора становится слишком много. Когда ваше бизнес-приложение заточено на показ трёх значений курсов валют на экране, то сборщик мусора работает просто прекрасно. А вот если вы пытаетесь сделать ленту из видео файлов с «бесконечным скроллом» то сборщик мусора может запросить 8 гиг памяти у системы и конкретно всё затормозить.
Идея сборки мусора перекочевала в javascript. В общем-то, это не очень плохая идея. Она просто накладная. У вас запускается не только ваша программа, но и программа, которая следит чтобы ваша программа нормально работала.
Акт номер 6: LLVM
Ладно, наступили двухтысячные. Ява с Дотнетом борются за лидерство. Яваскрипт завоёвывает серверную часть. А вот Си с плюсами начинает трясти. Проблема заключалась в том, что количество компиляторов перевалило за исчислимые пределы и теперь считается иррациональными числами. На сцене существуют тяжеловесы – Microsoft C++ Compiler и GNU C. Не то, чтобы эти компиляторы «воевали» друг с другом, войны между ними быть не может, ибо они рассчитанны для абсолютно разных систем.
И тут на сцену выходит Apple, которая пытается сделать «всё для себя». Проблема вот в чём, самый популярный компилятор C для Unix-систем это gcc. Apple приходится использовать этот компилятор в своих продуктах, но лицензия GNU, которая идёт в добавку с этим компилятором накладывает жёсткие ограничения на политику яблоководов о том, чтобы сделать всё проприетарным. (Ежели вы берёте открытое программное обеспечение под лицензией GNU и дорабатываете его, вы обязаны оставить исходный код открытым.)
И тут внезапно в 2003 году выскочка из университета Иллинойса показывает миру свою лабораторную работу под названием LLVM. Это название ничего не значит. Просто название. Что это за зверь такой?
Это новая система компиляции. LLVM предоставляет доступ к очень низкоуровневому языку программирования который позволяет писать что-то типа ассемблера, только опять же, отрешенного от реального процессора. Этот код компилируется для конкретной платформы. На выходе мы получаем настоящий, чистокровный бинарник для конкретной системы без всяких фреймворков и тому подобных вещей.
Вместе со всем этим выходит clang. Это компилятор для Си-образных языков, который собирает Си и С++ в LLVM код. То есть ваши программы на C можно запросто пропустить через этот компилятор. А на выходе у вас есть поддержка Windows, Linux, MacOS для кучи процессоров: х86, х86-64, PowerPC, ARM, AArch64 и тд. И самое главное – Apache 2.0 лицензия, в которой выпускать модифицированный код необязательно. То есть, Apple смогла взять этот LLVM и сделать его проприетарно-закрытым! Из инструментов разработки Apple пропадает GNU компилятор и его заменяет LLVM компилятор, который отлично компилируется в байткод для LLVM, который в своё время отлично собирается под Apple.
Благодаря такому вниманию гиганта, проект получает поддержку и начинает развивать обороты. Хочешь написать свой язык? Пожалуйста! Пиши язык, который генерирует байт-код для LLVM, а мы его скомпилируем. Тебе не надо писать компилятор. Он уже есть. Просто пиши язык.
Акт номер 7: И где же rust?
И тут появляется rust. LLVM был просто средой компиляции. Работа с памятью как была проблемой программиста, так ею и осталась. Но ребята из Mozilla решили попробовать что-то новое. В 2010 они написали новый язык программирования, который использовал LLVM как компилятор.
Язык был си-образным и очень низкоуровневым. В нём не было примочек в виде сборщика мусора или фреймворка на 200+ мегабайт.
Но в язык была зашита принципиально новая система работы с памятью. Вместо того чтобы плодить БСОДы направо и налево, вам был дан borrow-checker. (Проверяльщик заимствования? Я не знаю, как правильно это перевести. Я его так и буду называть borrow-checker). Вшитый прямо в компилятор. Подход заключается в следующем: вы пишите код как будто у вас есть сборщик мусора. Вы просто объявляете строку и память для неё появляется автоматически. А после того как вы эту переменную используете, память освобождается сама по себе.
Но это всё не происходит потому что у вас есть сборщик мусора. Компилятор сидит и запихивает куда нужно команды, которые запрашивают память у системы и освобождают эту память. Это не создаёт проблем с производительностью, ибо сходный код на С был бы так же быстр. Вам всё так же пришлось бы запрашивать память и освобождать её. Разница в том что вам не надо постоянно смотреть на БСОДы и Appcrash repots. Компилятор даст вам знать, что вот тут, в строке номер 10 у вас есть потенциальная ошибка памяти. Так что сидите и правьте.
Следующая важная фича rust называется zero-cost abstractions. Это подход к разработке языка. Если вы даёте пользователю какую-то специальную функцию, то это функция не должна ничего стоить.
Когда вы создаёте новый поток в rust, то он не будет «тяжелее» fork(). Может быть в вашем коде вы увидите следующее:
Выглядит это всё круто, но под капотом этого странного способа создавать замыкания в rust (||) вы найдёте fork(). Rust сам по себе не будет писать менеджер потоков за вас. Посему, писать всё придётся самому. Если тебе нужен менеджер соединений с базой данных, пожалуйста, вот тебе чистый лист, пиши. (Либо ищи и качай его с crates.io)
Что мы получили в итоге? Rust это язык, который является относительно быстрым и не нуждается в гигантском фреймворке, который надо таскать с собой на конечную систему пользователя. Он позволяет вам предотвратить ошибки управления памятью в процессе написания программы. Вариантов словить утечку намного меньше. Всё прекрасно, так?
Да. Всё прекрасно. Но rust это не простой язык для изучения. Вам надо очень хорошо разбираться в архитектуре компьютеров и понимать как на самом деле работает память. Вам надо хорошо знать системное программирование и иметь хорошее представление о том как работает heap и stack в операционной системе. Rust не прощает ошибок. Но, в отличие от C и C++, rust не прощает ошибок с памятью на этапе компиляции.
Итог: Rust это хороший язык в сообществе Cи-образных языков, который позволяет писать удивительно быстрый код и предотвращает большое количество ошибок работы с памятью.
Акт номер 0xFE: Заключение
Как мне выбрать язык для своего проекта? Вы должны знать свой проект. Какова нагрузка на ваш проект? Сколько он проживёт? Сколько ему надо жить? Как долго и кто его будет поддерживать?
На самом деле – это те вопросы, на которые вам надо ответить. Если вы пишете скрипт, который вы выкинете через 2 дня, пишите его на чём попало. Главное, чтобы не в продакшин.
Если вы пишете драйвер для нового устройства, то можно попробовать rust. Если вы действительно пишите драйвер, то вы уж точно знаете как правильно работать с памятью и весь этот трёп про ассемблер выше по тексту для вас будет детским лепетом.
Играетесь с новым адуриноподобным устройством на ARM? Попробуйте rust! Будет весело.
Если у вас есть WEB приложение, которое должно работать на одном сервере и обслуживать 200 человек в вашей организации, то вам будет достаточно node.js. На нём писать проще. Когда компания вырастает до 2000 человек, то надо уже серьёзно подумывать про переход на шарпы или яву. Но когда аудитория сайта переваливает за 200000 человек, то мы можем говорить о переходе на rust.
Или вот, например, у вас есть docker контейнер, в котором у вас вертится микросервис написанный на Java. Этот «микросервис» занимает 200+ мегабайт места на жёстком диске. С использованием C или Rust вы могли бы это сократить до 20 мегабайт. Обновление и запихивание всего этого дела на серверы может прилично сократить трафик.
На rust написаны куски кода для Discord, Microsoft Azure IoT Engine, Open DNS, Firefox, Linux Kernel, и тд.
Для кого rust? Для суровых бородатых системных программистов, которые хотят скорости и готовы часами проектировать своё программное обеспечение с учётом потребления памяти и производительности. Написание игр или компонентов рендеринга, драйверов устройств и так далее – это удел rust.
Следует оговориться, что если вы будете работать с WebAssembly (wasm), то вам точно нужно попробовать rust. Так как код, генерируемый rust использует LLVM, а LLVM может компилировать в wasm, использовать rust для этих целей будет просто удовольствием.
Написание WEB приложения на rust это не обязательно полезная деятельность. Если вы действительно хорошо разбираетесь в системном программировании, и можете писать на С++ с закрытыми глазами, то вам стоит писать WEB на rust. Иначе, вы будете часами сидеть перед функцией, которая принимает параметры возвращаемые из формы, и горько плакать, потому что перед вами будет стоять непосильная задача распарсить эти параметры в JSON.
Акт номер 0xFF: Учимся
Если вы решили учить rust для WEB программирования, но ещё никогда им не пользовались, то для начала я рекомендую выучить rust, читая официальное руководство. Я очень сильно не советую пытаться начать пилить серверную часть на rust если вы никогда ничего на этом языке не писали.
Для начала, напишите хотя-бы парсер текста. Простой grep, например. Потом разберитесь, как эту программу распарралелить. Когда вы научитесь пользоваться областями видимости и без проблем будете создавать замыкания и новые потоки, можно будет переключаться именно на WEB программирование на rust.
После того как язык перестанет быть для вас полной кашей, можете обратиться к “Fullstack Rust” by Andrew Weiss. Я никакого отношения к этой книге не имею, за исключением того, что я её прочитал, и она в деталях объясняет, как правильно писать WEB сервер на rust, как пользоваться wasm и так далее. Не пытайтесь читать эту книгу, если вы ничего про rust не знаете.
А если не хотите обзаводиться этой книгой, что же, не проблема! Мы лёгких путей не ищем!
После этого идём в http://actix.rs и учим его. Это один из самых передовых WEB фреймворков для rust.
Можно выучить rocket – это самый новый WEB фреймворк для rust. Здесь синтаксис проще и работа быстрее. Единственное что мне в rocket не понравилось – это то что он не компилируется на стандартном компиляторе rust и заставляет вас установить nightly билд. Это не очень хорошо для продакшена.
После актикса можно учить http://diesel.rs. Это фреймворк для работы с базами данных.
Попутно выучите serde. Систему сериализации и десереализации данных в rust.
С подобным багажом знаний уже можно написать приличный WEB сервер с базой данных и блек-джеком.
Ну а если вы хотите окунуться в новый мир невероятного wasm то начать надо будет с: https://github.com/rustwasm/wasm-bindgen
В попытках выучить всё это вы наткнётесь на кучу различных пакетов, про которые стоит знать. Натыкайтесь. Будет весело.
Читать дофига, учиться и того больше. Ставим компилятор rust и начинаем эксперименты.