Для ОС Redox, написанной на языке Rust, удалось произвести bootstrapping - скомпилировать всю ОС и ядро под самой ОС Redox.

Для этого под ОС были портированы компиляторы GCC toolchain и LLVM Compiler Toolchain, для портирования компилятора языка Rust - rustc.

https://www.redox-os.org/news/gsoc-self-hosting-1/

Разработчики компилятора OCaml Compiler Toolchain при оптимизации циклов в генерируемом компилятором коде программ на практике нашли баги при исполнении процессорами Intel блоков инструкций в коротких циклах в многопоточном режиме Hyper-Threading. Проблема касается процессоров Intel последних поколений, Skylake и KabyLake.
Обновления микрокода для некоторых моделей процессоров уже готовы для дистрибутива Debian.

https://lists.debian.org/debian-devel/2017/06/msg00308.html

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

Линус Торвальдс и Дирк Хоундл (VP, VMWare) - беседа на открытии первой ежегодной конференции LC3 China (LinuxCon + ContainerCon + CloudOpen) в Пекине.

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

https://www.lfasiallc.com/linuxcon-containercon-cloudopen-china

https://www.linuxfoundation.org/announcements/linuxcon-containercon-cloudopen-comes-to-china-for-first-time-2017

https://www.linux.com/blog/event/LC3-China/2017/linux-foundation-brings-3-new-open-source-events-china

Состоялся релиз языка и компилятора Crystal 0.23.0.

Появилась поддержка CSP многопоточности (как в Go, но со вкусом Ruby 😉) на базе сопрограмм, каналов и тред-пулов для маппинга программных потоков (нитей, fibers, green threads) на системные потоки в thread-pool'е процесса программы.
Для сборки компилятора требуется LLVM 3.8.

https://github.com/crystal-lang/crystal/releases/tag/0.23.0

Иерархическая классификация типизированного лямбда-исчисления, на базе лямбда куба Барендрегта, и его поддержка в языках функционального программирования:
https://gist.github.com/andrcmdr/7121c3d9eb83f06785d8055a5c3604a3


PS:
В январе-феврале этого года я прошёл курс Ерика Мейера по Haskell на EDX:
https://www.edx.org/course/introduction-functional-programming-delftx-fp101x-0

А после прослушал дополнительно курс практических лекций по Haskell:
https://www.youtube.com/watch?v=02_H3LjqMr8

https://www.youtube.com/playlist?list=PLwwk4BHih4fj2fxUuHEfvwNN84LALr5R3

Всем, кто интересуется и изучает концепции функционального программирования - очень рекомендую! 👍

Дискуссия с Крисом Лэттнером по дальнейшему развитию языка Swift на конференции WWDC 2017.

https://youtu.be/4qX1o-4W0HM

https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/

Видеозапись дискуссии можно также найти здесь:
https://news.realm.io/news/wwdc-2017-swift-panel/

