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

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://xn--r1a.website/technologique/651
https://xn--r1a.website/technologique/663
https://xn--r1a.website/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://xn--r1a.website/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

Fearless concurrency in Rust, Servo Engine & Firefox Quantum.

Про безопасность и целостность памяти (thread safety, lock-free, race-free), контроль указателей через механизм владений и заимствований памяти (borrow and ownership checking), которую обеспечивает система типов (субструктурная система уникальных типов, sub-structural uniqueness types system) языка Rust при создании браузерного движка Servo/Quantum и любых других многопоточных приложений.

https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html

https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

Про библиотеку параллельнных структур данных и параллельной обработки данных Rayon - https://xn--r1a.website/technologique/1041

#Rust

Ссылки:
https://doc.rust-lang.org/book/first-edition/concurrency.html

https://doc.rust-lang.org/book/second-edition/ch16-00-concurrency.html
https://doc.rust-lang.org/book/second-edition/ch16-01-threads.html
https://doc.rust-lang.org/book/second-edition/ch16-02-message-passing.html
https://doc.rust-lang.org/book/second-edition/ch16-03-shared-state.html
https://doc.rust-lang.org/book/second-edition/ch16-04-extensible-concurrency-sync-and-send.html

https://github.com/nikomatsakis/concurrency-tutorial

Коротко о последнем апдейте клиентов до версии 4.5 и глобального поиска в Telegram:
https://telegram.org/blog/albums-saved-messages#improved-search

24 октября я предложил улучшить глобальный поиск каналов, потому что через клиентские приложения поиск не искал нормально, только через Google или другой поисковик можно было находить каналы по описанию:
https://twitter.com/andrcmdr/status/922594877568901120

Павел @durov услышал и всё правильно сделал!
И месяца не прошло!
Здорово, что можно вот так просто предлагать идеи в Twitter команде и быть услышанным - обратная связь работает!

Любая мелочь может улучшить юзабилити, поэтому будьте активнее и предлагайте ваши идеи улучшения Telegram! ✌️

Links:
https://xn--r1a.website/telegram/79

Интересная история о том, как пожилой программист воссоздал древний системный язык программирования SPITBOL, диалект языка SNOBOL, и сохранил его для истории благодаря GitHub.

Сам автор говорит о программировании на системном машинном уровне, как о потерянном искусстве (sad, but true), поэтому столь важно было сохранить разработанный им много лет назад и давно потерянный язык и его компилятор для истории на современных облачных носителях данных.

https://motherboard.vice.com/en_us/article/78x5ba/this-70-year-old-programmer-is-preserving-an-ancient-coding-language-on-github

SPITBOL is written at the assembly language level—low-level code that interfaces almost directly with hardware itself. Since most coding is now done at a higher level, Shields refers to SPITBOL as an important part of software history. "What's special about it is that it's the most elegant surviving example of coding at the machine level," Shields said. "The art of writing at the machine level is a lost art."

Янн ЛеКун, знаменитый исследователь методов разработки искусстенного интеллекта, разработавший модели свёрточных нейронных сетей (convolutional neural networks) для распознавания образов, ныне работающий директором по исследованиям проблем искусстенного интеллекта в Facebook AI Lab, с лекцией о возможностях, ограничениях и пределах границ в применении методов глубокого машинного обучения для анализа данных.

https://www.youtube.com/watch?v=0tEhw5t6rhc

Embedding Rust in Python. Next step.

Дело оптимизации и встраивания Rust в проекты написанные на Python развивается!
Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных комбинированных проектов на Python, содержащих бинарные модули написанные на Rust (и используемые через CFFI) а также на других системных языках (C/C++) совместимых по ABI, при помощи инфраструктуры систем сборки пакетов PIP (Python Wheels) и EasyInstall/SetupTools (Python Eggs).

Для Python проектов не нужно сильно заботиться о кросс-платформенной переносимости программ, если вы не используете специфичные для платформы API интерфейсы (например библиотеки GLib в GNU/Linux или интерфейс WinAPI в Windows, хотя и они сейчас переносимы в большинстве случаев - GLib кросс-платформенная библиотека проекта GNOME, а для WinAPI под Linux есть WINE) - в идеале если вы полагаетесь на стандартную библиотеку, то межплатформенная переносимость будет зависеть только от наличия сборки интерпретатора CPython для целевой платформы и её особенностей, например полноты стандартной библиотеки (сборки CPython есть для большинства платформ, даже экзотических).

