Rust *

Еще в декабре мне попалась одна совершенно замечательная статья на английском, посвящённая использованию системы типов языка для более широкого класса задач, для повышения надежности приложений и простоты рефакторинга. К сожалению, в тот момент я был слишком занят написанием статей по ФП, которые крайне важно было написать, пока свежи воспоминания. Но теперь, когда с этой задачей я справился, наконец дошли руки перевести эту замечательную заметку. Оригинальный язык примеров — Хаскель, но я решил переписать их на раст, для более широкого охвата аудитории. Однако язык тут совершенно неважен, советы этой статьи я применяю в ежедневной разработке на вполне себе "приземлённых" C# и TypeScript, так что если вы просто стараетесь писать надёжный и поддерживаемый код, то, вне зависимости от языка, статья вам будет в тему.

Благодарю за вычитку и помощь в переводе Hirrolot, funkill и andreevlex

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

• Сложность с поддержкой таких макросов в IDE. По сути дела нужно как-то научить анализатор кода самостоятельно компилировать, загружать и исполнять эти самые макросы с учетом всех особенностей. Это весьма нетривиальная задача.
• Так как макросы самодостаточные и ничего не знают друг о друге, то нет никакой возможности делать композицию макросов, что иногда могло бы быть полезным.

Буквально на днях на arXiv-е была выложена очень занятная статья швейцарских исследователей, в которой представлены подробности проекта LLHD. Это проект создания многоуровневого промежуточного представления для языков описания аппаратуры, наследующий идеологию и принципы проекта LLVM.

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

Предлагаемая иерархия инструментов (здесь и далее изображения из оригинальной статьи)

У проекта есть все шансы стать тем же, чем GCC и LLVM в свое время стали для мира открытого программного обеспечения. Сложно даже представить, насколько это может изменить ситуацию вокруг разработки железа.

Под катом описание текущего положения дел, краткий обзор языка и отличия нового подхода.

Команда Rust рада сообщить о выпуске новой версии, 1.42.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.42.0 вам достаточно выполнить следующую команду:

rustup update stable

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

Что вошло в стабильную версию 1.42.0

Основными нововведениями Rust 1.42.0 являются более удобные сообщения о панике в случае вызова unwrap, шаблоны срезов, объявление устаревшим Error::description и многое другое. Смотрите подробности выпуска для дополнительной информации.

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

Команда Rust опубликовала новый корректирующий выпуск Rust, 1.41.1. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.41.1 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта

Что вошло в стабильную версию 1.41.1

Rust 1.41.1 посвящён двум критическим регрессиям, появившимся в Rust 1.41.0: некорректность в статических временах жизни и неправильная компиляция, вызывающая ошибки сегментирования. Эти регрессии не затрагивают предыдущие выпуски Rust и мы рекомендуем пользователям Rust 1.41.0 обновиться настолько быстро, насколько это возможно. Другая проблема, связанная со взаимодействием между временем жизни 'static и реализациями типажа Copy, присутствовала ещё с Rust 1.0 и тоже исправляется данным выпуском.

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

Основная OS у меня Linux, но иногда приходится собирать исполняемые файлы и для Windows. И естественно что перегружаться в Windows только для сборки exe не особо хочется. С языками C и C++ проблем нет, давно существует кросскомпилятор MinGW, который прекрасно с этим справляется. Про Python и Java даже упоминать не стоит, кроссплатформенность в них изначально. Но в прошлом году я решил попробовать такой пока что новомодный язык, как Rust. При сборке исполняемого файла при помощи включённого в дистрибутив Rust пакетного менеджера cargo вроде как достаточно задать ключ --target, при помощи которого указать результирующий процессор, архитектуру и ABI и при сборке из Linux в результате получить exe, который будет являться стандартным исполняемым файлом для Windows. Но пытаясь так сделать:

cargo build --target x86_64-pc-windows-gnu

я получил только сообщения об ошибках линкера:

error: linking with `gcc` failed: exit code: 1

[...]

  = note: /usr/bin/ld: unrecognized option '--nxcompat'
          /usr/bin/ld: use the --help option for usage information
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

error: could not compile `foobar`.

Если кому интересно как я это поборол и теперь спокойно могу кросскомпилировать программы на Rust для Windows, не покидая Linux, добро пожаловать под кат.

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

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

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

