Поглощение проекта CoreOS компанией RedHat.

Разработки проекта CoreOS будут интегрированы в дистрибутив RedHat Atomic и облачную инфраструктуру RedHat OpenShift.

https://coreos.com/blog/coreos-agrees-to-join-red-hat

https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos

https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership

Oracle Fn

Соонователь Iron.io, ныне директор по направлению serverless в Oracle, Чед Аримура рассказал подробнее о serverless/FaaS платформе Fn, применяемой для создания инфраструктуры микро и наносервисов, на базе Docker, Kubernetes и написанных на различных языках программирования.

https://youtu.be/YgNrGT8pzYw

#serverless
#FaaS
#Go
#Golang

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

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

В новом раунде были проведены тесты фреймворков из предыдущих раундов, а также появилось несколько новых очень классных фреймворков на Rust (Hyper, Actix, улучшены тесты Tokio) и Kotlin (ktor, hexagon, http4k, pronghorn), которые заняли топовые позиции по результатам тестов, при этом показатели результатов тестов производительности уже присутствовавших ранее фреймворков на данных языках (взгляните на фреймворк Tokio.rs) с каждым раундом и релизом фреймворка только растут, это показывает, что кодовая база и архитектура фреймворков уже стабилизировалась и теперь происходит её постепенная оптимизация и улучшение.
Безусловно, довольно молодые экосистемы языков Rust, Go и Kotlin растут, библиотеки и фреймворки на этих языках улучшаются и появляются новые.

https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext&a=2

https://www.techempower.com/blog/2018/02/14/framework-benchmarks-round-15/

За непрерывным обновлением данных по прохождению тестов между раундами можно следить на данной странице:
https://tfb-status.techempower.com

Предыдущие посты по теме:
https://xn--r1a.website/technologique/970
https://xn--r1a.website/technologique/609
https://xn--r1a.website/technologique/59

Релиз Go 1.10

https://blog.golang.org/go1.10

https://golang.org/doc/go1.10

#Go #Golang

Связанные посты:
https://xn--r1a.website/technologique/1170
https://xn--r1a.website/technologique/1172

https://xn--r1a.website/technologique/1057
https://xn--r1a.website/technologique/750
https://xn--r1a.website/technologique/551

Оливер Гоулд, CTO компании Buoyant, в интервью-подкасте от InfoQ, о проектах Conduit и LinkerD, организации сервисных шин для управления роем сверхлёгких (микро/нано) сервисов в контейнерных окружениях в IoT и Cloud Native инфраструктурах.

https://soundcloud.com/infoq-channel/oliver-gould-omicroservices-service-meshes-linkerd

https://www.infoq.com/podcasts/Oliver-Gould-microservices-linkerd-service-mesh

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

Kategory for Kotlin

Очень впечатляющий спич о фреймворке Kategory для Kotlin.

Extension functions и extension interfaces (KEEP-87) для поддержки type classes - будут введены в Kotlin для всех экосистем языка и в этом есть большая уверенность, потому что это кардинально изменит расклад сил в JVM экосистеме.
Что самое интересное - Kotlin хорошо совместим с Java и байт-кодом JVM и таким образом при введении в язык классов типов он вносит базовый элемент для создания настоящего продвинутого функционального программирования на JVM при полной совместимости с ней и всей экосистемой библиотек и фреймворков. Расширения Scala, scalaz и cats, а также диалекты Haskell для JVM, Eta и Frege, не позволяют достичь совместимости, т.к. используют нестандартные трюки с байт-кодом для реализации классов типов, монад и категорий.

https://www.youtube.com/watch?v=s9oMED6ZikQ&t=16m12s

#Kotlin

Про архитектурные паттерны с применением функционального программирования для проектирования приложений.

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

Nightly build удался! 525 модулей - легко! #NodeJS'сть!

#humorous_tech

Тенденции индустрии

Stack Overflow вновь опубликовали результаты исследования тенденций в индустрии на 2018 год по данным опроса разработчиков из различных экосистем и стэков технологий.

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