Но что если в проекте есть оптимизации критических участков кода при помощи модулей, написанных на системных статически компилируемых языках (таких как C, C++ и Rust, который начал входить в область оптимизации существующих проектов), как в проекте Sentry, и такие зависимости тоже нужно контролировать, и создавать воспроизводимые сборки (reproducible builds) таких проектов при непрерывном интеграционном тестировании, формировании поставки и развёртывании таких проектов в облачной инфраструктуре (continuous delivery, deployment, continuous integration).

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

Идея состоит в том, чтобы из скриптов сборщиков пакетов Python вызывать сторонние системы сборки для внешних зависимостей проекта (в данном случае Cargo для сборки crate пакета/модуля, написанного на Rust) и статической компиляции бинарных исполняемых образов для целевой платформы — всё для создания переносимых кросс-платформенных сборок таких комбинированных компонентных проектов и их зависимостей.

Для этого и была создана библиотека Milksnake, для расширения функциональности систем сборки пакетов для Python. Она подходит для подключения не только Cargo в качестве внешнего сборщика, но и билд-систем сборки для других языков,

https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake

https://github.com/getsentry/milksnake

Так же для тех, кто интересуется темой воспроизводимых сборок (reproducible builds), в комбинированных проектах на скриптовых и статически компилируемых языках, советую посмотреть на билд-систему Meson, которая используется в проекте дистрибутива Debian, проекте GNOME, написана на Python и позволяет делать сборки проектов на Python, Rust, Vala, Genie, D, Си и C++.

http://mesonbuild.com

https://github.com/mesonbuild/meson

https://reproducible-builds.org

Ещё одна интересная статья из блога для разработчиков RedHat по этой же теме оптимизации критических участков программ на Python при помощи Rust и сборке таких проектов.

https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/

Инициатива развития Nim в направлении GC free и raw pointer free программирования.

Автор языка Nim и его компилятора, Андреас Рампф (Andreas Rumpf), недавно написал о планах удаления механизма сборки мусора (GC) и перехода к ARC (atomic/automatic reference counting) модели управления памятью. Также планируется внедрить механизм контроля указателей подобный имеющемуся в Rust.

https://nim-lang.org/araq/destructors.html

https://nim-lang.org/docs/gc.html

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

http://telegra.ph/GC-free-and-raw-pointer-free-programming-10-21

Автор планирует сделать boxed указатели c системой типов для контроля их владений и заимствований поверх ARC механизма LLVM с применением автоматических деструкторов (RAII) - всё как в Rust. Но зачем всем нам ещё один "Rust" со смесью синтаксиса Object Pascal (Free Pascal, если быть точным - на нём в среде Windows был написан первый компилятор языка Nimrod, позже язык был переименован в Nim) и Python, ещё и с последующей трансформацией синтаксического дерева фронт-энд компилятором в слаботипизированный Си (промежуточная транс-компиляция), пока не очень понятно и не только мне, так как для Nim есть другие, до сих пор в полной мере не реализованные пути его улучшения, в первую очередь это поддержка событийно-асинхронного кода (event loop, async/await), различных моделей thread safety многопоточности (continuations, coroutines, channels, actors) и доработка стандартной библиотеки в этих направлениях. Это было в планах, об этом просит сообщество разработчиков, но планы реализуются крайне медленно.

И сейчас не понятно сколько предложенная инициатива будет реализовываться по времени, т.к. другие инициативы автора — улучшения thread safety (thread safe, lock-free, race-free, null references free, and so on!) и модели многопоточности (сопрограммы, каналы, акторы), а также иммутабельности данных в памяти (системы типов на базе эффектов - читайте системы зависимых типов или даже реализации транзакционной памяти в Nim!) — до сих пор не реализованы в полной мере в языке и лишь частично покрыты в стандартной библиотеке языка, и это спустя уже несколько лет после самих статей автора!

https://nim-lang.org/araq/concurrency.html

https://nim-lang.org/araq/concurrency2.html

https://nim-lang.org/araq/writetracking.html

Автоматическое управление памятью и система типов в Rust.

