Embedding Rust in Python.

Статья годичной давности, но при этом не менее актуальная, об интересном опыте процесса оптимизации проекта Sentry на Rust.

Критические части Python приложений можно переписывать на Си и С++ - но это давно всем известно, со времён введения ctypes в Python.
Но я давно задавался вопросом - если заменить Си и C++ на Rust и взаимодействовать со скомпилированным кодом через CFFI, это будет безопасно и с практически нулевым оверхэдом!
Ребята из Sentry продемонстрировали эту концепцию на практике!

https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html

Армин Ронахер, автор фреймворка Flask, контрибьютор проекта Sentry, платформы мониторинга, логирования и агрегации ошибок, рассказал о том как происходила оптимизация критических по времени исполнения и памяти, а также чувствительных к задержкам частей кода на Python в проекте Sentry при помощи библиотечного модуля (парсера отладочных Source Map файлов из дампов логов Sentry), написанного на Rust и вызываемого через СFFI из обёртки (wrapper) на языке Python.
Также интересна и очень показательная на практике совместимость скомпилированного кода Rust с C ABI через rust-ffi интерфейс (https://doc.rust-lang.org/book/first-edition/ffi.html).

https://github.com/getsentry/libsourcemap - production парсер обёрнутый в Python

https://github.com/getsentry/rust-sourcemap - изначальная библиотека парсера на на Rust от Армина

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

https://github.com/PyO3/pyo3

https://github.com/dgrunwald/rust-cpython

Об отладке при помощи Source Map, постепенной типизации (gradual typing) и типизации контекста испонения (flow typing).

Чистый JavaScript сейчас используется всё чаще как слаботипизированный промежуточный язык (как ассемблер, Си или C--) для браузерного движка, компилятора JS, например V8 для Chromium или Spider/Jaeger Monkey для Firefox.

Есть более высокоуровневые языки (а также статические анализаторы и типизаторы, транс-компиляторы для JS) с более строгой динамической типизацией (flow sensitive typing - Dart2JS, TypeScript, Elm, Facebook Flow, Babel), которые транс-компилируются через трансформации абстрактных синтаксических деревьев в JS. Такой исходный код похож на жутко обфусцированный и минифицированный обычный JS код. Но он включает необходимые проверки типов (gradual typing) для run-time фазы исполнения кода и хорошо оптимизирован для стадии JIT компиляции браузерным движком, JS компилятором.

Всё движется к строгой статической типизации с CTTI и RTTI трюками выводов типов в compile-time и run-time соответственно:
https://webcache.googleusercontent.com/search?q=cache:https://blog.jooq.org/2014/12/11/the-inconvenient-truth-about-dynamic-vs-static-typing/

http://sitr.us/2014/11/21/flow-is-the-javascript-type-checker-i-have-been-waiting-for.html

Конечно, даже типизация контекста испонения (flow typing), которая используется ещё на этапе разработки в статических анализаторах кода в IDE (проверки типов параметров в WebStorm, Atom IDE, Visual Studio Code) и постепенная типипзация (gradual typing, типизация с включением проверок типов в исходный код промежуточных слабо типизированных языков или динамических языков с нестрогим контролем типов, типизированный байт-код для динамических языков, например mypy в СPython, либо наоборот директива динамической диспетчеризации типов в байткоде для виртуальной машины, например invoke-dynamic в JVM, dynamic тип в байт-коде DartVM и DLR .Net для C# - это всё вариации постепенной типизации) не защищают полностью от исключительных ситуаций и ошибок времени исполнения в run-time (не говоря о языках CoffeeScript, LiveScript в которых нет flow sensitive системы типов, как и в обычном JavaScript), а директива динамической диспетчеризации типов dynamic в байткоде только повышает риск исключений в типах при слабой нестрогой системе типов в run-time.

Поэтому подобным транс-компилированным JS приложениям необходима отладка. Файл source map подобен debug symbols для JS приложений. Он содержит реверс отображение, которое при помощи отладчика позволяет найти по транс-компилированному JS коду часть исходного кода на первоначальном языке в которой возникло исключение или ошибка типов. Библиотека парсера source map файлов позволяет этот процесс автоматизировать и выделять отладочную информацию из бинарных дампов в лог базы данных Sentry.

https://blog.sentry.io/2015/10/29/debuggable-javascript-with-source-maps.html

https://docs.sentry.io/clients/javascript/sourcemaps/

PS: Тема современных систем типов и контроля целостности памяти в многопоточных приложениях интересная, живая и горячая - thus of, stay tuned and don't switch channel. =)

Полезные ссылки к статье:
https://en.wikipedia.org/wiki/Gradual_typing
https://en.wikipedia.org/wiki/Flow-sensitive_typing

CPython+Mypy:
https://t.me/technologique/155
https://www.python.org/dev/peps/pep-0484/
https://github.com/python/mypy

Facebook Flow:
https://flow.org
https://github.com/facebook/flow
https://github.com/flowtype/flow-typed

О возможностях разных редакторов кода:
https://t.me/technologique/887
https://t.me/technologique/888
https://t.me/technologique/889

Собственно вот так flow-sensitive typing работает в режиме реального времени при парсинге исходников и проверке типов параметров в Atom IDE (и в VSCode это тоже есть) - посмотрите по ссылкам, там много gif screen capture анимаций и конечно советую попробовать Atom IDE и VSCode на практике:

https://t.me/technologique/1086
https://t.me/technologique/1061

https://nuclide.io

https://github.com/facebook/nuclide

https://ide.atom.io

https://atom.io/packages/atom-ide-ui

https://github.com/flowtype/ide-flowtype

https://github.com/atom/atom-languageclient

https://github.com/flowtype/flow-language-server

Аудио-интервью с Андреем Бреславом для портала InfoQ.

О принципах дизайна языка Kotlin, его возможностях, истории разработки и будущем Kotlin/Native.

https://youtu.be/iqbAPY7PPAw

#Kotlin

Ссылки по теме:
https://t.me/technologique/1108
https://t.me/technologique/1042
https://t.me/technologique/1043
https://t.me/technologique/1044
https://t.me/technologique/1047
https://t.me/technologique/995
https://t.me/technologique/928

Открыт исходный код Plus Messenger.

https://gitlab.com/rafalense/plus-messenger

Исходный код альтернативного Telegram клиента Plus Messenger был опубликован в репозитории GitLab ещё месяц назад, но широко об этом стало известно только сейчас.

#Telegram

Разговор двух Алис.

У голосовой помощницы Алисы от Яндекс есть ярко выраженная индивидуальность и очень эмоциональная натура.

Оказывается если заставить двух голосовых помощниц Яндекса пообщаться друг с другом выходят весьма забавные интеллектуальные беседы полные аллюзий. 😆😂👍

В целом русская версия самообучающегося AI выглядит именно так - Алиса учится у Алисы и становится лучшей версией самой себя. 😁😂

https://youtu.be/vsaMXZ4Q_t8

https://youtu.be/hDZNXh2X73k

https://youtu.be/xOHwbZCVFXc

Голосовая помощница Алиса доступна в приложении Яндекс.Поиск:

https://play.google.com/store/apps/details?id=ru.yandex.searchplugin

https://play.google.com/store/apps/details?id=ru.yandex.searchplugin.beta

lal - language-agnostic build system and dependency manager.

На днях нашёл интересный проект от Cisco для управления зависимостями и сборки проектов на разных языках (language-agnostic). Весьма полезен для управления зависимостями проектов на С/C++. В помощь тем кто пишет на С/C++ и до сих пор собирает проекты с помощью make скриптов.

Проект реализован на #Rust. =)

https://github.com/cisco/lal-build-manager

Андерс Хейлсберг о нововведениях в TypeScript на конференции MS Build 2017.

Очень интересное выступление Андерса Хейлсберга на Build 2017 о нововведениях в языке TypeScript с сильной строгой flow-sensitive системой типов (flow typing) - очень советую посмотреть!

https://channel9.msdn.com/Events/Build/2017/B8088/

Я сам практически не использую Windows в работе (и остаюсь приверженцем Debian и Arch Linux), но Андерс показывает классный отработанный до автоматизма экспириенс в Windows 10 и консоли, виртуозное владение TypeScript в редакторе с возможностями IDE Visual Studio Code - люблю смотреть такие выступления, это просто хай-тэк шоу и очень приятно наблюдать за работой профессионалов столь высокой квалификации!

Андерс молодец - остаётся актуальным в технологическом потоке, движет тренды, развивает технологии сам, всё ещё молод в душе, зажигателен и подаёт яркий пример для молодёжи! А ведь он делал ещё в разное время Turbo Pascal, Delphi и C#! Вряд ли я смогу назвать хоть ещё одного, столь экспрессивного, современного автора столь многих популярных языков программирования! Разве что таким же был его учитель, профессор Никлаус Вирт, в своё время.


Ссылки на материалы по теме:
https://t.me/technologique/1124

Dotty Linker & the future of Scala 3.

Разбирал код линковщика, модифицированный Dotty Linker, который пишется для реализации DOT-evaluation системы типов компилятора Scala 3.

https://github.com/dotty-linker/dotty

Если совсем коротко - система типов dependent object types evaluation (DOT calculus), придуманная Мартином Одерски, это реализация редукции графов для объектных типов, т.е. это реализация нестрогих/ленивых вычислений (non-strict/lazy evaluation strategy) для CTTI вывода типов по графовой модели их зависимостей в системе типов будущей Scala 3 (ныне проект компилятора и системы типов Dotty).
С одной стороны это увеличит безопасность программ благодаря конкретизации типов через их зависимости, с другой стороны увеличит производительность, т.к. граф зависимостей типов позволяет оптимизировать код и поток исполнения программы, приводя его в детерминированное состояние (оптимизация потока исполнения, циклов и рекурсивных вызовов, с приведением его графа к виду возможному для исполнения на детерминированном конечном автомате, детерминированной машине Тьюрига).
Но главное чего хотели добиться с помощью Dotty - неявное/автоматическое максимально возможное распараллеливание программы на потоки, с последующей графовой редукцией результатов вычислений.
Подобное распараллеливание потока исполнения с редукцией (по типу map-reduce или fork-join модели) результатов вычислений позволяют выполнять практически все чистые функциональные языки и логика кодогенераторов их компиляторов, что позволяет более эффективно и просто без явного ручного программирования распараллелить поток исполнения на множество вычислительных ядер и более эффективно и быстро исполнять программу.
Зависимые типы в системе типов языка дают граф зависимостей данных и кода при анализе программы и позволяют понять какие части программного кода более независимы друг от друга и от общих данных, и позволяют выполнить распараллеливание исполнения в отдельных программных потоках с возможным (более дорогим по накладным расходам системных вызовов) маппингом на системные потоки пространства ядра.
Но есть и минусы такого решения - зависимые типы ещё более затягивают процесс компиляции из-за наследования типов и разростающегося графа их зависимостей при выведении типов с помощью правил формализованных в DOT исчислении (DOT calculus).
К тому же архитектура стэковой машины (с сохранением контекста исполнения в стэковой структуре данных) и семантика байт-кода JVM ограничивают возможности и не способствует реализации ленивых вычислений (lazy evaluation) в чистом виде - в Clojure (а также Frege и Eta) например используется CTTI и RTTI хаки вывода типов, в т.ч. dynamic dispatch через invoke-dynamic байт код (то же что и dynamic тип в DLR .Net и С#) и multiple dispatch для обобщённых типов в RTTI фазе при исполнении кода, т.е. больше используется структурный и отложенный вывод типов в compile-time и позднее связывание (late binding) и динамическая диспетчеризация типов (dynamic dispatch, short-circuit/minimal evaluation) в run-time, нежели реальные чистые ленивые вычисления (lazy evaluation strategy).
Быстрая компиляция при такой системе типов - это архисложная задача с которой ещё предстоит справится.
Но у меня оптимизма остаётся всё меньше. Ни один язык с системой зависимых типов - в т.ч. из более-менее распространённых Idris, Agda, F*, системы автоматических доказательтв Coq и Matita, и символьных вычислений, которые вообще используют динамическую интерпретацию, перенося вывод типов в run-time фазу (RTTI) при исполнении кода - не компилируется быстро.
Саймон Пейтон Джонс специально создал для поддержки реализации lazy evaluation strategy слаботипизированный язык C-- в который компилируется Haskell.

Ссылки на материалы по теме:
https://en.wikipedia.org/wiki/Evaluation_strategy

https://t.me/technologique/343 =)
https://t.me/technologique/720
https://t.me/technologique/1002
https://t.me/technologique/1006
https://t.me/technologique/1007
https://t.me/technologique/1051
https://t.me/technologique/1052
https://t.me/technologique/1054
https://t.me/technologique/1072

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

https://gist.github.com/andrcmdr/e31ba4c9bf881fbff595cd799620ca72#algebras

Ссылки:
https://t.me/technologique/1054
https://t.me/technologique/1052
https://t.me/technologique/1051

Дорогие читатели, сегодня хочу порекомендовать вам один очень классный канал системного администратора Linux - "Записки админа" (@SysadminNotes).

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

Я сам (как и вы, надеюсь) использую Linux (Debian, Arch), открытый софт и инструменты FLOSS, DevOps практики в своей профессиональной (и не только) деятельности и проектах ежедневно.
Канал меня лично очень заинтересовал, в нём я нашёл достаточно много полезной для себя информации, например удобный консольный мониторинг серверов, думаю и вы также найдёте много полезной информации в данном канале для себя.
Очень рекомендую! 👍

#channels

Трансляция из главного зала конференции HighLoad++ 2017 в Москве, Сколково.

https://www.youtube.com/watch?v=BlDK2KKKYc8

http://www.highload.ru/2017/news/643.html

Резервный канал:
http://play.ngenix.net/highload

Расписание конференции:
http://www.highload.ru/2017/schedule.html
http://www.highload.ru/pdf-hl-2017/hl.pdf

Тезисы докладов конференции:
http://www.highload.ru/2017/abstracts
http://www.highload.ru/2017/meetups

Ссылки:
https://t.me/technologique/583
https://t.me/SysadminNotes/530
https://t.me/HighLoadConfChannel
https://t.me/HighLoadConf

Rock solid kernel - previous max uptime has beaten!

Какое ядро самое стабильное? Linux, BSD? Nope!

Sun Solaris (Sun OS), IBM AIX, HP-UX, SGI IRIX и прочих коммерческих Unix систем.

Буквально вчера товарищ в Твиттере показал сервер Solaris с uptime в 6519 дней - чуть меньше 18 лет аптайма! 😱 Сервер решили перезагрузить в связи с проблемой системного времени Y2K - с 2000-го года система не получала никаких патчей и апдейтов!

https://twitter.com/lworonowicz/status/927507006138839045

https://twitter.com/lworonowicz/status/927900714038329344

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

"How do you power off this machine?" — Linus Torvalds

Прежний "рекорд" был опубликован на форуме онлайн журнала ArsTechnica и описан в статье в нём же, и принадлежал файловому серверу с ОС NetWare от Novell, аптайм которого был равен 6039 дней.

https://twitter.com/andrcmdr/status/576267130045337600

https://arstechnica.com/information-technology/2013/03/epic-uptime-achievement-can-you-beat-16-years/

https://arstechnica.com/civis/viewtopic.php?f=23&t=1199529

Шаблоны проектирования в динамических языках программирования.

Design patterns exist to compensate for a programming language's lack of expressiveness.

Петер Норвиг, один из основоположников в программировании систем искусственного интеллекта, ныне Director of Research at Google, о паттернах/шаблонах проектирования в динамических языках (с динамическим выводом, диспетчеризацией и связыванием типов во время исполнения, in run-time), главным образом Dylan и Lisp. Презентация 1996-го года, но сегодня актуальна как никогда ранее! Просто почитайте!

http://norvig.com/design-patterns/

http://norvig.com/design-patterns/design-patterns.pdf

http://norvig.com/design-patterns/design-patterns.pdf#page=67

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

Думаю самая первостепенная характеристика любого языка, в т.ч. языка программирования - это его выразительность, т.е. информационная ёмкость его синтаксических конструкций и выражений (что также порождает сложность грамматики, лексем и сематики языка).

Есть даже такая характеристика в формальной теории языков (formal language theory) - сила выразительности языка (expressive power).

https://en.wikipedia.org/wiki/Expressive_power_(computer_science)

Links:
https://en.wikipedia.org/wiki/Peter_Norvig

Gogland теперь GoLand... для GoLang.

Теперь уже официальное название IDE для #Golang от JetBrains получила в выпуске EAP 18.

https://twitter.com/GoLandIDE/status/926157642158034945

С первого раза и неуловишь разницу! Забавная игра букв - с таким названием возникает много аллюзий. 😆😂

Links:
https://t.me/technologique/651
https://t.me/technologique/663
https://t.me/technologique/915

New Firefox: Firefox Quantum. Fast. For good.

Mozilla выпустили релиз браузера Firefox 57 на новом движке рендеринга макетов страниц Quantum.

https://www.youtube.com/watch?v=n6wiRyKkmKc

https://www.mozilla.org/en-US/firefox/quantum/

О том какие компоненты входят в состав движка Quantum - https://t.me/technologique/1079

https://blog.mozilla.org/firefox/get-ready-firefox-quantum/
https://blog.mozilla.org/blog/2017/11/14/introducing-firefox-quantum/
https://blog.mozilla.org/blog/2017/11/14/fast-for-good-launching-the-new-firefox-into-the-world/
https://hacks.mozilla.org/2017/11/entering-the-quantum-era-how-firefox-got-fast-again-and-where-its-going-to-get-faster/

Во всех основных браузерах внедрена поддержка WebAssembly (WASM модулей) - теперь клиентские приложения можно писать не только на JavaScript, но и, например, на Rust 😉:
https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/

Ссылки:
https://www.youtube.com/watch?v=YIywpvHewc0
https://www.webpagetest.org
https://github.com/WPO-Foundation/webpagetest

Mozilla makes HolyJit!

Помимо компонентного движка Servo для проекта нового браузера Firefox Quanum, ребята из Mozilla работают над meta-JIT компилятором Rust (вернее пока это расширение пропатченного стандартного компилятора rustc в виде библиотеки) с забавным названием HolyJit. Сам проект написан полностью на Rust.

https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new-hope/

https://github.com/nbp/holyjit

Чтобы использовать HolyJit нужно скомпилировать специальную пропатченную версию компилятора rustc:
https://github.com/nbp/rust/tree/register_opt_mir_pass

Данный пропатченный фронт-энд компилятор rustc изменяет семантику байт-кода и порождает MIR/IR код потребный для оптимизации и динамической компиляции бэк-энд JIT компилятором стэковой виртуальной машины LLVM.

На языковом уровне добавлен макрос jit! {} для объявления функции или имплементора impl трейта динамически компилируемым.

Для реализации рефлексивной гомоиконности (метапрограммирования, интроспекции байт-кода) промежуточного представления кода и интеграции с байт кодом MIR (фаза оптимизации) и ассемблером IR (финальная стадия компиляции) стэковой машины LLVM и управления процессом динамической JIT компиляции добавлен тип-класс (класс типов, type class) JitContext в виде имплементора трейта.

https://github.com/nbp/holyjit/blob/master/lib/src/context.rs

Проект пока ещё на самых ранних стадиях своего развития и у него ещё многое впереди, но перспективы весьма интересны - посмотрим что из этого выйдет.

Пока HolyJit это meta-JIT компилятор Rust, но со временем можно будет провернуть бутстрап бэк-энд компилятора и полностью отказаться от LLVM - сам проект HolyJit это экспериментальная кодовая база для создания нового JIT компилятора JavaScript для Firefox, с улучшенной безопасностью памяти и возможностями оптимизации, и (возможно), используя модульную архитектуру движка Servo/Quantum, для создания JIT компиляторов других языков программирования, подключаемых в виде WASM (WebAssembly) модулей. И тогда нас всех ждёт более увлекательное мультиязыковое будущее клиент-сайд приложений.

#Rust