Rust ��������� ���������� mac os

Пять лет Rust

В этом бардаке, который сейчас происходит в мире, легко забыть, что прошло уже пять лет с выпуска 1.0 в 2015 году! Rust за эти пять лет сильно изменился, так что мы хотели бы вспомнить о работе всех участников сообщества, начиная с момента стабилизации языка.

Напомним, если кто забыл: Rust — это язык программирования общего назначения, который обладает средствами, позволяющими строить надёжное и эффективное программное обеспечение. Rust может быть использован в любой области: от ядра вашей операционной системы до вашего следующего web-приложения. Этот язык полностью построен участниками открытого многоликого сообщества, в основном волонтёрами, кто щедро делился своим временем и знаниями для того, чтобы помочь сделать Rust таким, какой он есть сейчас.

Основные изменения с версии 1.0

1.2 — Параллельная кодогенерация: уменьшение времени компиляции всегда являлось главной темой в каждом выпуске Rust, и сейчас трудно представить, что когда-то был короткий период времени, когда Rust вообще не имел параллельной кодогенерации.

1.3 — The Rustonomicon: наш первый выпуск фантастической книги «The Rustonomicon», книги, которая исследует тёмную сторону языка Rust, Unsafe Rust и смежные темы. Она стала прекрасным источником сведений для любого, кто хочет изучить и понять самые трудные аспекты языка.

1.4 — Поддержка Windows MSVC уровня 1: продвижение платформы на уровень поддержки 1 принесло нативную поддержку 64-битной Windows с инструментарием Microsoft Visual C++ (MSVC). До 1.4 вам нужно было устанавливать MinGW (порт окружения GNU под Windows) чтобы использовать и компилировать ваши программы на Rust. Поддержка Windows стала одним из самых больших улучшений Rust за эти пять лет. Лишь недавно Microsoft анонсировала публичный пре-релиз официальной поддержки Rust для WinRT API! И наконец, сейчас стало значительно легче строить высококачественные и кроссплатформенные приложения, нежели это было когда-либо ранее.

1.5 — Cargo Install: добавлена поддержка возможности сборки исполняемых файлов с помощью компилятора Rust вместе с поддержкой предустановленных дополнений cargo породило целую экосистему приложений, утилит и инструментов для разработчиков, которые сообщество обожает и от которых зависит. Cargo теперь поддерживает довольно много команд, которые сначала были просто плагинами, сделанными участниками сообщества и выложенными на crates.io!

1.6 — Libcore: libcore — это подмножество стандартной библиотеки, содержащее только API, которое не требует функций выделения памяти или функций уровня операционной системы. Стабилизация libcore позволила компилировать Rust без выделения памяти или зависимости от операционной системы, что стало одним из первых основных шагов к поддержке Rust для разработки встраиваемых систем.

1.10 — Динамические библиотеки с C ABI: крейт типа cdylib компилируется в динамическую библиотеку с C-интерфейсом, что позволяет встраивать проекты Rust в любую систему, которая поддерживает ABI языка C. Некоторые из самых больших историй успеха Rust среди пользователей — это возможность написать небольшую критическую часть системы на Rust и легко интегрировать в большую кодовую базу. И теперь это стало проще, чем когда-либо.

1.12 — Cargo Workspaces: позволяют организовать несколько проектов Rust и совместно использовать один и тот же lock-файл. Рабочие пространства были неоценимы при создании крупных многоуровневых проектов.

1.13 — Оператор Try : первым основным синтаксическим изменением был оператор ? или оператор «Try». Он позволяет легко распространять ошибку по стеку вызовов. Раньше вам приходилось использовать макрос try! , который требовал оборачивать всё выражение каждый раз, когда вы сталкивались с Result , теперь вместо этого можно легко связать методы с помощью ? .

1.14 — Rustup 1.0: Rustup — это менеджер инструментальных средств. Он позволяет беспрепятственно использовать любую версию Rust или любой его инструментарий. То, что начиналось как скромный скрипт, стало тем, что персонал по эксплуатации нежно называет «химера». Возможность обеспечить первоклассное управление версиями компилятора в Linux, macOS, Windows и десятке целевых платформ была мифом ещё пять лет назад.

1.15 — Процедурные макросы вывода типажей: макросы вывода типажей позволяют создавать мощные, обширные и строго типизированные API без часто повторяющегося кода. Это была первая стабильная версия Rust с которой стало можно использовать макросы из библиотек serde или diesel .

1.17 — Rustbuild: одним из самых больших улучшений для наших контрибьюторов в разработке языка стал переход от начальной системы сборки на основе make на использование Cargo. Благодаря этому участникам и новичкам rust-lang/rust стало намного проще создавать и вносить свой вклад в проект.

