Наконец-то вчера JetBrains дали доступ к IDE Gogland EAP (Early Access Program) - разослали перед праздниками всем зарегистрировавшимся в EAP мэйлы со ссылками.

https://twitter.com/GoglandIDE/status/812323814088572928

http://download-cf.jetbrains.com/go/gogland-163.10615.6.tar.gz

Документация:
https://www.jetbrains.com/help/go/1.0/getting-started-with-gogland.html

Баг-трекер:
https://youtrack.jetbrains.com/issues/GO

https://www.jetbrains.com/go/

Весёлого Рождества и Счастливого Нового Года друзья! 🎄☃🍊🍾🎊🎉

А тем временем биткойн уже вновь по $900 торгуется на биржах
Взрывной рост буквально в течение недели

Локальная новость

НурТелеком запустил своё IP телевидение O!TV и линейку тарифов для него - https://otv.kg

http://o.kg/ru/o_kompanii/novosti/607

Есть мобильное приложение для просмотра ТВ каналов - https://play.google.com/store/apps/details?id=kg.o.tv

Также есть свой VoD видео портал - http://video.o.kg

Делал ГИС приложение для картографирования покрытия сетей связи.
Испытывал на местных сетях.
Уровень сигнала сети в dBm, её идентификацию и другие данные о сети брал через api системной библиотеки (NDK) и драйвера для всеядного радиомодуля смартфона Asus Zenfone 2 на Android.
Обрабатывал данные в приложении и логи с данными в json сливал приложением в серверсайдный бэкэнд, обрабатывающий геоданные для слоя карты в OSM.

Для разделения сетей и их покрытия нужны были более актуальные данные по кодам MCC/MNC чем содержат документы ITU.

https://github.com/musalbas/mcc-mnc-table/blob/master/mcc-mnc-table.csv#L805

Например:
(43709, MCC=437, KG, MNC=09, O!/NurTelecom)

Есть интересная информация по MCC/MNC кодам сетей - жаль что данные уже устаревшие и неполные, более актуальных данных в сети не нашёл.

http://mcc-mnc.com

http://mcclist.com/mobile-network-codes-country-codes.asp#K

После чуть более долгих поисков нашёл нормативные акты министерства связи.
Теперь всё стало более понятно!

http://nas.gov.kg/index.php?option=com_content&view=article&id=315:prikazovideleniikodovbesprovodnogoshpd73-np2011-07-01doc&catid=52:deyatelnost-standarty-i-tex-regulirovanie&Itemid=461&lang=ru

http://nas.gov.kg/index.php?option=com_content&view=article&id=295:kodyvydeloperatoramkrdoc&catid=52:deyatelnost-standarty-i-tex-regulirovanie&Itemid=441&lang=ru

Сети LTE без символьной идентификации - это Сайма (437-10) и... МегаЛайн (437-11).

http://megaline.kg/4g/4g-ob-usluge/

http://megaline.kg/zona-pokryitiya/

Мы тут с другом @lucky_rider'ом дискутировали про Go...
Он считает, что сейчас, прямо сейчас, нет смысла переходить на Go полностью в проектах на Python.
Это конечно субъективно и спорно, и зависит от проекта, объёма уже созданной кодовой базы на Python, нагрузок, которые испытывает серверсайдный бэкэнд, его ресурсоёмкости по железу и масштабируемости.

Например Dropbox и Uber уже переписали критические по производительности части server-side back-end'а на Go.

Но в целом я считаю если писать с нуля распределённое многопоточное высокопроизводительное сетевое приложение, расчитанное под высокие нагрузки по RPS (requests-per-second) и по количеству соединений, где понадобится обрабатывать каждое соединение в отдельном потоке, то лучше сразу начинать писать проект на Go.

Тем более сейчас есть уже очень много классных фреймворков для создания сетевых и веб приложений на Go, некоторые более оптимизированные и быстрые чем даже net/http модуль из стандартной библиотеки - FastHTTP, Iris, Echo, Beego, Gin...

По личным впечатлениям:

https://github.com/valyala/fasthttp - наиболее быстрый HTTP сервер, поддержка HTTP2 в планах

Подкаст с автором FastHTTP - http://golangshow.com/episode/2015/12-03-032/

В модуле net/http протокол http2 поддерживается с версии Go 1.6 - https://http2.golang.org

Роутеры для fasthttp:
https://github.com/buaazp/fasthttprouter

https://github.com/qiangxue/fasthttp-routing

