На пути к 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.

Jolla выпустили обновление Sailfish OS 2.1.1

Обновление образов прошивок будет доступно для устройств Jolla и Sony Xperia.

https://blog.jolla.com/sailfish-os-2-1-1-now-available-jolla-devices-early-access/

https://blog.jolla.com/sony-xperia-project-update/

Девайсов с Sailfish на борту по прежнему очень мало - это устройства Jolla собственной разработки компании и с недавних пор отдельные устройства Sony Xperia, прошивки для которых разрабатываются по договору о сотрудничестве Jolla с Sony.
Поддержка устройств не очень широкая и вряд ли будет таковой. Причины этого обективны и понятны - рынок уже занят и поделён.
Все основные производители мобильных устройств и SoC чипов завязаны на Open Handset Alliance, который недостаточно open, чтобы быть открытым для сторонних производителей железа и софта, и альянс сильно завязан на Google и экосистеме Android, которые обязывают компании альянса, для участия в нём и экосистеме Android, закрывать спецификации своих SoC и запрещают открывать исходники драйверов для сторонних производителей софта.

https://www.openhandsetalliance.com/oha_members.html#handset

https://www.openhandsetalliance.com/oha_members.html#semiconductor

https://www.openhandsetalliance.com/oha_members.html#software

Это захват и сегментация рынка, и защита своих лидирующих позиций на нём для Google, как производителя софта и защита доходов от производства устройств и их компонентов для производителей железа, т.е. это фактически закрытый рынок и закрытый конгломерат компаний его формирующих, который не приемлет новых производителей софта и ОС.
Даже китайские производители железа не смогли изменить ситуацию на рынке и снизить зависимость от Google.

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

Canonical искали точки входа на рынок, сначала пытались распространять устройства с помощью европейских (например Bq) и азиатских мобильных операторов, участвовали со своим проектом мобильного дистрибутива Ubuntu в Mobile World Congress в Барселоне на протяжении нескольких лет для его популяризации среди производителей устройств, европейских и азиатских операторов , после пытались сотрудничать с азиатскими производителями железа (например Meizu) - но ничего не вышло.

Думаю та же участь ждёт проект Jolla Sailfish, даже не смотря на сотрудничество с Sony.
Такая ситуация на рынке делает любой проект альтернативной ОС невостребованным и слабо окупаемым.
Производитель железа должен иметь уверенность в прибыли, сколько он устройств сможет и должен произвести и отгрузить, сколько из них будут востребованы, согласно исследованиям рынка и ситуации на нём, чтобы окупить их разработку и производство и ещё заработать прибыль - Google с Android и альянс дают гарантии этого, а сторонние производители софта не дают никаких гарантий.
С другой стороны производитель софта должен создавать удобный инструментарий для разработки приложений и формирования экосистемы вокруг ОС - успех ОС во многом зависит от её SDK, доступности языковых и инструментальных средств для разработки приложений под неё.

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

Хотя сам я за Jolla очень болею, но уже ни на что не надеюсь, потому что на успех Ubuntu у меня лично была очень большая надежда и большие ожидания свершений, и сейчас я просто использую те устройства что более доступны.

На таком рынке сможет остаться только полностью самостоятельный производитель софта и железа ("full-stack vendor"), как например Apple, чтобы составить конкуренцию и зарабатывать на нём деньги.

Даже в самой экосистеме Android такая ситуация на рынке и в альянсе порождает негативные тенденции - замкнутость экосистемы, элиминация/исключение не только иных производителей софта, но и железа (пример - слабый успех YotaPhone 2, что послужило причиной замораживания всего проекта, слабый успех Intel на мобильном рынке, не смотря на влияние корпорации и технологически очень хорошо проработанные последние поколения мобильных чипов), из-за чего устройства всё больше становяться до ужаса однообразными, как по своей железной начинке, дизайну, форм-фактору, так и по пользовательским интерфейсам приложений и системы, из-за влияния одного главного производителя софта, Google, со своим мнением о том "как нужно делать интерфейсы правильно".
Тем не менее такая унификация железа, ОС, SDK и интерфейсов не делает разработку приложений, прошивок и их поддержку более простой - до сих пор в экосистеме Android присутствует значительная фрагментация самой ОС в плане существующего железа и его поддержки, возникшая во многом из-за закрытости драйверов для SoC (производители SoC чипов в альянсе делятся спецификациями и исходниками драйверов только с производителями конечных устройств) и из-за модели выпуска и поддержки обновлений прошивок целиком под конкретные устройства самими производителями конечных устройств. Таким образом фрагментация ОС возникла из-за vendor centric модели выпуска и распространения самой системы, сконцентрированной вокруг производителей конечных утсройств, которые решают сделать ли прошивку, её обновления, ядро и драйверы доступными или нет, что делает процесс поддержки прошивок устройств самими производителями (без привлечения сообщества) очень сложным и также негативно влияет на процесс разработки приложений разработчиками под различные устройства, т.к. нужно поддерживать как можно больше различных стройств и сделать универсальную поставку приложения работающего на всех устройствах становится всё сложнее, даже не смотря на наличие единого SDK.

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

Выпустив Windows для персональных компьютеров в своё время Microsoft поступили очень грамотно (что было весьма очевидно для того времени), разработав единый универсальный API ядра и системных библиотек (WinAPI), и заставив производителей самого железа, а также производителей компьютеров "в сборе" и лэптопов, распространять как минимум бинарные драйверы железа и устройств для их поддержки и работы в ОС Windows.

Links:
https://xn--r1a.website/technologique/777
https://xn--r1a.website/technologique/933
https://xn--r1a.website/technologique/936
https://xn--r1a.website/technologique/938

Первый тизер третьего сезона сериала "Мистер Робот".

С каждым сезоном сериал "Мистер Робот" всё больше отражает тенденции в американском и глобальном обществе и политике, а также показывает влияние технологий на информационное общество - побочные эффекты применения и использования цифровых технологий, тотальная слежка за гражданами, ограничение свободы доступа к информации, всё большее влияние глобальных корпораций и финансовых конгломератов на жизни и судьбы людей, распространение криптовалют и darknet.
Во втором сезоне было сделано весьма смелое предположение, что после краха традифионной финансовой системы фиатных денег международные финансовые конгломераты могут перейти на криптовалюты, основанные на блокчейн алгоритмах. И это вполне подтверждается текущими экспериментами крупных международных банков (например UBS) с блокчейн алгоритмами.
Я конечно не сторонник теорий заговоров, но мне думается, что появление Bitcoin в текущую post-2K эру было далеко не случайным и весьма своевременным, учитывая также факт сокрытия его авторства. 😉

Сложно представить до чего дойдёт фантазия (фантазия ли? скорее предупреждение и предостережение) Сэма Эсмейла в новом, третьем, сезоне, премьера которого состоится 11 октября этого года.

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

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