https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages

Данная тенденция отражает желание и готовность применять технологию на практике самими разработчиками, но не отражает текущую востребованность технологии в индустрии.

Другие тренды вы можете также посмотреть в данном исследовании - в нём очень много интересной информации!

#Rust #Kotlin

Опубликован roadmap для языка Rust и его экосистемы на этот год.

https://blog.rust-lang.org/2018/03/12/roadmap.html

Language improvements:

Ownership system improvements, including making borrowing more flexible via “non-lexical lifetimes”, improved pattern matching integration, and more.

Trait system improvements, including the long-awaited impl Trait syntax for dealing with types abstractly.

Module system improvements, focused on increasing clarity and reducing complexity.

Generators/async/await: work is rapidly progressing on first-class async programming support.

Долгожданные возможности, которые будут реализованы в этом году - статическая перегрузка имлементаций трейтов impl Trait (статическая диспетчеризация при возврате реализаций абстрактных типов описанных в трейтах, без необходимости их boxing'a и unboxing'a с выделением памяти в куче, что медленнее и дороже), которая ускорит исполнение кода и повысит производительность асинхронных библиотек (например Tokio), а также возможности асинхронного программирования на уровне языка, first-class async programming support, пожалуй самая долгожданная возможность, т.к. позволяет программировать многопоточный код (легковесные потоки, диспетчеры потоков и M:N thread-mapping на системные потоки) на базе сопрограмм и использовать асинхронный неблокирующий ввод-вывод на базе сопрограмм без применения сторонних библиотек.

#Rust

Метафизика программирования.