Реализация протокола websocket на Go для fasthttp:
https://github.com/leavengood/websocket

https://github.com/kataras/iris - очень функциональный, оптимизированный и очень быстрый, построен на fasthttp, my personal favourite 👍

https://github.com/labstack/echo - очень быстрый микрофреймворк

https://github.com/hoisie/web - очень простой

https://github.com/astaxie/beego/ - мощный и очень функциональный, практически всё из коробки 👍

https://github.com/gin-gonic/gin - джин лучше мартини! 😂👍

https://github.com/revel/revel - тоже прикольный 😉

В целом все фреймворки весьма производительны!

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

Что касается Python...

У Python область применения намного более узкая из-за динамической типизации и интерпретации, которая фактически является единственным вариантом среды исполнения промежуточного байт-кода эталонного CPython, в инструкции которого заключены инвокации/вызовы кода динамической диспетчеризации типов и методов, которые могут быть вызваны только в рантайме, во время исполнения, интерпретации байт-кода, и замедляют как скорость исполенения так и сборку мусора на больших кучах.

Python и Ruby более сложные скриптовые языки с объектными типами, во многом из-за реализации абстрактных типов данных через парадигму ООП с применением динамического определения типов во время исполнения кода, поэтому они пленники, заложники своей скриптовой динамической идеологии, заложенной в их основу с самом начале.

Реализация JIT компиляции байт кода для таких языков задача архисложная.

JIT и AoT проще сделать для языков с более простой реализацией абстрактных типов данных (прототипы в Lua и JS, интерфейсы, но не для ООП, ОП или ФП)
при этом эти типы всё равно будут определяться динамически в runtime (динамическая типизация), во время исполнения байт-кода, для чего в байт код внедряются специальные инструкции динамической диспетчеризации типов в методах/функциях, их параметрах, в выражениях, переменных.
А проверка типов замедляет время исполнения (run-time), т.к. это тоже код выполняющий дополнительные проверки типов - динамизм типов отъедает машинное время.

Поэтому даже Node.js и LuaJIT более медленны чем статически компилируемые языки без динамизма в определении типов.

Node.js/V8, LuaJIT самые быстрые скриптовые языки по скорости исполнения кода благодаря более простой по концепции реализации абстрактных динамических типов данных, что дало возможность реализовать динамическую JIT компиляцию для этих скриптовых языков и таким образом ускорить их среду исполнения.

Поекты JIT компиляторов JRuby, Rubinius, PyPy, Pyston имеют более ограниченную реализацию эталонного интерпретируемого языка, с меньшим динамизмом в типах в угоду скорости исполнения и компиляции, но всё же они медленнее прототипных языков JavaScript и Lua и их реализаций Node.js/V8 и LuaJIT, ввиду своей сложности в реализации абстрактных объектных типов данных и их динамичного определения/диспетчеризации.

То же самое можно сказать применимо к Hack, HipHop PHP, KPHP, PHP7, Perl6/Parrot.

Во многом из-за этого Python и Ruby за много лет своего существования и разработки не вышли за пределы своих ниш и доменов применения.
И поэтому могут применяться только в средненагруженных сервер-сайд бэкэндах
или использоваться как удобные оболочки для абстракции и создания DSL языков, научных расчетов, статистических расчётов, анализа данных, создания утилит, возможно с GUI интерфейсом.

Да, критические участки могут быть написаны на более низкоуровневом языке и использованы в коде Python через FFI ABI ctypes, но это не решает проблему общей производительности в корне.

В мобильном и IoT секторе на маломощных устройствах, с небольшим объёмом памяти ОЗУ и упором на энергосбережение Python и Ruby также не стали популярны, из-за своей интерпретируемой природы и соответственно большей ресурсоёмкости.

JS и Lua наоборот нашли самое широкое применение, ввиду более простой прототипной природы объектов, лёгкости создания и использования объектных моделей к низкоуровневым API (типа DOM в браузере и других объектных моделей в Node.js, Electron, PhoneGap/Cordova), лёгкости реализации DSL для специфичных доменов применения языка, благодаря чему появилась куча языков транслируемых в JS транс-компиляторами (TypeScript, CoffeeScript, ES6/Babel, LiveScript, Scala.js, Kotlin.js, ASM.js, etc.), а Lua стала применяться как высокоуровневый экономичный по ресурсоёмкости быстрый скриптовый язык для автоматизации работы с низкоуровневыми API, имея очень хорошо ABI совместимый FFI интерфейс к Си подпрограммам и библиотекам, используемый например для прошивок embedded devices и IoT и как скриптовый язык для веб-сервера nginx и не только для него.

