OCaml in Financial Technologies

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

Несколько очень классных и интересных видео, которые посмотрел на днях, с непосредственным участием Ярона Мински (https://twitter.com/yminsky), соавтора самой лучшей книги об OCaml (да и вообще в целом о создании компиляторов) "Real World OCaml" (https://t.me/technologique/1010) и разработчика трейдинговых биржевых платформ на OCaml в крупной трейдинговой компании Jane Street Capital, в которой OCaml используется не для высокочастотного трейдинга (https://www.youtube.com/watch?v=FDUrItVCeyg&t=7m45s), а для максимального покрытия рисков в биржевых операциях с ликвидными средствами. Jane Street является одним из крупнейших системных интеграторов OCaml в своей инфраструктуре (наряду например с Facebook) — https://blog.janestreet.com
В интервью для San-Francisco Scala Meetup's Ярон рассказал более подробно о моделях вычислений в обработке данных на OCaml для финансового сектора и анализе финансовых данных с помощью OCaml в сравнении с другими языками функционального программирования.

#OCaml

В интервью Ярон затронул также очень тонкий вопрос - в чём основное отличие OCaml, его компилятора и VM, а также Rust/LLVM, от JVM и языков для неё, которые также очень широко используются в финансовом секторе.

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

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

https://www.youtube.com/watch?v=-J8YyfrSwTk

Вся соль в метапрограммировании, run-time рефлексии и интроспекции типов.

Rust (равно как и OCaml, и ML) из-за полностью статической системы типов (вывода и статического анализа типов в compile-time) поддерживает метапрограммирование благодаря поддержке гомоиконности через систему compile-time макро-расширений (макросов) языка.
JVM языки (Java, Kotlin, Scala), наряду со статической системой типов (compile-time выводом и статическим анализом типов), также поддерживают run-time рефлексию и интроспекцию типов данных в run-time. Это очень удобно для создания моделей данных и вычислений, особенно в финансовом секторе. Именно поэтому JVM языки стали столь популярны в бизнес среде и разработке приложений для корпоративного и финансового сектора.
И это главное отличие Rust и языков группы ML (Standard ML, Concurrent ML, Dependent ML и их потомка, языка OCaml) от JVM языков.
Но при этом, нужно отметить, что все эти языки, как Rust/OCaml/ML, так и JVM языки, могут проходить разные стадии компиляции, независимо от наличия статической (вывода и статического анализа типов данных в compile-time) и динамической (run-time рефлексии и интроспекции типов данных) системы типов — например, интерпретация байт-кода (JVM), компиляция байт-кода (LLVM IR/MIR), динамическая кодогенерация, т.е. динамическая JIT компиляция байт-кода (JVM и LLVM JIT).

#Rust
#OCaml
#ML

Поисковые механизмы Telegram пока ещё не так совершенны (до сих пор в клиентских приложениях нет глобального поиска по описаниям каналов, содержимому постов или по тегам, как в Twitter, но уже есть внешние индексирующие сервисы, например https://tgstat.ru/search) и встроенные механизмы поиска не позволяют читателям находить каналы с интересующей информацией определённой тематики прямо в клиентских приложениях (через строку поиска), а авторам находить заинтересованную аудиторию, продолжать писать и делиться интересной информацией и опытом.
Единственным самым простым и доступным способом для авторов и читателей найти друг друга остаются подборки и рекомендации каналов.
Поэтому не так давно мы с авторами других IT каналов решили рассказывать вам друг о друге.
В данной подборке каналов каждый из вас сможет найти интересную и полезную для себя информацию из разных направлений IT сферы.
А если вы автор интересного канала — пишите (@andrcmdr), расскажите о себе, мы с коллегами, другими авторами, стараемся создать пул достойных IT каналов разной направленности для блага читателей и поддержки друг друга.

Наш регулярный листинг IT каналов в Telegram.

@sea_plus_plus - Канал об интересных материалах из мира C/C++, Python, Go, Linux и не только. Новости, заметки, полезные советы и многое другое.

@dncuug - Канал посвящен разработке под .NET Core - ежедневные публикации о новостях платформы, интересные статьи, видео.

@IoT_community - Канал крупнейшего российского сообщества по интернету вещей. Подборки интересных материалов, новости и анонсы различных мероприятий об IoT.

@msdnru - Официальный канал сообщества Microsoft Developer для разработчиков и всех, кто интересуется новыми технологиям.

@ITBroadcast - Канал для тех, кто хочет быть в теме и познавать новое в области IT. Входим в Top 1 каналов Telegram о технологиях.

@MicrosoftRus - Авторские заметки для ITPro & Dev о Microsoft, Windows Server, System Center, Azure, Office 365, OMS, SQL, облаках, железе и не только.

#channels
#telegram
#advices

Tokio.rs internals: Understanding Rust's asynchronous I/O framework from the bottom up

Дэвид Симмонс погрузился в исходники фреймворка Tokio для многопоточной обработки асинхронного ввода-вывода на Rust и рассказал о его внутреннем устройстве, архитектуре, принципах и механизмах работы, и насколько вообще глубока "кроличья нора" (pipeline) при обработке системных вызовов ввода-вывода.

Фреймворк Tokio базируется на низкоуровневой библиотеке/crait'е MetalIO (MIO), написанной также на Rust, для работы с API системных вызовов ввода-вывода и использует Future/Promise/Tasks модель для многопоточной обработки ввода-вывода в асинхронном неблокирующем режиме.

https://cafbit.com/post/tokio_internals/

#Rust

Ссылки:
https://t.me/technologique/1200 - фреймворки Tokio и Tower используются в проекте Conduit компании Buoyant для организации сервисных шин и управления роем сверхлёгких микро/нано-сервисов в контенерных окружениях при ограниченных машинных ресурсах в IoT и Cloud Native инфраструктурах

https://t.me/technologique/970 - результаты нагрузочных тестов фреймворка Tokio в сравнении с многими другими фреймворками в бенчмарке от TechEmpower

Fast and Asynchronous: Tokio Drift

Отличный доклад от Алекса Крайтона о принципах дизайна фреймворка Tokio.

https://www.youtube.com/watch?v=4QZ0-vIIFug

#Rust

Links:
https://t.me/technologique/1207

Rust: Reach Further!

Недавний доклад Нико Матсакиса (Niko Matsakis), одного из основных core developers проектов Rust и Servo Engine в Mozilla, с евангелизмом Rust в очень правильной подаче — объяснением концепций языка, его системы типов, полностью статического анализа и вывода типов в compile-time (отсутствие динамизма типов времени исполнения (run-time) программ, мономорфизация обобщённых полиморфных типов), обеспечения безопасности памяти и потоков кода системой типов, абстракций нулевой стоимости и принципов дизайна компилятора языка Rust.

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

#Rust

Сборник подобных видео лекций и материалов по базовым концепциям Rust:
https://t.me/technologique/1012
https://t.me/technologique/1041
https://t.me/technologique/1145

https://t.me/technologique/1199
https://t.me/technologique/1015
https://t.me/technologique/892
https://t.me/technologique/957

Debugging WebAssembly (WASM) modules written in Rust right in the Firefox DevTools!

Firefox DevTools в nightly сборках браузера теперь поддерживает отладку скомпилированных WebAssembly (WASM) модулей, написанных на #Rust, с адресным source mapping'ом на участки исходников модулей.

Возможности отладки были показаны на live coding сессии конференции Mozilla All-Hands, проходившей 11-16 декабря в Остине, штат Техас:
https://twitter.com/slsoftworks/status/941400137921949696

Напомню, поддержка WebAssembly внедрена уже во все основные браузеры - Mozilla Firefox, Google Chrome/Chromium, Apple Safari и Microsoft Edge.

Ссылки на материалы по темам:
Об отладке при помощи Source Map:
https://t.me/technologique/1124
https://t.me/technologique/1125

Опыт Sentry с применением Rust для оптимизации мониторинга run-time инцидентов и их отладки при помощи Source Map:
https://t.me/technologique/1123
https://t.me/technologique/1153

WebAssembly и Firefox DevTools:
https://t.me/technologique/1161
https://t.me/technologique/1144
https://t.me/technologique/1143
https://t.me/technologique/1079
https://t.me/technologique/655

Isomorphous Rust

Gotham и Rocket — пара отличных фреймворков для создания серверных веб-приложений на #Rust:

https://rocket.rs

https://github.com/SergioBenitez/Rocket

https://gotham.rs

https://github.com/gotham-rs/gotham

https://twitter.com/gotham_rs

Плюс интересный новый фреймворк для создания клиентских браузерных (React alike) веб-приложений на Rust с возможностью их компиляции в WebAssembly WASM модули:

https://github.com/DenisKolodin/yew

https://users.rust-lang.org/t/yew-a-framework-for-client-side-web-apps/14597

Итоги года для Rust Community.

Подведение итогов этого года работы над развитием экосистемы Rust и Rust Community в официальном блоге.

https://blog.rust-lang.org/2017/12/21/rust-in-2017.html

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

https://www.nostarch.com/rust - более практическая книга от Стива Клабника, подобна самоучителю, на основе Rust Book, https://doc.rust-lang.org/book/second-edition/ почти то же самое 😉

http://shop.oreilly.com/product/0636920040385.do

https://www.manning.com/books/rust-in-action

Dynamic analysis for static typing in Python!

Недавно инженеры Instagram открыли исходный код типизатора MonkeyType — инструмента для динамического run-time анализа программ на Python и автоматизации внедрения статических аннотаций типов в исходниках на Python, с использованием gradual typing расширения mypy (PEP-484) для интерпретатора CPython.
Статические аннотации типов и постепенная типизация (gradual typing) в динамических языках повышают надёжность и предсказуемость поведения программы во время исполнения, уменьшают количество run-time ошибок и исключительных ситуаций, необходимых тестов для их покрытия и выявления, а также повышают быстродействие приложений, т.к. во время исполнения (in run-time) программы уже не производится динамический вывод (type inference), проверка (type matching), диспетчеризация (dynamic dispatching) и связывание (type linkng) типов, что не вызывает задержек проверки типов по времени исполнения кода, а только сокращает их и таким образом ощутимо повышает производительность и скорость исполнения кода приложения.

https://engineering.instagram.com/let-your-code-type-hint-itself-introducing-open-source-monkeytype-a855c7284881

https://github.com/Instagram/MonkeyType

#Python

Ссылки на материалы по теме:
О CPython+Mypy, постепенной типизации (gradual typing) и source maping отладке run-time исключений с применением Sentry:
https://t.me/technologique/1124
https://t.me/technologique/1125
https://t.me/technologique/155

https://www.python.org/dev/peps/pep-0484/
https://github.com/python/mypy

Оптимизация критических участков проектов на Python с помощью Rust:
https://t.me/technologique/1123
https://t.me/technologique/1153

​​Популярность языков программирования за 2017 год.

Данные популярности языков программирования за 2017 год по уровню контрибуции/вклада разработчиков на разных языках в кодовую базу репозиториев на хостинг-сервисе открытых проектов GitHub.

Уровень контрибуции (contribution rate) рассчитывается сервисом Krihelimeter на основе данных о частоте и объёме коммитов кода на различных языках программирования в репозитории проектов на хостинге GitHub.

Визуальное графическое представление данных - https://plot.ly/~andrcmdr/5.embed

Полная диаграмма - https://plot.ly/~andrcmdr/5/#plot

Исходные данные:
https://plot.ly/~andrcmdr/5/#data

https://plot.ly/~andrcmdr/4/#data
https://plot.ly/~andrcmdr/4.embed

Предыдущие публикации:
https://t.me/technologique/1122

С наступающим Новым годом друзья! Желаем Вам отлично встретить Новый год в кругу близких и друзей!

Пусть в Новом году технологии помогают Вам в повседневной жизни, облегчают и делают её более комфортной!

#NewYearsEve

Счастливого Нового Года друзья! ☃️🎄🎁🍊🥂🍾🎉🎊

2018 is actually came!

TDLib - официальная библиотека для создания клиентских приложений от Telegram.

Telegram выпустил официально кросс-платформенную библиотеку для создания клиентсикх приложений и взаимодействия с серверной частью мессенджера по протоколу MTProto 2.0 (обеспечивается полная поддержка протокола).

https://github.com/tdlib/td
https://core.telegram.org/tdlib

Документация:
https://core.telegram.org/tdlib/docs/

Библиотека кроссплатформенная и достаточно просто компилируется практически для любой платформы и ОС, и таким образом пригодна для создания клиентов для любых платформ.

Библиотека реализована на C++, но есть интерфейсы для возможности её использования в других языках (Java, интерфейс с JNI/JNA, и С#, через поддержку C++/CLI в .Net).
В Python скриптах функции библиотеки очень просто использовать через ctypes или cffi модули поддержки FFI в языке.
Для совсем не поддерживаемых официально языков есть интерфейс для обмена данными в формате JSON (JSON-RPC).

Для многопоточной неблокирующей (асинхронной) обработки ввода-вывода TDLib использует собственную реализацию библиотеки акторов для работы с тред-пулами (thread-pools) — https://github.com/arseny30/tdactor

Акторная модель многопоточности для многопоточной асинхронной обработки ввода-вывода и нативная компиляция, используемые в реализации бибилотеки, также обеспечивают очень высокое выстродействие при обработке API вызовов — заявляется, что библиотека TDLib уже давно используется в продакшн сервер-сайде Telegram для поддержки BotAPI и обработки ввода-вывода при взаимодествии с ботами, при этом каждый инстанс серверного приложения для поддержки BotAPI, использующий TDLib поддерживает взаиможействие с 18000 ботов одновременно, что говорит о весьма хорошем масштабировании приложений по нагрузке при использовании библиотеки и о грамотных решениях (actor-based concurrency), заложенных в её дизайн.

In the Telegram Bot API, each TDLib instance handles more than 18000 active bots simultaneously.

https://github.com/tdlib/td/tree/master/tdactor
https://github.com/tdlib/td/tree/master/benchmark
https://github.com/tdlib/td/blob/master/benchmark/bench_actor.cpp

Links:
https://t.me/technologique/1197

Meltdown & Spectre.

Опубликована информация по некорректной работе процессоров Intel, приведшей к двум критическим уязвимостям, касающимся особенностей аппаратной реализации в процессоре защиты страниц памяти ядра и приложений (Meltdown), её поддержки ядрами современных ОС (главным образом Linux и Windows), а также работы процессорного конвейера (pipeline) и спекулятивного предсказания инструкций при переходах и ветвлении кода (Spectre).

Уязвимы процессоры выпускавшиеся последние 10 лет, начиная с поколений архитектур Nehalem и Sandy Bridge.

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

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

https://lwn.net/Articles/738975/

Атака эксплуатирующая уязвимость Meltdown позволяет в непривелегированном режиме читать данные из адресного пространства ядра, вынесенные в user space memory, а также возможна запись кода в данные области памяти с последующим их исполнением в привелегированном режиме работы ядра.

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

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

Однако первая эксплуатация была проведена 1.5 года назад и отчёт по данным уязвимостям был сдан в Intel ещё в июне 2016 года.

Для предотвращения атаки Meltdown в Linux возможно применение двух уже вышедших и включенных в ядро патчей - KAISER и kernel address space layout randomization (KASLR).

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

На данный момент разработчики ядра Linux, патча KAISER и патч-сета GRSecutiry ведут разработку патча Kernel Page Table Isolation (KPTI) на базе патча KAISER.

Описание уязвимости:
https://meltdownattack.com и https://spectreattack.com (доменные псевдонимы одного и того же сайта)

https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

http://www.opennet.ru/opennews/art.shtml?num=47849

#security

See also:
https://t.me/technologique/709
https://t.me/technologique/710

https://t.me/technologique/964
https://t.me/technologique/999
https://t.me/technologique/1004

Кто кодил на мнемонике ассемблера 80x386/586/686 знает, что при передаче инструкций и указателей на конвейер в процессорах Intel они никак не проверяются (просто либо исполняются либо возвращается исключение, либо происходит остановка конвейера, операция Halt) — проблема давняя и уходит глубоко корнями в историю.
Сейчас процессорами проверяется только пометка страниц памяти NX битом неисполнения и контекст управляющих контрольных регистров (CR), при восстановлении контекста исполнения кода содержащегося в странице памяти. При этом не все ядра используют весь блок регистров CR и не все кольца привелегий (всего 4, от 0 до 3 в числовом представлении регистра), задаваемые регистром CR0, в т.ч. ядро Linux и ядро Windows, которые используют только два кольца, ring0 для адресного пространства памяти с привелегиями ядра (модулей ядра, драйверов и некоторых резидентных демонов) и ring3 для остальных пользовательских приложений, что во многом обусловлено требованием переносимости ядер на другие аппаратные процессорные архитектуры.
Кольца привелегий были введены впервые программно в ОС Multics, предшественнице Unix, разработанной также в Bell Labs в 1960-x годах. Ядро Multics поддерживало программно 64 кольца (http://www.multicians.org/mgr.html#ring, http://www.multicians.org/protection.html), но аппаратно железо того времени поддерживало только 8 колец.

Для создания более безопасного окружения для исполнения приложений сборка ядра Linux должна быть с поддержкой nx-bit и security модулями (SELinux, AppArmor), и патч-сетом grsecurity (включая патч PaX).
В этом случае для создания безопасного окружения приложений лучше использовать специализированные дистрибутивы, например микро-дистрибутив Alpine Linux (лучше дополнительно в Docker контейнере), сборки ядра которого содержат данные патчи.

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

В процессорах AMD, при исполнении кода в конвейере, спекулятивном эвристическом предсказании переходов для оптимизации циклов, трансляции адресов памяти через TLB кэш, инструкции и указатели проверяются и исполняются согласно уровню привелегий и контексту безопасности управляющих регистров, поэтому архитектурных проблем в процессорах AMD нет — https://lkml.org/lkml/2017/12/27/2

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

Многие IT издания и СМИ пишут о данных уязвимостях как исключительно аппаратных, ставя в вину Intel и нанося ущерб репутации компании, и при том не разделяя особенности аппаратной реализации и её программную поддержку со стороны ядер ОС и не вникая в суть проблемы, т.е. практически все СМИ пишут только об аппаратной архитектурной проблеме, но никто не акцентирует внимания на программной поддержке средств безопасности, предоставляемых современными процессорными аппаратными архитектурами, уровнях/кольцах привелегий, контексте безопасности при сохранении/восстановлении состояния регистров при исполнении кода, пометке страниц памяти и защите сегментов памяти от записи/изменения кода или исполнения данных в них.
Это вызвало уже ответную реакцию и критику со стороны самой Intel - https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Meltdown и Spectre это лишь названия, две грани одной давней проблемы, огреха в дизайне железа при его проектировании и производстве, за которыми по сути стоит одна и та же проблема контроля привилегий при упреждающей (с предсказанием переходов/возвратов) обработке инструкций в конвейере суперскалярной архитектуры соверменных процессоров (параллелизм выполнения на уровне инструкций).

На данный момент опубликованы лишь уязвимости с возможностями чтения привилегированной памяти ядра из непривилегированного режима исполнения пользовательского кода приложений:
Spectre:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
https://nvd.nist.gov/vuln/detail/CVE-2017-5715
https://nvd.nist.gov/vuln/detail/CVE-2017-5753
Meltdown (тайминг атака, через анализ кэша данных, https://habrahabr.ru/post/346078/):
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
https://nvd.nist.gov/vuln/detail/CVE-2017-5754

https://support.f5.com/csp/article/K91229003

Если посмотреть на время попадания (не публикации!) уязвимостей в базу MITRE - 20170201 - становятся вполне оправданной информация, что первая эксплуатация была проведена 1.5 года назад и отчёт по данным уязвимостям был сдан в Intel ещё в июне 2016 года.

Но есть ещё более глубокая проблема в дизайне cуперскалярной архитектуры Intel - injection through the return predictor.