Многие годы идёт дискуссия о том, что есть программирование - искусство или только ремесло?
Для меня в первую очередь это инженерная дисциплина и профессия, для многих это ремесло (разработка софта).
Но эстетическое ощущение процесса творения не сравнимо ни с чем другим - поэтому программирование это искусство во многом. При этом нужно признать, что не у каждого творца (программиста) есть чувство прекрасного и не у всех оно развито в равной степени одинаково (после проведения code review это ощущается особенно остро - были даже рассуждения в духе https://www.youtube.com/watch?v=-a7unnF48t0&t=5m38s =) - поэтому чтобы быть лучшим программистом и совершенствовать свои навыки не так важно знать все технологии, методологии, концепции и паттерны, нужно совершенствовать своё сознание, работать над своим эстетическим ощущением окружающей дествительности и чувством прекрасного! Но при этом не нужно очень сильно погружаться в искусство программирования, ибо это страсть, а страстями сложно управлять (хаскелисты поймут о чём я говорю - всегда можно сделать код совершеннее, если есть множество очевижных и неочевижных, даже если вы голландец, способов сделать одно и то же решение правильно работающим, i.e. remind about syntactical diabet vs. syntactical sugar).

Я хочу сказать вам о том, что всем нам требуется работать над собой, развивать своё тонкое восприятие красоты. Многие находят отдушину в разнообразных хобби. Ваш покорный слуга и автор канала любит хорошее кино (желательно со сценарием по книгам), литературу в жанре киберпанк, электронную музыку (Trance) и читает блог Classic Programming Paintings 😉 (http://classicprogrammerpaintings.com/post/142321815809/hieronymus-bosch-a-visual-guide-to-the-scala).

В нашем канале вы можете найти не только посты о технологиях, но и о влиянии техногогий на форматирование техно-ноосферы человечества, о технологиях в дизайне, искусствте, литературе в жанре киберпанк, кино и даже о "тщете всего сущего"!

Связанные посты:
https://xn--r1a.website/technologique/1039
https://xn--r1a.website/technologique/1175
https://xn--r1a.website/technologique/1180
https://xn--r1a.website/technologique/1181
https://xn--r1a.website/technologique/1182

The day when the Telegram stood still.

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

https://outage.report/telegram#2018-03-29

https://twitter.com/telegram/status/979274718401515521

https://twitter.com/durov/status/979284965178400769

https://twitter.com/durov/status/979303818126135299

https://xn--r1a.website/durov/75

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

Необходимо снижать зависимость инфраструктуры (компании, организации) от внешних сервисов и всегда иметь резервные сервисы и каналы связи на базе собственной self-hosted инфраструктуры - есть решения на базе self-hosted облачных сервисов, например плагины Spreed, реализующие полноценный обмен сообщениями, файлами и аудио-видео связсь (на базе WebRTC) и работающие на базе self-hosted облачной инфраструктуры NextCloud (альтернатива и форк OwnCloud):
https://apps.nextcloud.com/apps/spreed
https://github.com/nextcloud/spreed

https://apps.nextcloud.com/apps/spreedme
https://github.com/strukturag/nextcloud-spreedme/blob/master/README.md

У меня в свою очередь возникает другой вопрос - где же децентрализация сервер-сайд бэк-энд инфраструктуры Телеграм, обеспечиваемая также и его протоколом MTProto 2.0? Где отказоустойчивость и высокая доуступность?

https://twitter.com/andrcmdr/status/979324546334552064

#telegram

Истоки многопоточности в Rust.

Как и многие другие разработчики в экосистеме Rust я хотел бы видеть в Rust сопрограммы и продолжения на уровне языка и его ключевых слов (first-class coroutines and first-class continuations) с сохранением состояний (scopes, namespaces, lifetimes) на базе замыканий (closures), что более естественно в мире функционального программирования.

http://mttyng.com/closures-101/

Но то, что делается сейчас для реализации async/await макросов с их последующим внедрением на уровне языка в виде ключевых слов (или трейтов в stdlib) - реализуется на базе линейного "выпрямления" вложенных (call-back'ов) и рекурсивных вызовов функций посредством использования futures/promises и оптимизации хвостовой рекурсии с превращением рекурсивных вызовов в итераторы (итеративные вызовы), последовательные вызовы функций.

https://boats.gitlab.io/blog/post/2018-03-20-async-vi/

Базовая абстракция во многих языках для реализации сопрограмм и положений (call with current continuation - call/cc) - это замыкания (closures), которые пришли во многие языки из языка Lisp, но впервые были изобретены для цепочки вызовов ассемблерных подпрограмм.

Замыкание хранит состояние вызова функции (её локальную область видимости со всеми переменными и передаными в неё ссыклами на другие функции в качестве параметров или возвратами этих функций, call-back'ов) как её стэк вызова и восстанавливает его при повторном вызове функции - это используется для создания сопрограмм, продолжений и программирования в continuation passing style, для программирования многопоточного кода.
Поэтому в отличии от функций, которые всегда stateless, сопрограммы хранят промежуточные состояния вычислений, поэтому они stateful, как и акторы.
Это используется в CSP многопоточности.

Кстати, основное отличие CSP на базе сопрограмм от акторов на базе тех же сопрограмм главным образом не в том, что для сопрограмм сообщения передаются синхронно, а для акторов асинхронно, а в том, что в CSP каналы это отдельная абстракция, которая способна передавать сообщения через канал только синхронно, что делает асинхронный код более "линейным" и последовательным при его программировании, но работает такой код при этом асинхронно (наприер с вводом-выводом).
В свою очередь в акторах тоже есть отдельная абстракция для сообщений с виде mailbox'ов, которая способна принимать сообщения асинхронно и представлять их в виде последовательности сообщений (message queue).

Сопрограммы на базе замыканий реализованы в Kotlin, Go, JavaScript, TypeScript, Python, Lua и ещё многих языках.
Но не в Rust, т.к. в Rust есть проблема lifetimes of scopes/namespaces (времени жизни областей видимости переменных) - деструкторы (RAII), чтобы не было утечек памяти, сразу освобождают память при выходе потока исполнения кода из области видимости функции (impl's scope) и срабатывания умного указателя на финализатор и деструктор, поэтому любая область видимости всегда stateless и не хранит состояние достаточно долго (по причине финализации и вызова деструкторов для объектов хранящихся в куче, подобная концепция применена также в generational garbage collecting, автоматической сборке мусора в памяти на базе длительности времени жизни групп стэков вызовов сопрограмм, хранимых в памяти кучи как цепочки стэков вызовов подпрограмм на базе cactus-stack/parent-pointer tree), в результате чего корректно реализовать stateful сопрограммы (продолжения/continuations и continuation-passing style код) на базе замыканий в Rust очень сложно, поэтому чаще для реализации многопоточных сетевых приложений с асинхронным вводом-выводом используется модель акторов и future/promise трейты (как например в фреймворке Tokio) для реализации асинхронных вызовов в event-loop цикле.

Таковы ограничения концепций и особенности реализации управления памятью в Rust.

#Rust

Ссылки по теме:
https://xn--r1a.website/technologique/1273
https://xn--r1a.website/technologique/1263
https://xn--r1a.website/technologique/1209
https://xn--r1a.website/technologique/1207
https://xn--r1a.website/technologique/1200

Анонс релиза второй версии языка Dart.

Буквально месяц назад состоялся официальный анонс второй версии языка Dart.

На данный момент Dart позволяет программировать код для всех платформ - server-side back-end сервисы исполняемые JIT компилятором DartVM, клиентские мобильные приложения для Android и iOS благодаря Flutter (DartVM с поддержкой SDK мобильных платформ) и клиентские веб-приложения благодаря транс-компилятору Dart2JS.
Это в свою очередь позволяет иметь максимально обобщённую кодовую базу проекта, с отдельными слоями сопряжения со средой для взаимодействия с платформой, и использовать таким образом максимально общую логику в приложениях для разных платформ.

https://medium.com/dartlang/announcing-dart-2-80ba01f43b6

https://news.dartlang.org/2018/02/announcing-dart-2-optimized-for-client.html

https://www.dartlang.org/dart-2

Во второй версии языка Dart и его среды исполнения кода DartVM будет использоваться новая система типов (в меньшей степени gradual typing, в большей flow-sensitive typing), со структурным статическим выводом типов на этапе компиляции (sounding type system) и минимальным динамизмом определения типов времени исполнения, в run-time (только для обобщенных generic типов).
Это в свою очередь повысит скорость исполнения кода в run-time, которая в версии Dart 1.x была сравнима с Node.js/V8 (около 10x раз медленнее кода на Си, по результатам синтетических тестов производительности - http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html).

#Dart

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

Первого мая этого года будет закрыт хостинг проектов https://alioth.debian.org

Вместе с хостингом будет закрыт один очень хороший проект, Benchmarks Game, с тестами производительности и эффективности программ на разных языках программирования.

Проект http://benchmarksgame.alioth.debian.org существовал с 2004 года (http://web.archive.org/web/20040611035744/http://shootout.alioth.debian.org) и до 2012 года работал на домене http://shootout.alioth.debian.org (http://web.archive.org/web/20121231010227/http://benchmarksgame.alioth.debian.org).

Сайт вместе со всем контентом и кодом тестов на различных языках программирования можно скачать в виде архива:
http://benchmarksgame.alioth.debian.org/download/benchmarksgame-html.zip

Надеюсь проект продолжится уже на GitHub!

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

http://doyoutrustthiscomputer.org/watch

#antitrust

Бэкэнд компилятора Rust 1.25 переведён на инфраструктуру компиляции LLVM 6.
Также улучшены синтаксис импортов и паттерн матчинг выражений - теперь импорты могут быть вложенными, а паттерн матчинг блоки имеют синтаксис как в OCaml.
Подробнее в заметках к релизу:
https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1250-2018-03-29

#Rust

Проект Benchmarks Game продолжит свою жизнь на страницах GitLab:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/

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

Финальный вариант RFC по внедрению поддержки async/await синтаксиса на уровне языка (first-class asynchronous support) в #Rust.

https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/

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