Фактически ARC и RAII единственно приемлемые методы автоматического управления памятью для системных языков.
Rust как раз полагается на ARC в LLVM бэкэнд компиляторе.
Но, поверх ARC механизма построен сильный строгий контроль типов и использования boxed указателей, благодаря субструктурной системе типов.
Swift также использует ARC механизм LLVM, но только с контролем владений (ownership - owned, unowned, weak refereces), пока без механизма заимствований указателей (borrowed pointers) на сегменты памяти.

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

Чисто системные языки не используют GC из-за STW задержек (stop-the-world latency) при обходе указателей в памяти (STW возникает в любом случае, даже в многопоточном GC, т.к. GC это дополнительный алгоритмический механизм поверх RC/ARC механизма подсчёта указателей), что не приемлемо для mission-critical и real-time задач, особенно для задач жёсткого реального времени (hard real-time) с гарантированным временем реакции/задержки.

Поэтому в Rust нет GC, т.е. вообще нет работающего GC в run-time, хотя есть сторонние proof-of-concept проекты реализующие GC для Rust:

http://dpzmick.com/2017/01/23/rust-arc-gc-realtime/
https://github.com/Manishearth/rust-gc
http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/
http://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/

В Rust нет динамизма времени исполнения, производится полный вывод типов в compile-time (CTTI, compile-time type inference), даже для полиморфных типов производится мономорфизация через субструктурную систему уникальных типов и в run-time при множественной диспетчеризации (multiple dispatch) типов срабатывает принцип автоматической подстановки экземпляра кода для обработки определённого заранее статически вычисленного типа выражения, но при этом выведенного в run-time (RTTI, run-time type inference) - столь сильная система типов необходима для строгой проверки выражений (eager/strict evaluation), для статических гарантий безопасности времени исполнения, безопасности типов данных и работы с ними, для безопасности и абсолютной предсказуемости поведения программы во время её исполнения (в run-time), статического анализа завершения/завершённости программы (escape analysis, termination analysis, totality checking) и гарантий полноты типов программы.
Именно на этих принципах, тотального/сильного функционального программирования (total/strong functional programming), использующего системы типов, основанные на типизированном лямбда-исчислении высших порядков, статическом анализе, анализе завершённости и полноты типов, основывается language based security, т.е. безопасность программ должна начинаться с языка и сильной системы типов для него.

Всё управление памятью Rust строится на субструктурной системе уникальных типов (substructural type system of uniqueness types) для контроля указателей поверх ARC механизма LLVM, плюс в Rust совместно с ARC механизмом используются автоматические деструкторы RAII.

В Nim (и других современных системных языках - Swift, Vala, Genie) нет uniqueness types, т.е. нет субструктурной системы уникальных типов, наподобие линейных типов (линейной логики), но ещё более сильной и строгой, для того чтобы обеспечить безопасность памяти и работы указателей так, как это сделано в Rust, а для внедрения такой системы типов нужно будет фундаментально переработать язык, компилятор и даже синтаксис, особенно синтаксис работы с boxed указателями, а указатели нужно будет обернуть (wrapped pointers, wrapping) в уникальные типы (boxing, box model) для контроля владений памяти и её заимствований указателями в различных потоках (при многопоточном программировании).

Для языков Vala и Genie фронт-энд компилятором производится синтаксический анализ (parsing) и трансформация абстрактного синтаксического дерева полученных лексем (AST, abstract syntax tree transformation) в язык Си, т.е. производится транс-компиляция в язык Си, так же как и во фронт-энд компиляторе Nim. Далее язык Си компилируется бэкэнд компилятором LLVM Clang. Библиотека Glib (набор системных библиотек проекта GNOME) используется как стандартная библиотека этих языков. Для автоматического управления памятью используются RAII и ARC механизм LLVM, но нет субструктурной системы типов, соответственно нет контроля указателей и не обеспечивается thread safety.

В целом - Nim (а тажке Swift, Vala, Genie) нельзя рассматривать как серьёзные системные языки и серьёзной конкуренции Rust и OCaml в области надёжного системного программирования в ближайшем будущем они составить не смогут, т.к. Rust и OCaml основываются на серьёзных фундаментальных исследованиях систем типов и изначально спроектированы для безопасного системного программирования и создания надёжных программ.

