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

Информация также отображается веб сервисом t.me (telegram.me).

Товарищи с Хабра провели отличное интервью с Аланом Кейем, автором SmallTalk и очень крупным учёным в области computer science, разработавшем в конце 60-х будучи в Xerox PARC очень много ИКТ технологий, ставших нашей сегодняшней реальностью.

https://habrahabr.ru/post/333778/

С сорокового вопроса начинаются очень интересные ответы по части технологий программирования.

44:

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

58:

Религиозный культ становится злом даже если пытается быть добром, потому что сталкивается с трудностями по отношению к различным изменениям мира — а ещё бывает и так, что культ возникает относительно неправильных идей. Поэтому убрать всякий «религиозный культ» из компьютерной сферы было бы большим благом. Настоящий вопрос заключается в следующем: как создавать системы, в которых «простые вещи были бы просты, а сложные вещи — возможны». Это, в том числе, подразумевает возможность измененения своей точки зрения на вещи со временем, а также способность осуществлять изменения, затрачивая разумное количество усилий.

И в дополнение мысль Алана о сегодняшних технологиях разработки ПО из другой весьма интересной статьи (https://www.itweek.ru/idea/blog/idea/3254.php):

Одна из наиболее катастрофичных вещей в программной инженерии - это шаблоны программирования. Извлечение паттернов из сегодняшних практик разработки излишне их облагораживает. Создается замкнутый круг: из практик программирования, очень далеких от оптимальных, извлекаются шаблоны, затем этим шаблонам обучаются другие люди, и превращают практику программирования в еще более шаблонную и ограниченную!

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


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

https://youtu.be/NdSD07U5uBs

https://youtu.be/KVUGkuUj28o

https://youtu.be/M6ZHxUwqPVw

https://habrahabr.ru/company/edison/blog/310588/

И раз уж речь зашла про паттерны проектирования - Марио Фуско из Red Hat большой оригинал в этом деле и преподнёс весьма элегантное решение для упразднения ООП паттернов проектирования.
Он буквально вывернул наизнанку ООП паттерны проектирования, спроецировал и привёл их к функциональной парадигме, где программы проектируются с использованием лямбда исчисления и функций высших порядков, и структурируются с помощью функторов и монад, как структурного паттерна для проектирования приложений.

The book of design patterns known as Gang of Four has been a kind of Bible for all the developers of my generation.
Nevertheless the biggest issue with this is that almost all patterns listed in that book, especially the behavioural ones, are a only workaround for a missing abstraction: higher order functions.

https://www.youtube.com/watch?v=lZG74WbnhoE&feature=youtu.be&list=PLRsbF2sD7JVq8QYW0vlbOS2JuXUWaWMnT

https://github.com/mariofusco/from-gof-to-lambda

https://github.com/lmller/gof-in-kotlin

https://github.com/truizlop/GOFToLambda


PS:
Огромная благодарность за материалы для крайних двух постов Люгеру (@Luger_08) - во многом благодаря нашим регулярным дискуссиям о технологиях программирования рождаются интересные мысли и посты, которыми живёт и полнится наш канал. 👍

Весьма интересный и близкий нам канал о технологиях программирования на С, C++, Go и Python, а также о Linux, ведёт Сергей Аббакумов - Sea++. Подписывайтесь на канал, чтобы поддержать автора в его стремлении писать больше об этих технологиях программирования.

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

Мне понравилась серия постов про обработку ошибок и исключений в С++:

https://xn--r1a.website/sea_plus_plus/22 - про использование идиомы RAII (деструкторной техники освобождения ресурсов) в обработке исключительных ситуаций

https://xn--r1a.website/sea_plus_plus/23 - про сравнение с методом обработки исключений в Go

В Go обработка исключений и ошибок происходит посредством возврата состояний через тип-интерфейс error. [1] [2] [3] [4]

https://xn--r1a.website/sea_plus_plus/24 - про класс Expected<T> от Андрея Александреску, соавтора D и стандартной библиотеки языка D (библиотеки Phobos).

О подобном способе обработки исключений в Java, посредством класса Either<MyError, MyResult>, как альтернативе checked exceptions, писал недавно Марио Фуско из RedHat в Twitter.