Эффективное программирование на #Go с Gogland IDE от JetBrains

https://youtu.be/o3igXAE9eDo

https://t.me/technologique/651
https://t.me/technologique/663

Очень классный консольный редактор, реализованный на #Go

https://micro-editor.github.io
https://github.com/zyedidia/micro
https://github.com/zyedidia/micro/releases

ctop - очень юзабельная утилита для мониторинга контейнеров #Docker, написанная на #Go

http://ctop.sh
https://github.com/bcicen/ctop
https://github.com/bcicen/ctop/releases

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

Видео с недавней конференции GopherCon 2017 с докладом Расса Кокса о будущем Go и грядущем релизе Go 2.0.

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

Данный доклад лёг в основу статьи Расса "На пути к Go 2.0" ("Toward Go 2.0"), которую мы публиковали в канале ранее — https://t.me/technologique/1008.


#Go
#GoLang

https://habrahabr.ru/post/271789/

В своей первой презентации от 2010 года по первому публичному релизу Rust (http://venge.net/graydon/talks/intro-talk-2.pdf) Грейдон Хоар очень верно отметил:

Go has coroutines, but kept shared mutable state - thread safety и безопасность общей памяти потоков нарушаются.
Есть нулевые указатели и они никак не проверяются - в Kotlin например есть проверка nullable types, т.е. обнуляемых типов благодаря flow-sensitive type system.
Нет деструкторной техники освобождения ресурсов (RAII).
Есть GC, но нет динамики вывода типов во время исполнения (в run-time) и дженериков (обобщённых типов).
Сообщения хоть и передаются синхронно через каналы, но мутабельны.

https://habrahabr.ru/post/338718/

В этом и вся проблема в Go - авторы сделали горутины по образу CSP Чарльза Энтони Хоара, чтобы исключить доступ к общей памяти потоков (shared mutable memory), её повреждение при одновременной записи (shared mutable state), состояние гонки или взаимоблокировки потоков за счёт синхронных сообщений, передаваемых через каналы, а теперь выходит что нужно пользоваться мьютексами для предотвращения повреждения данных в общей памяти потоков при одновременной записи (shared mutable state), потому что параллельные коллекции не предусмотрели.

Rust имеет более широкий спектр применения и скомпилированный им код более безопасен при работе с памятью и вводом-выводом, чем Go - Go более узкоспециализированный язык программирования.
Всё что можно сделать на Go можно сделать и на Rust, но ещё более эффективно, например писать веб-приложения с помощью фреймворка Rocket или веб-серверы на Hyper+Finchers или Tokio.
Но не наоборот - Go не системный язык и например на нём невозможно разрабатывать драйверы или модули ядра, или даже само ядро, когда Rust и это позволяет (проект Redox OS).
При том, что Rust, так же как и Go, и Python, не ограничивает программиста в производительности и скорости написания программ.

#Rust vs. #Go
#Golang

Go Garbage Collector — concurrent tri-color incremental mark & sweep algorithm.

Доклад Рика Хадсона на конференции GopherCon 2015 о том, как в Go 1.5 удалось радикально уменьшить STW (Stop-The-World) задержки исполнения потоков программы (до наносекундных/субмиллисекундных показателей в последующих версиях, вплоть до крайних Go 1.8 и 1.9) благодаря применению гибридных алгоритмов многопоточной сборки мусора (GC) для программ написанных на языке Go.

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

https://blog.golang.org/go15gc

Слайды:
https://talks.golang.org/2015/go-gc.pdf

Roadmap - на пути к версии 1.5:
http://golang.org/s/go14gc (https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit)

Метрики:
https://github.com/bmhatfield/go-runtime-metrics

https://twitter.com/brianhatfield/status/900473287750365184

Статья с оценкой производительности и метрик сервиса Twitch в их блоге:
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7

В версии языка и компилятора Go 1.5 был кардинально переработан код сборщика мусора (GC), до этой версии он был полностью переписан на самом Go методами автоматного (транс-компиляция с языка Си), а после и ручного программирования (коррекция) и были внедрены новые (вернее старые, но давно забытые) улучшения в алгоритмы многопоточной сборки мусора, благодаря чему данный GC стал лучшей программой в своём классе (субмиллисекундные задержки при освобождении памяти даже для оперативных in-memory хранилищ данных с размером кучи в 256 ГиБ (heap-size) для каждой ноды кластера!).

Эта разработка стала исторической вехой не только для языка Go, укрепившей его позиции в серверной разработке облачных инфраструктур, сетевых сервисов и демонов сетевых протоколов (server-side cloud infrastructure software development), но и большим прецедентом для доказательства работоспособности концепций (proof-of-concept) алгоритмов сборки мусора, разработанных ещё в 1970-х годах (tri-color, quad-color, incremental, mark & sweep algorithms).

Алгоритм сборки мусора, применённый в GC для программ на Go - это многопоточный трёхцветный (по фазам пометки указателей с последующим перемещением и освобождением блоков памяти) алгоритм коллектора (concurrent tri-color incremental mark & sweep collector), концепция которого была разработана известным датским математиком и инженером Эдсгером Дейкстра в 1978 году.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD520.html

Но run-time (фаза исполнения) программ на Go был не первым проектом где был применён подобный алгоритм для коллектора памяти (GC).
Ранее Майк Пэлл (Mike Pall), автор знаменитого оптимизированного JIT копилятора Lua, применил подобный алгоритм в LuaJIT версий 1.x/2.0 для run-time фазы исполнения программ на языке Lua.
В LuaJIT будущей версии 3.0 автор планирует реализовать ещё более продвинутый четырёх-цветный оптимизированный алгоритм коллектора (Quad-Color Optimized Incremental Mark & Sweep GC).

http://wiki.luajit.org/New-Garbage-Collector

В run-time фазе исполнения программ оригинальным интерпретатором Lua версий 5.1/5.2 также используется трёхцветный алгоритм коллектора (Tri-Color Incremental Mark & Sweep GC). В более ранней версии Lua 5.0 использовался стандартный двухцветный алгоритм для коллектора памяти (Two-Color Mark & Sweep GC).

Отличная статья в блоге Майка Хёрна (Mike Hearn) о Go GC и вызовах современной компьютерной индустрии при создании гибридных алгоритмов коллекторов памяти:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

Визуализация различных алгоритмов сборки мусора - https://t.me/technologique/958

#Go
#GC
#Lua
#ThrowbackTech

Ссылки:
https://t.me/technologique/721
https://t.me/technologique/722
https://t.me/technologique/750
https://t.me/technologique/1057

https://t.me/technologique/732
https://t.me/technologique/551
https://t.me/technologique/423

https://t.me/technologique/1157

Serverless/FaaS архитектура сервисов и платформа OpenFaaS на базе Docker контейнеризации.

Functions as a service (FaaS) это готовая к работе и самодостаточная (не требующая обслуживания со стороны пользователя/разработчика, serverless) облачная инфраструктура, чаще на базе нижележащих Docker контейнеризации и инструментов оркестрирования контейнеров (Kubernetes, Docker Swarm), предоставляемых как сервис, для упрощения развёртывания и обслуживания наносервисов.

Существует проект открытой платформы OpenFaaS на базе Docker для самостоятельного (self-hosted) развертывания FaaS инфтраструктуры на собственной хостинг площадке (например в дата-центре компании) для обслуживания сервисов.

Плэйлист с недавней конференции DockerCon Europe 2017, прошедшей в Копенгагене, Дании, 17 октября 2017 года - главной темой конферении были FaaS платфома OpenFaaS и serverless инфраструктуры для наносервисов:
https://www.youtube.com/watch?v=C3agSKv2s_w&list=PLlIapFDp305AiwA17mUNtgi5-u23eHm5j

https://www.openfaas.com

https://github.com/openfaas/faas

Автор проекта платформы OpenFaaS - Алекс Эллис.

Демонстрация работы:
https://www.youtube.com/watch?v=sp1B7l5mEzc
https://www.youtube.com/watch?v=BK076ChLKKE

Канал Алекса:
https://www.youtube.com/channel/UCJsK5Zbq0dyFZUBtMTHzxjQ

Также есть несколько коммерческих FaaS платформ - Amazon Lambda, Oracle Fn и Iron Functions:

https://github.com/fnproject/fn
http://www.opennet.ru/opennews/art.shtml?num=47314

https://github.com/iron-io/functions
https://t.me/technologique/608

#FaaS
#Go
#Golang

You can do it, with Conduit!

В компании Buoyant создали новое поколение системы поддержки и управления группами сервисов (service mesh) Conduit для организации сервисных шин и обеспечения реестров сервисов (service discovery), балансировки и распределения нагрузки (load balancing), мониторинга, анализа и предупреждения инцидентов (failure handling), маршрутизации коммуникаций между сервисами (routing for inter-service communication).

Новая, пока экспериментальная (not yet production ready), система управления группами сервисов Conduit написана в большей степени на Rust и в меньшей на Go, ориентирована (в отличии от Linkerd) на управление сверхлёгкими сервисными роями с ограниченными по мощности ресурсами, что хорошо применимо в IoT Cloud Native инфраструктурах.

https://buoyant.io/2017/12/05/introducing-conduit/

Для коммуникаций используется пока только протокол HTTP/2, есть возможность использования фреймворка gRPC для расширения функциональности. В качестве управляемого окружения контейнеров в бэкэнде используется Kubernetes.
При создании Conduit использовались многопоточный фреймворк асинхронного неблокирующего ввода-вывода Tokio (https://github.com/tokio-rs/tokio) и фреймворк Tower (https://github.com/tower-rs/tower) для организации асинхронного IO и многопоточной обработки ввода-вывода посредством функционального Future паттерна (подобного IO Monad в Haskell).

https://conduit.io — https://twitter.com/runconduit

https://github.com/runconduit/conduit

Ранее в компании Buoyant была создана подобная система поддержки межсервисной коммуникации и управления группами сервисов Linkerd, написанная на Scala и использующая JVM стэк (Finagle, Netty).
Linkerd поддерживает различные реестры сервисов (service discovery backends), например Consul, ZooKeeper, Nomad, и управляемые окружения для контейнеров, например Mesos, Kubernetes и Rancher.
Linkerd это production ready система управления группами сервисов, которую используют уже многие компании в своих облачных инфраструктурах, в числе которых такие масштабные проекты как компания Monzo (ранее финансовый стартап), серверная часть которого реализована полностью на Go.

https://buoyant.io — https://twitter.com/BuoyantIO

https://linkerd.io — https://twitter.com/linkerd

https://github.com/linkerd/linkerd — https://hub.docker.com/r/buoyantio/linkerd/


#Rust #Go
#Cloud #CloudNative #IoT
#DevOps #SOA #ESB

Oracle Fn

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

https://youtu.be/YgNrGT8pzYw

#serverless
#FaaS
#Go
#Golang

Ссылки по теме:
https://t.me/technologique/1177
https://t.me/technologique/608

Релиз Go 1.10

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

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

#Go #Golang

Связанные посты:
https://t.me/technologique/1170
https://t.me/technologique/1172

https://t.me/technologique/1057
https://t.me/technologique/750
https://t.me/technologique/551

Go 2 Draft

Роб Пайк о черновике будущего релиза Go 2 и будущих возможностях языка для уменьшения шаблонного (boilerplate) кода - внедрении параметрически полиморфных обобщённых типов (дженериков) на базе механизма контрактов, а также внедрении механизма обработки ошибок на базе function scopes и namespaces модулей с помощью ключевого слова check.

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

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

#Go
#Golang

Go Modules Registry and Mirror

https://blog.golang.org/module-mirror-launch

Разработчики Google запустили в продакшн реестр и зеркало для модулей написанных на языке Go - данные сервисы включают в себя три компонента обеспечения централизованной экосистемы модулей и их версионирования для языка Go и его toolchain'а:

https://proxy.golang.org - зеркало модулей

https://sum.golang.org - хранилище контрольных сумм

https://index.golang.org - реестр

Полный список модулей в JSON формате на данный момент времени - https://index.golang.org/index

О том как использовать модули, их версионирование и вендоринг в проекте и как внедрить использование модулей в уже существующем проекте - об этом пара статей в официальном блоге Golang:

https://blog.golang.org/using-go-modules

https://blog.golang.org/migrating-to-go-modules

#Go
#Golang

#thinkingoutloud #sundaythoughts

#Rust #Kotlin #CPP #Go #Golang

#interview #interviews
#processes #culture
#work #team
#teamwork

😉

Rust goes well - the Discord experience

Here's a cool story of how and why Discord switched from Go to Rust for server-side cloud native back-end development and why Rust for now suits so well to development of multi-threaded applications and for (highly available low-latency) services with asynchronous networking IO:

https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

Links to previous posts on this subject:

https://t.me/technologique/1370

#Rust
#Go #Golang

The good and balanced article by Nick Cameron (Rust Language Server main author and maintainer) about his impressions and differences between Go and Rust (Nick is still in the Rust core team).

https://pingcap.com/blog/early-impressions-of-go-from-a-rust-programmer/

https://github.com/nrc

#Rust
#Go
#Golang

Vision is an action, if there's no vision - there's no action.

Brilliant recent interview with Rob Pike!

https://evrone.com/rob-pike-interview

#Go
#Golang