Андерс Хейлсберг о нововведениях в 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://xn--r1a.website/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://xn--r1a.website/technologique/343 =)
https://xn--r1a.website/technologique/720
https://xn--r1a.website/technologique/1002
https://xn--r1a.website/technologique/1006
https://xn--r1a.website/technologique/1007
https://xn--r1a.website/technologique/1051
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1054
https://xn--r1a.website/technologique/1072

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

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

Ссылки:
https://xn--r1a.website/technologique/1054
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/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://xn--r1a.website/technologique/583
https://xn--r1a.website/SysadminNotes/530
https://xn--r1a.website/HighLoadConfChannel
https://xn--r1a.website/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://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