1.20 — Ассоциированные константы: ранее константы могли быть связаны только с модулем. В 1.20 мы стабилизировали ассоциативные константы для структур, перечислений и, что важно, для типажей. Это упростило добавление богатых наборов предустановленных значений в типы вашего API, таких как общие IP-адреса или использующиеся числовые константы.

1.24 — Инкрементальная компиляция: до версии 1.24, когда вы вносили изменения в библиотеку, компилятору приходилось перекомпилировать весь код. Теперь он стал намного умнее в плане кэширования, насколько это было возможно, и ему нужно только заново перегенерировать изменения.

1.26 — impl Trait : добавление impl Trait дало вам выразительные динамические API с преимуществами и производительностью
статической диспетчеризации.

1.28 — Глобальные аллокаторы: ранее вы были ограничены использованием аллокатора, предоставленного Rust. Теперь с помощью API глобального аллокатора можно выбрать аллокатор, который соответствует вашим потребностям. Это был важный шаг в создании библиотеки alloc , другого подмножества стандартной библиотеки, содержащей только те её части, для которых требуется аллокатор, например Vec или String . Теперь стало проще, чем когда-либо, переиспользовать части стандартной библиотеки на различных системах.

1.31 — 2018 редакция: выпуск 2018 редакции стал нашим самым большим выпуском языка после версии 1.0, добавив изменения синтаксиса и улучшения в код на Rust, написанного полностью обратно совместимым образом. Это позволяет библиотекам, созданным с разными редакциями, беспрепятственно работать вместе.

• Нелексические времена жизни (NLL): огромное улучшение в анализаторе заимствований Rust, позволяющее ему принимать более проверяемый безопасный код.
• Улучшения в системе модулей: большие улучшения UX в объявлении и использовании модулей.
• Константные функции: константные функции позволяют запускать и вычислять код Rust во время компиляции.
• Rustfmt 1.0: новый инструмент форматирования кода, созданный специально для Rust.
• Clippy 1.0: анализатор Rust для поиска распространённых ошибок. Clippy значительно упрощает проверку того, что ваш код не только безопасен, но и корректен.
• Rustfix: со всеми изменениями синтаксиса мы знали, что хотим предоставить инструментарий, позволяющий сделать переход максимально простым. Теперь, когда требуются изменения в синтаксисе Rust, можно просто выполнить команду cargo fix для решения проблем, связанной с изменениями синтаксиса.

1.34 — Альтернативный реестр крейтов: поскольку Rust всё больше и больше используется в производстве, возникает большая потребность в возможности размещении и использовании проектов в приватных пространствах. Вместе с этим в Cargo всегда разрешены зависимости из git-репозиториев. С помощью альтернативных реестров ваша организация может легко создать и делиться своим собственным реестром крейтов, которые можно использовать в ваших проектах, как если бы они были на crates.io.

1.39 — Async/Await: стабилизация ключевых слов async / await для обработки Future была одной из главных вех в превращении асинхронного программирования в «объект первого класса» Rust. Уже через шесть месяцев после его выпуска, асинхронное программирование превратилось в разнообразную и производительную экосистему.

1.42 — Шаблоны срезов: хотя это было и не самое большое изменение, добавление шаблона .. (остальное) был долгожданной функцией, которая значительно улучшает выразительность сопоставления образцов для срезов.

Диагностики и ошибки

Одна вещь, которую мы не упомянули, это то насколько улучшены сообщения об ошибках и диагностика в Rust с 1.0. Глядя на старые сообщения об ошибках кажется, что это теперь другой язык.

Мы выделили несколько примеров, которые лучше всего демонстрируют насколько мы улучшили сообщения об ошибках. Теперь они показывают пользователям, где они допустили ошибки, и помогают понять почему код не работает, а также подсказывают, как можно их исправить.

Источник

Символы Unicode: о чём должен знать каждый разработчик

Если вы пишете международное приложение, использующее несколько языков, то вам нужно кое-что знать о кодировке. Она отвечает за то, как текст отображается на экране. Я вкратце расскажу об истории кодировки и о её стандартизации, а затем мы поговорим о её использовании. Затронем немного и теорию информатики.

Введение в кодировку

Компьютеры понимают лишь двоичные числа — нули и единицы, это их язык. Больше ничего. Одно число называется байтом, каждый байт состоит из восьми битов. То есть восемь нулей и единиц составляют один байт. Внутри компьютеров всё сводится к двоичности — языки программирования, движений мыши, нажатия клавиш и все слова на экране. Но если статья, которую вы читаете, раньше была набором нулей и единиц, то как двоичные числа превратились в текст? Давайте разберёмся.

Краткая история кодировки