...

JS и Lua также как и Python и Ruby удобны для RAD разработки, быстрого прототипирования приложений.

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

Да, есть архитектурные паттерны построения высоконагруженных приложений - суть этих практик сводится к большей модульности и структурированности проектов, большей самостоятельности и независимости каждого модуля/воркера/хэндлера, для создания распределённых систем в угоду масштабируемости нагрузки.

Но...

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

В этом заключается успех Java и JVM в крупном бизнесе и в мобильном секторе (Android, а ранее J2ME).

В post-2k эру стали наконец-то появляться сильные конкуренты по отношению к очень подуставшей классике, языки с более современными концепциями и более ортогональным синтаксисом - Go, Rust, Nim, Dart, Swift, Scala, Kotlin, Haskell, Elixir

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

Будучи в Китае, в Шеньчжене и Гонконге, понимаешь, почему в Юго-Восточной Азии так популярен Golang.

Технологический масс-маркет и нагрузки на системы будут только расти.

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

Есть большой пласт систем, критичных к скорости исполнения, time critical, real time и mission critical систем.
Мы их обычно даже не замечаем в повседневной жизни, погрузившись в интернет. 😆
До тех пор пока что-нибудь начинает идти не так.
И я уже не говорю про управление ракетами, самолётами, спутниками, бортовые системы, оборонные и военные системы, в которых время реакции и надёжность критически важны.
Я задумался про гражданские системы.
И это не только обеспечение связью, банковские, экономические системы, трейдинговые платформы, транспортные, энергетические системы, где так же критически важны время реакции и надёжность.
Сейчас появляется всё больше отраслей в IT - driverless cars, дроны, коптеры, персональный наземный и воздушный транспорт, автопилоты, IoT, умная городская среда, умные дома, носимая электроника, даже появился термин "подключенная реальность", "подключенный мир", "всеобщие коммуникации", потому что скоро грядёт 5G с гигабитными скоростями.
Huawei заявляет о первых внедрениях систем связи пятого поколения уже в 2017-2018 году в Китае.
Будет всё больше устройств, подключенных к облачным системам.
Мы всё больше зависим в своей жизнедеятельности от электронных программируемых систем.
И в таком мире будущего нет места задержкам в исполнении и большому времени реакции систем.

Я думаю, что надёжное многопоточное системное и сетевое программирование будут только набирать популярность.

PS: Изучайте Rust друзья! Rust силён!
Чувствую позиции C++ скоро будут сильно потеснены.

https://github.com/redox-os/redox

#Generics in Go

Pass interfaces

Generic functions can easily be written - this require the caller to use variables of the empty interface type. The empty interface can hold a value of any type.

package main
 
import "fmt"
 
func swap(a, b *interface{}) {
    *a, *b = *b, *a
}
 
func main() {
    var a, b interface{} = 3, "four"
    fmt.Println(a, b)
    swap(&a, &b)
    fmt.Println(a, b)
}


Output:

3 four
four 3

В интернетах только и разговоров, что об отсутствии дженериков в Go...
В Go нет дженериков?
Зато есть ещё более шикарный хак!
Обобщённые типы для функций/методов и их параметров могут создаваться через пустые интерфейсы, которые могут содержать значения любого типа.
При этом параметры в обобщённую функцию передаются по ссылке, интерфейсы передаются через указатели и все операции с интерфейсами и параметрами происходят через указатели.
Таким образом вся реализация дженериков сводится к операциям через указатели с переменными, тип которых определён пустыми интерфейсами, т.е. всё сводится к операциям с интерфейсами!

Интерфейсы и модули - это сила структурного программирования!

Исходники Java библиотеки NFC/EMV (https://en.wikipedia.org/wiki/EMV) ридера бесконтактных платёжных карт.

https://github.com/devnied/EMV-NFC-Paycard-Enrollment

Весьма полезная библиотека при создании Android приложений мобильного банкинга, использующих NFC для эмуляции виртуальных карт и оплаты с помощью смартфона с запущенным приложением.
Яркий пример - приложение Яндекс.Деньги.

Счастливого Нового Года друзья! 🎄☃🍊🍾🎊🎉

А тем временем в Кыргызстане и в его столице, городе Бишкек, все празднуют наступление Нового 2017-го года! 😄