Rust и OCaml используют очень схожие системы уникальных типов (uniqueness types), основанные на λω (λ2 + λω_) исчислении, все проверки типов происходят в compile-time до фазы времени исполнения и с полным выводом типов в compile-time (CTTI). Достаточно сказать, что первая публичная версия компилятора Rust была написана Грейдоном Хоаром на OCaml - парсер был реализован с помощью макро-препроцессора Camlp4, код компилировался фронт-энд компилятором в LLVM IR/MIR представление.

Ссылки:

Swift:
https://xn--r1a.website/technologique/1095
https://xn--r1a.website/technologique/1096
https://xn--r1a.website/technologique/1097
https://xn--r1a.website/technologique/1098
https://xn--r1a.website/technologique/1099

Scala:
https://xn--r1a.website/technologique/1131
https://xn--r1a.website/technologique/1132
https://xn--r1a.website/technologique/1133

#обзор
#viewpoint

#Nim
#Rust
#OCaml

Доклады с недавнего Rust Hungary Meetup проходившего в столице Венгрии, Будапеште, 23 ноября.

https://www.meetup.com/Rust-Hungary-Meetup/events/244411460/

Нативные бинарные модули на Rust для Node.js.

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

Плюс статья:
https://blog.risingstack.com/node-js-native-modules-with-rust/

Оптимизация проектов, написанных на скриптовых языках при помощи бинарных статически скомпилированных модулей, написанных на Rust - это уже фактический тренд.

Ссылки по теме:
https://xn--r1a.website/technologique/1153
https://xn--r1a.website/technologique/1154
https://xn--r1a.website/technologique/1155

https://xn--r1a.website/technologique/1123
https://xn--r1a.website/technologique/1124
https://xn--r1a.website/technologique/1125

Nim safety.

На днях у нас с коллегой разгорелась интересная дискуссия о Nim safety, безопасен ли Nim и обеспечивает ли он безопасность (language based security) на уровне системы типов при написании программ.

В посте выше я утверждаю, что Nim не безопасен, поэтому автор языка и компилятора хочет сделать систему типов "как в Rust" для обеспечения безопасности работы с указателями, обернув их в типы (uniqueness types), с использованием субструктурной системы уникальных типов (на низком уровне в процессе статического анализа и компиляции программы) для контроля использования указателей и памяти, особенно в разных потоках при многопоточном программировании.

Для того, чтобы сделать Nim безопасным нужно в первую очередь переработать бэкэнд компилятор, чтобы он порождал LLVM IR/MIR код, имеющий проверки исключений, которые можно использовать в таком скомпилированном коде для реализации любой системы типов.

Существует также транс-компилятор Nim в JavaScript, который сейчас считается не иначе как языком "C-based language for web and mobile clients" или даже "web-based C" по своей семантике типов.

Но JS позволяет делать сложную проверку исключений на уровне самого языка и транс-компилятор в JS может генерировать шаблонный код всех проверок при AST трансформациях мета-языка (TypeScript, Dart, ReasonML), что позволяет реализовать любую систему типов поверх JS.

Поэтому транс-компиляция в JS - это ещё куда не шло, но код при этом не будет быстрее, т.к. базовый JS исполняется движком V8 который использует JIT компиляцию, но вывод, проверка, диспетчеризация и связывание типов происходят в run-time во время JIT компиляции, до полной компиляции проверок типов в машинный код, что и вызывает задержки по времени исполнения кода и V8 в этом плане уже оптимизирован до предела по скорости исполнения кода.

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

#Rust
#Nim

Ссылки:
https://news.ycombinator.com/item?id=9050999
https://www.reddit.com/r/programming/comments/3sa6lf/d_has_no_vision_go_is_out_of_its_depth_rust/cwvgh4k/

https://www.quora.com/Is-Nim-really-that-unsafe
https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#is-nim-unsafe
https://github.com/nim-lang/Nim/issues/3531
https://news.ycombinator.com/item?id=8936061
https://gradha.github.io/articles/2015/02/goodbye-nim-and-good-luck.html

А некоторые ещё и очень сильно обожглись в своих проектах, когда решили перейти с Rust на Nim:
https://news.ycombinator.com/item?id=9050114
https://news.ycombinator.com/item?id=10947761

https://xn--r1a.website/technologique/1157