На заре своего развития интернет был исключительно англоязычным. Его авторам и пользователям не нужно было заботиться о символах других языков, и все нужды полностью покрывала кодировка American Standard Code for Information Interchange (ASCII).

ASCII — это таблица сопоставления бинарных обозначений знакам алфавита. Когда компьютер получает такую запись:

то с помощью ASCII он преобразует её во фразу «Hello world».

Один байт (восемь бит) был достаточно велик, чтобы вместить в себя любую англоязычную букву, как и управляющие символы, часть из которых использовалась телепринтерами, так что в те годы они были полезны (сегодня уже не особо). К управляющим символам относился, например 7 (0111 в двоичном представлении), который заставлял компьютер издавать сигнал; 8 (1000 в двоичном представлении) — выводил последний напечатанный символ; или 12 (1100 в двоичном представлении) — стирал весь написанный на видеотерминале текст.

В те времена компьютеры считали 8 бит за один байт (так было не всегда), так что проблем не возникало. Мы могли хранить все управляющие символы, все числа и англоязычные буквы, и даже ещё оставалось место, поскольку один байт может кодировать 255 символов, а для ASCII нужно только 127. То есть неиспользованными оставалось ещё 128 позиций в кодировке.

Вот как выглядит таблица ASCII. Двоичными числами кодируются все строчные и прописные буквы от A до Z и числа от 0 до 9. Первые 32 позиции отведены для непечатаемых управляющих символов.

Проблемы с ASCII

Позиции со 128 по 255 были пустыми. Общественность задумалась, чем их заполнить. Но у всех были разные идеи. Американский национальный институт стандартов (American National Standards Institute, ANSI) формулирует стандарты для разных отраслей. Там утвердили позиции ASCII с 0 по 127. Их никто не оспаривал. Проблема была с остальными позициями.

Вот чем были заполнены позиции 128-255 в первых компьютерах IBM:

Какие-то загогулины, фоновые иконки, математические операторы и символы с диакретическим знаком вроде é. Но разработчики других компьютерных архитектур не поддержали инициативу. Всем хотелось внедрить свою собственную кодировку во второй половине ASCII.

Все эти различные концовки назвали кодовыми страницами.

Что такое кодовые страницы ASCII?

Здесь собрана коллекция из более чем 465 разных кодовых страниц! Существовали разные страницы даже в рамках какого-то одного языка, например, для греческого и китайского. Как можно было стандартизировать этот бардак? Или хотя бы заставить его работать между разными языками? Или между разными кодовыми страницами для одного языка? В языках, отличающихся от английского? У китайцев больше 100 000 иероглифов. ASCII даже не может всех их вместить, даже если бы решили отдать все пустые позиции под китайские символы.

Эта проблема даже получила название Mojibake (бнопня, кракозябры). Так говорят про искажённый текст, который получается при использовании некорректной кодировки. В переводе с японского mojibake означает «преобразование символов».

Пример бнопни (кракозябров).

Безумие какое-то.

Именно! Не было ни единого шанса надёжно преобразовывать данные. Интернет — это лишь монструозное соединение компьютеров по всему миру. Представьте, что все страны решили использовать собственные стандарты. Например, греческие компьютеры принимают только греческий язык, а английские отправляют только английский. Это как кричать в пустой пещере, тебя никто не услышит.

ASCII уже не удовлетворял жизненным требованиям. Для всемирного интернета нужно было создать что-то другое, либо пришлось бы иметь дело с сотнями кодовых страниц.

��� Если только ������ вы не хотели ��� бы ��� читать подобные параграфы. �֎֏0590֐��׀ׁׂ׃ׅׄ׆ׇ

Так появился Unicode

Unicode расшифровывают как Universal Coded Character Set (UCS), и у него есть официальное обозначение ISO/IEC 10646. Но обычно все используют название Unicode.

Этот стандарт помог решить проблемы, возникавшие из-за кодировки и кодовых страниц. Он содержит множество кодовых пунктов (кодовых точек), присвоенных символам из языков и культур со всего мира. То есть Unicode — это набор символов. С его помощью можно сопоставить некую абстракцию с буквой, на которую мы хотим ссылаться. И так сделано для каждого символа, даже египетских иероглифов.

Кто-то проделал огромную работу, сопоставляя каждый символ во всех языках с уникальными кодами. Вот как это выглядит:

Префикс U+ говорит о том, что это стандарт Unicode, а число — это результат преобразования двоичных чисел. Стандарт использует шестнадцатеричную нотацию, которая является упрощённым представлением двоичных чисел. Здесь вы можете ввести в поле что угодно и посмотреть, как это будет преобразовано в Unicode. А здесь можно полюбоваться на все 143 859 кодовых пунктов.