Языку Swift и его компилятору сейчас действительно не хватает безопасной и внятной модели работы с потоками и их памятью, для удобного создания многопоточных приложений, т.к. на уровне языка нет поддержки работы с потоками (на базе сопрограмм или акторов) и асинхронным неблокирующим вводом-выводом (futures and promises, async/await, event-based async). Есть только фреймворк Grand Central Dispatch (GCD), который использует thread-pool pattern и мьютексную блокировку доступа к памяти потоков для управления критическими секциями. При использовании GCD код превращается в бесконечную пирамиду вызовов ("handler pyramid of doom", "call-back/closures hell").
Таким образом Swift не обеспечивает thread safety и код использует общую память для потоков (критические секции, shared mutable memory, shared mutable state), а без обеспечения thread safety про Server API (https://swift.org/server-apis/) и применение Swift в разработке ПО для серверных облачных инфраструктур можно забыть.

Ксавьер Лерой, разработчик группы проекта Gallium из института INRIA в Париже, во Франции, один из авторов языка OCaml и основных разработчиков его компилятора и виртуальной машины, рассказал подробности об обнаруженном им баге в процессорах Intel, при отладке оптимизации циклов компилятором OCaml для исполнения генерируемого компилятором кода в многопоточном режиме Hyper-Threading на архитектурах процессоров Intel последних поколений (Skylake и KabyLake).

http://gallium.inria.fr/blog/intel-skylake-bug

http://ocamllabs.io/general/2017/06/26/IntelHyperThreadBug.html

Перевод на русский язык:
https://habrahabr.ru/post/332552/

Oracle создали открытый run-time для контейнеризации в Linux на Rust - проект RailCar.

Проект RailCar создаётся на Rust на базе спецификации OCI (Open Container Initiative Runtime Specification, https://www.opencontainers.org) и претендует на положение серьёзной альтернативы и конкурента Docker, другой реализации спецификации OCI на Golang, от очень серьёзного поставщика облачных систем и решений - Oracle.


https://blogs.oracle.com/developers/building-a-container-runtime-in-rust

https://blogs.oracle.com/developers/three-new-open-source-container-utilities

https://thenewstack.io/oracle-opens-oci-container-runtime


https://github.com/oracle/railcar - run-time для управления контейнерами

https://github.com/oracle/crashcart - инструмент для отладки контейнеров с возможностями загрузки (sideload) в контейнер сторонних образов с исполняемыми файлами

https://github.com/oracle/smith - сборщик образов контейнеров на базе образов OCI или RPM пакетов


https://github.com/opencontainers/runtime-spec - спецификация OCI run-time

https://github.com/opencontainers/image-spec - спецификация образов OCI

https://github.com/opencontainers/runc - реализация OCI, базовый run-time для порождения процессов контейнеров


Причины создания RailCar и почему Go не так хорош для создания run-time для систем конейнеризации:

https://blogs.oracle.com/developers/the-microcontainer-manifesto

https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix


Links:
https://xn--r1a.website/technologique/971

OOP versus FP - почему противопоставление парадигм программирования является некорректным.

Аргументы FP.

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

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

Одна из тех статей к которой всегда интересно вернуться, перечитать её и переосмыслить ещё раз:
http://blogerator.org/page/oop_why-objects-have-failed

Плюс более прагматичный практический взгляд на данный вопрос в статье на русском языке:
http://eax.me/adt-and-traits/

В этой статье Александр Алексеев весьма верно отметил - сейчас ООП подход у каждого свой, у каждого языка и евангелиста.

Вот по большому счету и все, что нужно знать об АТД и классах типов. Если вы загляните на Hackage, то обнаружите, что с их помощью на практике можно реализовать что угодно. А зачем нам дополнительная сложность? Фактически, мы можем избавиться от иерархии классов (интерфейсы не считаются). В этом случае нам не нужно никакой там ковариации и контрвариации, восходящего и нисходящего преобразования, абстрактных классов, protected методов и так далее (за редкими исключениями, в основном связанными с наследием Java, см. определение MyMaybe выше). В общем, все плоско, как в... Go! Плоские абстракции only - плоское лучше чем вложенное (из манифеста Python).

Недаром в современных языках программирования, взять хотя бы Rust и Go, нет никакого наследования. Потому что наследование это полиморфизм подтипов и он не нужен, потому что сам по себе решается композицией типов! 😆😂👍

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

Останутся интерфейсы/трейты/тайпклассы (классы типов), что в принципе одно и то же по концепциям, но называется по разному, их имплементации/имплементоры и параметризованные типы (generics, параметрический импредикативный полиморфизм) - это то же самое модульное структурное программирование! Никаких классов и наследования! Ещё в Модула-2 были модули с интерфейсами и их имплементациями. Потом эти же концепции перекочевали в Оберон, а далее в Go и Rust.
Нужны только интерфейсы, структуры, перечисления, как в Go, Rust и Виртовских языках. Через нетипизированные интерфейсы в Go можно реализовать поведение параметризованных типов, тех самых дженериков, которых якобы в Go нет.

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

Мне понравилось как этот процесс смещения акцентов в программировании объяснил Саймон Пейтон Джонс, большой спец по Haskell и автор его основного компилятора GHC:
https://youtu.be/iSmkqocn0oQ


Контраргументы OOP.

Сегодня на конференции услышал мнение одного из разработчиков, программиста с многолетним опытом на Haskell (но в компании он пишет на Rust и OCaml), что лингвистическим дизайнерам ФП языков приходится в них встраивать инкапуляцию из ООП (для type class'ов, функций и данных в OCaml и Haskell например) как дополнительный инструмент структурирования программ и проектов, потому что ФП парадигма в чистом виде (основанная на видах типизированного лямбда-исчисления) не имеет достаточных средств для структурирования очень крупных проектов (кроме функций различных порядков) и не позволяет этого делать, хотя в OCaml и Haskell помимо type class'ов, есть функторы (функции как объекты), монады (эндофункторы, для последовательного стуктурирования кода программ, например ST монада в Haskell для придания коду императивного вида и поведения) и конечно модули, но они опять же были привнесены в языки из структурного имеративного программирования, для структурирования очень крупных проектов.

Я решил проверить эту мысль и провести небольшое практическое исследование - отыскать очень крупные проекты на функциональных языках по объёму кода в количестве SLoC и посмотреть на используемые в этих проектах средства структурирования, используя https://openhub.net (бывший https://ohloh.net) - и по результатам исследования был несколько удивлён тому факту, что все проекты c кодовой базой более 1M SLoC использующие ФП языки (в основном OCaml, Haskell и Erlang) прибегают к императивным средствам структурирования программ.

Мартин Одерски об этом говорил в одном интервью на YouTube в котором он рассказывал об истоках Scala. Он рассматривал ООП для Scala как раз как средство модульности и средство структурного программирования для ФП, да и вообще Мартин в целом рассматривает объекты как модули, но более локального действия, в пределах обычных модулей/пакетов.

Все забыли, что ООП было создано для улучшения структурного программирования и привнесения в него большей модульности, компонентного подхода к проектированию программ, очень крупных проектов.
Были забыты и извращены идеи и концепции положенные в основу ООП и изначально возникшие в языках Simula, Smalltalk, Self - эти идеи были прекрасны!
Сейчас они живы в языках Objective-C и Ruby - это самые близкие к концепциям Smalltalk языки - и отчасти в Python и Swift.

ООП концепции которые были в версии Xerox Smalltalk изначально, бывшие инженеры Apple, выкупив их ранее у Xerox и будучи уже в команде Стива Джобса в Next, привнесли в Си и создали Objective-C, объектный Си, для разработки ОС NextStep, системных библиотек и графического интерфейса.

В Ruby Matz сам говорил что многое взял из Smalltalk - гомоиконность системы типов, интроспекцию типов, run-time рефлексивность языка и его системы типов.

Поэтому в Ruby и Objective-C очень сильно ощущается наследие Smalltalk.

Интересная видео лекция об истоках чистого ООП, языках Smalltalk и Objective-C:
https://youtu.be/mdhl0iiv478

Алана Кэя, автора Smalltalk, также всегда интересно послушать:

https://youtu.be/NdSD07U5uBs

https://youtu.be/KVUGkuUj28o

https://youtu.be/M6ZHxUwqPVw

На пути к Go 2.0 - Расс Кокс о дальнейшей эволюции Golang на конференции GopherCon 2017

https://blog.golang.org/toward-go2

На русском:
https://habrahabr.ru/post/333346/

Грядущие изменения в Go 1.9:
https://beta.golang.org/doc/go1.9


#Go
#Golang

Интересное обсуждение у нас возникло сегодня по теории компиляции, автоматному программированию, системам типов и применению типизированного лямбда исчисления для систем типов и строгого контроля типов, для статического анализа программ (и side-effect'ов в частности), математического доказательства безопасности систем типов, безопасности программ и их завершённости.
Язык OCaml уже давно доказал свою эффективность в этой области computer science и практическую применимость для создания компиляторов, статических анализаторов кода, парсеров, а также для создания системного программного обеспечения в целом (проекты Unikernel, MirageOS и ClickOS, которые ныне являются частью компании Docker и на базе которых создаются проекты Moby и Linux Kit [1] ).

По этом поводу и теме есть замечательная книга - Real World OCaml.

https://realworldocaml.org/v1/en/html/index.html

Часть вторая - parsing, tooling:
https://realworldocaml.org/v1/en/html/pt02.html

Часть третья - теория компиляции и автоматное программирование:
https://realworldocaml.org/v1/en/html/pt03.html

https://realworldocaml.org/v1/en/html/the-compiler-frontend-parsing-and-type-checking.html

https://realworldocaml.org/v1/en/html/the-compiler-backend-byte-code-and-native-code.html

Есть также книга Ксавье Лероя, автора OCaml - Unix system programming in OCaml:
http://ocaml.github.io/ocamlunix/

http://ocaml.github.io/ocamlunix/ocamlunix.pdf

https://github.com/xavierleroy

И ещё пара книг Ксавье Лероя, правда на французском:
http://caml.inria.fr/pub/distrib/books/manuel-cl.pdf

http://caml.inria.fr/pub/distrib/books/llc.pdf


Links:
[1] - https://xn--r1a.website/technologique/960

Второй трейлер киберпанк триллера "Blade Runner 2049".

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

Трейлер о процессе съёмок фильма, с мнением актёров и съёмочной группы:
https://www.youtube.com/watch?v=BBsjZgu7T2U

Продолжение спустя 35 лет обещает быть очень интересным! 👍

Выпуск "Синего Фила" с Дмитрием Пучковым про фильм Blade Runner (1982) с весьма грубоким анализом сценария от Клима Жукова:
https://www.youtube.com/watch?v=BCgcPZHiZms&t=7m56s

О некоторых моментах фильма я даже не догадывался, он также полон библейских мотивов, как и другие фильмы Ридли Скотта, например "Прометей" и "Чужой: Завет", и даже имеет с ними общую киновселенную!
https://www.youtube.com/watch?v=BN5jZLf1AaM


#киберпанк
#cyberpunk

Шикарный спич на недавней конференции C++Now 2017, прошедшей в мае, от Нико Матсакиса, одного из основных разработчиков Rust!

Нико очень простым языком на примерах объясняет весьма сложные концепции, например как устроена идиома контроля заимствований и владений (borrow and ownership checker), которая является гарантом безопасности сегментов памяти и защищает критические секции памяти от записи в них при совместном доступе к ним нескольких исполняемых потоков в многопоточном режиме.

https://www.youtube.com/watch?v=lO1z-7cuRYI

Оказывается, Нико также как и я в школе в своё время сильно улекался C++, очень ждал в качестве подарка (правда я на день рождения) тот самый справочник Герберта Шилтда по C++ и зачитывался им! Ностальгические воспоминания, such same feelings! 😄👍

https://www.youtube.com/watch?v=lO1z-7cuRYI&t=1m9s

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

Тот самый справочник, до сих пор со мной, спустя 14 лет! 😄😭😂👍

О возможностях безопасного автоматического управления памятью в Rust.

В Rust используется механизм подсчёта ссылок (ARC), доступный в LLVM, но проблему thread safety, критических секций и сильных/слабых указателей решили применением заимствования доступа к сегментам памяти и дополнительным механизмом проверки владений и заимствований - borrow & ownership checker, который проверяет все strong и weak references на соответствие и наличие циклических указателей (в RC механизме интерпретатора Python тоже есть подобный механизм).
И этот механизм - основная идиома безопасности памяти в Rust.
Помимо этого есть автоматические scope-based деструкторы - механизм RAII, который также есть в Vala, Genie и D; raw memory management через unsafe блоки; region based memory management, которое редко используется, чаще в unsafe режиме доступа к памяти; cам ARC механизм; но также есть и потенциальная возможность применения GC в Rust, например того же Boehm GC или иного, язык эту возможность не ограничивает, но возникает вопрос, зачем он нужен если даёт дополнительный run-time overhead и есть более эффективные механизмы проверок для безопасного автоматического управления памятью, позволяющие вообще исключить применение GC и связанные с его применением STW latency потоков, и иметь в run-time только саму программу в чистом виде, которая сама по себе самостоятельно и безопасно утилизирует память с минимальными накладными расходами на автоматическое управление памятью.

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

https://ts.data61.csiro.au/Events/summer/16/lin.pdf

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf

https://aturon.github.io/blog/2015/08/27/epoch/

https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/

https://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/

https://github.com/Manishearth/rust-gc

https://crates.io/crates/gc

https://docs.rs/gc/0.3.0/gc/

Tammy Butow на GopherCon 2017 - о крупномасштабном внедрении и использовании Golang в DropBox.

https://about.sourcegraph.com/go/go-reliability-and-durability-at-dropbox-tammy-butow

https://gophercon.com/speakers/14


Постепенно оправдывается всё то, о чём ещё в 2012 году писал Роб Пайк и для чего Go был задуман - для разработки крупномасшабных масштабируемых сервисно-ориентированных облачных инфраструктур.

https://talks.golang.org/2012/splash.article


Links:
https://xn--r1a.website/technologique/1008
https://xn--r1a.website/technologique/841

Отличный инструмент для визуализации и анализа данных профилирования приложений - pprof

На GitHub Джааной Доган (Google) было предложено реализовать в веб интерфейсе pprof возможности Flame Graph визуализации - голосуте все, кто заинтересован:
https://github.com/google/pprof/issues/166

Подобный более узкоспециализированный инструмент для профилирования Go приложений и Flame Graph визуализации уже был разработан в Uber:
https://github.com/uber/go-torch

Ранее инженеры Netflix использовали инстументы Flame Graph визуализации для профилирования сервер-сайд Node.js приложений под большой нагрузкой, в результате чего были обнаружены и исправлены серьёзные узкие места в роутере Express.js фреймворка и платформе Node.js:

https://medium.com/netflix-techblog/node-js-in-flames-ddd073803aa4

http://brendangregg.com/flamegraphs.html

Перевод на русский язык:
https://habrahabr.ru/post/243945/

Trifle, but nice! 😄👍

Приятная мелочь - в Telegram сделали возможность редактировать свою bio, для большего эксгибиционизма пользователей. 😁😂👍

Павел об этом писал не так давно, 31 октября 2015 года - https://xn--r1a.website/durov/33

Недавно bio по просьбам пользователей решили вернуть:
https://twitter.com/durov/status/886471494863290368

В официальных клиентах возможность отображения bio появится чуть позже (а после и в Plus), но в API бэкэнда эти возможности уже есть.

Редактирование bio практически сразу реализовали в неофициальных клиентах, после появления данной возможности в API бэкэнда и немного позже, буквально вчера, в Telegram Beta:
https://fabianpastor.github.io/webogram

Update:

Сегодня возможность редактировать bio добавили в мобильный клиент Telegram и в кодовую базу мобильного клиента на GitHub.

https://telegram.org/blog/now-you-see-me

https://github.com/DrKLO/Telegram

Links:
https://xn--r1a.website/technologique/856
https://xn--r1a.website/technologique/912