Команда Rust рада сообщить о выпуске новой версии, 1.41.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.41.0 вам достаточно выполнить следующую команду:

rustup update stable

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

Что вошло в стабильную версию 1.41.0

Основными новшествами Rust 1.41.0 являются ослабление ограничений на реализацию типажей, улучшения cargo install, новый формат файла Cargo.lock более дружелюбный для работы с git, и новые гарантии для Box<T>, связанные с FFI. Смотрите подробности выпуска для дополнительной информации.

Многие задаются вопросом — насколько медленный Python в операциях декодирования? Правда ли, что компилируемые языки дают прирост скорости во всем, чего касаются? Что быстрее: OpenCV или ничего? Ответы на эти и другие бесполезные вопросы под катом вы прочитать не сможете. Там обычное скучное исследование производительности в конкретной задаче.
Все заинтересовавшиеся, добро пожаловать!

Приветствую вас, глубокоуважаемые!

«… истинное место судна хотя и неизвестно, но оно не случайно, оно есть, но неизвестно в какой точке» Алексишин В. Г. и др. Практическое судовождение, 2006. стр. 71

«С двух краев галактики вышли пешеходы...» (С) Сергей Попов (Астрофизик)

• расстояние между двумя географическими точками
• определение точки по известной, расстоянию до нее и азимутальному углу
• определение положения точки по измеренным дальностям до известных точек (TOA, TOF)
• определение положения точки по измеренным временам прихода сигнала (TDOA)

Вообще-то смотреть какого цвета потроха у Rust я не собирался. Ковырнул хобби-проект на Go, пошел на GitHub посмотреть состояние fasthttp: развивается ли? Ну хотя бы поддерживается? Вспрокрастинулось. Пошел, посмотрел где fasthttp сидит в бенчмарках TechEmpower. Смотрю: а там fasthttp едва показывает половину того, что удаётся лидеру — какому-то actix на каком-то Rust. Какая боль.

Здесь бы мне сложить ручки, стукнуть головой в пол (трижды) и закричать: "Алилуйя, воистину Rust — истинный бог, как слеп я был раньше!". Но то ли ручки не сложились, то ли лоб пожалел… Вместо этого полез в код тестов, написанных на Go и actix-web тестов на Rust. Чтобы разобраться.

Через пару часов узнал:

1. почему Rust-фреймворк actix-web занимает первые позиции во всех тестах TechEmpower,
2. как в Java заводится Script.

Сейчас всё расскажу по порядку.

Краткая суть ситуации: наш соотечественник fafhrd91 на протяжении 3 лет практически самостоятельно (см. кдпв) писал actix-web — один из популярнейших крейтов в инфраструктуре раста, лидер в большинстве различных бенчмарков, и за это время подвергался как минимум трём волнам гонений за "неправильное использование раста". После последнего раза автор психанул, и перенес репозиторий к себе в аккаунт с пометкой "Планирую скрыть репозиторий". Конечно, куча людей сразу наделало зеркал и бекапов, но на мой взгляд это не сильно исправляет ситуацию.

На месте репозитория автор оставил единственный postmortem, который я ниже и цитирую целиком:

Привет, Хабр !

Работая с Javascript / Typescript, я давно заметил, что асинхронное API работает медленней чем аналогичное синхронное, и даже знал что так должно быть. Но в последнем проекте асинхронная работа с файловой системой стала узким местом, и я озаботился замерами.

Известно, что await можно использовать только внутри функций или блоков async, а это значит, что если у нас самый нижний уровень API асинхронный, то придется использовать async/await практически везде, даже там, где оно очевидно не нужно.

К примеру, мы пишем сервисную функцию, которая достает из хранилища объект по ключу. В качестве хранилища мы можем использовать файл, БД, микросервис, то есть медленный источник с асинхронным интерфейсом. Для улучшения производительности — внутри нашей функции мы кэшируем ранее извлеченные объекты (складываем их в Map). По мере работы программы реальных обращений к хранилищу становится все меньше, объекты отдаются из быстрого кэша, но интерфейс функции остается асинхронным!

Какую цену мне приходится платить за каждый асинхронный вызов?
Результаты тестов удручают...