Уточню на всякий случай: речь идёт о большом словаре кодовых пунктов, присвоенных всевозможным символам. Это очень большой набор символов, не более того.

Осталось добавить последний ингредиент.

Unicode Transform Protocol (UTF)

UTF — протокол кодирования кодовых пунктов в Unicode. Он прописан в стандарте и позволяет кодировать любой кодовый пункт. Однако существуют разные типы UTF. Они различаются количеством байтов, используемых для кодировки одного пункта. В UTF-8 используется один байт на пункт, в UTF-16 — два байта, в UTF-32 — четыре байта.

Но если у нас есть три разные кодировки, то как узнать, какая из них применяется в конкретном файле? Для этого используют маркер последовательности байтов (Byte Order Mark, BOM), который ещё называют сигнатурой кодировки (Encoding Signature). BOM — это двухбайтный маркер в начале файл, который говорит о том, какая именно кодировка тут применена.

В интернете чаще всего используют UTF-8, она также прописана как предпочтительная в стандарте HTML5, так что уделю ей больше всего внимания.

Этот график построен в 2012-м, UTF-8 становилась доминирующей кодировкой. И всё ещё ею является.

Что такое UTF-8 и как она работает?

UTF-8 кодирует с помощью одного байта каждый кодовый пункт Unicode с 0 по 127 (как в ASCII). То есть если вы писали программу с использованием ASCII, а ваши пользователи применяют UTF-8, они не заметят ничего необычного. Всё будет работать как задумано. Обратите внимание, как это важно. Нам нужно было сохранить обратную совместимость с ASCII в ходе массового внедрения UTF-8. И эта кодировка ничего не ломает.

Как следует из названия, кодовый пункт состоит из 8 битов (один байт). В Unicode есть символы, которые занимают несколько байтов (вплоть до 6). Это называют переменной длиной. В разных языках удельное количество байтов разное. В английском — 1, европейские языки (с латинским алфавитом), иврит и арабский представлены с помощью двух байтов на кодовый пункт. Для китайского, японского, корейского и других азиатских языков используют по три байта.

Если нужно, чтобы символ занимал больше одного байта, то применяется битовая комбинация, обозначающая переход — он говорит о том, что символ продолжается в нескольких следующих байтах.

И теперь мы, как по волшебству, пришли к соглашению, как закодировать шумерскую клинопись (Хабр её не отображает), а также значки emoji!

Подытожив сказанное: сначала читаем BOM, чтобы определить версию кодировки, затем преобразуем файл в кодовые пункты Unicode, а потом выводим на экран символы из набора Unicode.

Напоследок про UTF

Коды являются ключами. Если я отправлю ошибочную кодировку, вы не сможете ничего прочесть. Не забывайте об этом при отправке и получении данных. В наших повседневных инструментах это часто абстрагировано, но нам, программистам, важно понимать, что происходит под капотом.

Как нам задавать кодировку? Поскольку HTML пишется на английском, и почти все кодировки прекрасно работают с английским, мы можем указать кодировку в начале раздела .

Важно сделать это в самом начале , поскольку парсинг HTML может начаться заново, если в данный момент используется неправильная кодировка. Также узнать версию кодировки можно из заголовка Content-Type HTTP-запроса/ответа.

Если HTML-документ не содержит упоминания кодировки, спецификация HTML5 предлагает такое интересное решение, как BOM-сниффинг. С его помощью мы по маркеру порядка байтов (BOM) можем определить используемую кодировку.

Это всё?

Unicode ещё не завершён. Как и в случае с любым стандартом, мы что-то добавляем, убираем, предлагаем новое. Никакие спецификации нельзя назвать «завершёнными». Обычно в год бывает 1-2 релиза, найти их описание можно здесь.

Если вы дочитали до конца, то вы молодцы. Предлагаю сделать домашнюю работу. Посмотрите, как могут ломаться сайты при использовании неправильной кодировки. Я воспользовался этим расширением для Google Chrome, поменял кодировку и попытался открывать разные страницы. Информация была совершенно нечитаемой. Попробуйте сами, как выглядит бнопня. Это поможет понять, насколько важна кодировка.

Заключение

При написании этой статьи я узнал о Майкле Эверсоне. С 1993 года он предложил больше 200 изменений в Unicode, добавил в стандарт тысячи символов. По состоянию на 2003 год он считался самым продуктивным участником. Он один очень сильно повлиял на облик Unicode. Майкл — один из тех, кто сделал интернет таким, каким мы его сегодня знаем. Очень впечатляет.

Надеюсь, мне удалось показать вам, для чего нужны кодировки, какие проблемы они решают, и что происходит при их сбоях.

Источник