Наш регулярный листинг рекомендаций IT каналов в Telegram.

@MicrosoftRus - Авторские заметки для ITPro & Dev о Microsoft, Windows Server, System Center, Azure, Office 365, OMS, SQL, облаках и не только.

@mustreat - Mustreadы технологий и значимых событий.

@sea_plus_plus - Материалы и заметки из мира C/C++, Python, Go, Linux и не только.

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

@msdnru - Официальный канал сообщества Microsoft Developer для разработчиков и всех, кто интересуется новыми технологиям.

#channels
#telegram
#advices
#рекомендации

И ещё один небольшой список замечательных и очень интересных каналов о программировании, DevOps практиках и администрировании, о технологиях и немного о сарказме в IT. =)

@SysadminNotes - Заметки практикующего сисадмина о Linux и администрировании серверов.

@theaftertimes - Несерьезный дайджест IT. Ежедневно. Цитаты, паста, картинки.

@w20to - Настоящее и будущее технологий. Future, Science, Tech, Trands, Robotics, AI, IoT, VR, and more.

@dncuug - Канал посвящён вопросам разработки под .NET Core: новые фичи C#, .NET разработка под macOS X и Linux, микросервисы и HighLoad. Вот это вот все и даже больше.

@ITBroadcast - Канал для тех, кто хочет быть в теме и познавать новое в области IT. Входим в Top 1 каналов Telegram о технологиях.

#channels
#telegram
#advices
#рекомендации

GitHub поглощён корпорацией Microsoft

Сегодня была официально подтверждена сделка о поглощении git хостинга open source проектов GitHub компанией Microsoft за $7.5G.

https://blog.github.com/2018-06-04-github-microsoft/

https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

Все мы помним к чему приводят поглощения Microsoft open source компаний - достаточно вспомнить проекты открытых мобильных ОС Maemo и Meego (ныне проект Jolla Sailfish) также поглощённой в своё время компании Nokia.

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

Поэтому с трудом верится в bright future for GitHub and developers - это скорее светлое будущее для создателей и светлая память прекрасному сервису для коллаборации миллионов разработчиков по всему миру.

С другой стороны нельзя не признать что Microsoft меняется на гразах и очень быстро - компания вошла в Linux Foundation, был портирован гипервизор HyperV для ядра Linux, создан слой WSL (Windows Subsystem for Linux, https://github.com/Microsoft/WSL) для изоляции Linux окружений (файловых систем и процессов) на ядре Windows, и их интеграции с Windows окружением, открыт исходный код платформы .Net, компиляторов C# и F#, SQL Server, JS движка Chakra Core браузера Microsoft Edge, активно разрабатываются свободные и открытые проекты .Net/Roslyn и .Net Core, LSP (Language Server Protocol, http://langserver.org), редактор кода Visual Studio Code и инструментарий языка TypeScript.

https://github.com/Microsoft

Возможно (при оптимистичном сценарии) что огромное сообщество open source разработчиков теперь будет играть значимую роль в огромной компании и менять её вектор развития в интересах сообщества.

Тем временем сообщество стало активнее бэкапить проекты на сторонние сервисы хостинга git репозиториев - GitLab и Bitbucket сегодня испытывают всплеск нагрузки по импортированию репозиториев с сервиса GitHub:

https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1&from=1527811200000&to=1528156800000

Самое печальное в этой ситуации то, что очень много зависимостей в проектах на Go до сих пор сильно завязаны на хостинг GitHub, не смотря на наличие сервиса https://gopkg.in для проксирования адресов зависимостей.

All about Node

Откровенный рассказ Райана Дала, автора платформы Node.js, о недочётах в концепциях, положенных в основу дизайна при проектировании платформы Node.js на конференции JSConf.EU 2018

https://youtu.be/M3BM9TB-8yA

Ссылки:
https://xn--r1a.website/technologique/1071

Rust Traits

Прекрасная статья с подробным объяснением различий всех видов трейтов (тайп-классов - &Trait, Box<Trait>, impl Trait, dyn Trait), их обектов (экземпляров) и особенностей реализаций/имплементаций в языке #Rust.

https://joshleeb.com/posts/rust-traits-and-trait-objects/

Framework Benchmarks - Round 16

Шестнадцатый раунд нагрузочного тестирования производительности фреймворков - Framework Benchmarks от TechEmpower.

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

https://www.techempower.com/blog/2018/06/06/framework-benchmarks-round-16/

Тестовые наборы TechEmpower интересны разносторонним подходом к тестированию производительности и выявлением таким образом узких мест фреймворков.

Тестовые наборы находятся в открытом доступе для их open-source community разработки (https://github.com/TechEmpower/FrameworkBenchmarks).

Производительность фреймворков тестируется по различным параметрам и подсистемам, что формирует разные модели нагрузки - сериализация JSON и неформатированные plain-text запросы (для оценки производительности контроллеров и роутеров API запросов согласно идеоме фреймворка), одиночные и множественные (многопоточные) запросы к БД на чтение данных (оценка производительности коннекторов к различным БД и raw подключений к БД), количество операций записи данных в БД (через коннектор либо raw подключение к БД), запрос всех строк и полей таблицы с данными (fortunes) с их последующей шаблонизацией и отсылкой клиенту (комплексная оценка скорости операций чтения данных и производительности шаблонизации данных в формат сериализации для отдачи клиенту или стороннему API).

Dockerificationization!!! [Докерификэйшенизэйшн!!!]

Было обновлено серверное железо (Citrine - triple homogeneous Dell R440), ширина канала связи до серверов увеличена до 10 Гбит/с.

Самое же главное нововведение в данном раунде - контейнеризация тестовых окружений с помощью Docker.
Ранее использовался home-brew sandboxing - 1, 2, 3, 4.
Переход на Docker был произведён для улучшения процесса непрерывного нагрузочного тестирования (continuous benchmarking - https://tfb-status.techempower.com).
Прогон всех тестовых наборов для получения новых показателей занимает сейчас в среднем 67 часов.

Главное, что было проверено под большими нагрузками, что сам движок dockerd, библиотека libvirt и тем более изоляция окружений на базе системных вызовов ядра Linux не дают хоть сколько нибудь ощутимого оверхэда и торможения тестовых наборов в контейнерах - 67 часов прогона всех тестовых наборов без Docker при использовании Docker замедляются всего лишь в пределах минуты. Такой результат находится на уровне погрешности измерений при нескольких прогонах тестовых наборов!

Across the board, our sanity checking of performance metrics has indicated Docker's overhead is immeasurably minute. It's lost in the noise. And in any event, whatever overhead Docker incurs is uniformly applicable as all test implementations are required to be Dockered.

Это весьма сильный аргумент для до сих пор сомневающихся компаний и инженеров в пользу применения Docker в серверной инфраструктуре проектов.

В нагрузочном тестировании stateless контейнеры улучшили сам процесс непрерывного тестирования и воспроизводимость тестовых окружений (reproducibility of builds), что повысило согласованность данных (consistency) при множественных прогонах тестовых наборов в процессе непрерывного тестирования (continuous benchmarking).

Most importantly, thanks to Dockerizing, the reproducibility and consistency of our measurements is considerably better than previous rounds. Combined with our continuous benchmarking, we now see much lower variability between each run of the full suite.

И главное напутствие данного раунда тестов - медленные платформы и их приверженцы, разработчики, пытаясь преодолеть платформенные ограничения, плодят ужасные, некрасивые и неэлегантные архитектурные решения, которые не всегда необходимы, для масштабирования таких платформ под высокой нагрузкой (вспомните опыт инженеров Instagram - https://xn--r1a.website/technologique/1214).

Стремитесь к красоте и элегантным решениям!

Developers on slower platforms often have so thoroughly internalized the limitations of their platform that they don't even recognize the resulting pathologies: Slow platforms yield premature architectural complexity as the weapons of “high-scale” such as message queues, caches, job queues, worker clusters, and beyond are introduced at load levels that simply should not warrant the complexity.

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

Яндекс.Такси проводит соревнование для бэкенд разработчиков.
Главный приз — 300 тысяч рублей.
В качестве заданий — реальные задачи разработчиков Яндекс.Такси.
Писать можно на C++, Python или Java.

Регистрация открыта до 13 июля:
https://taxi.yandex.ru/action/ytcf/coding_fest

#challenge

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

https://www.webstack.de/blog/e/cloud-hosting-provider-comparison-2017/

https://www.vpsbenchmarks.com/compare/scaleway_vs_vultr
https://www.vpsbenchmarks.com/plans

Ссылки:
https://www.scaleway.com/pricing/
https://www.online.net/en

https://www.vultr.com/pricing/

https://www.ovh.com/world/vps/

https://www.digitalocean.com/pricing/

https://www.linode.com/pricing

https://www.heroku.com/pricing

https://www.hetzner.com/cloud?country=us

#vps #vds #asp

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

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

Ссылки на материалы по теме:
https://xn--r1a.website/technologique/1054
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1051

The big short

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

https://neilpatel.com/blog/speed-is-a-killer/

И занимательная аналитика на эту же тему:

https://blog.hubspot.com/marketing/page-load-time-conversion-rates

В условиях микро и нано-сервисных облачных (cloud native, FaaS) инфраструктур - оптимизация по расходу памяти (memory footprint) и времени отклика (decrease latency) это уже устойчивый тренд, при том не только для крупных компаний, который имеет более важное практическое значение, чем синтетические нагрузочные бенчмарки с замерами значений RPS (requests per second) к различным программным подсистемам софта.

OOMd - user space daemon for killing processes by out of memory exception raises.

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

Буквально на днях коллеги из группы Facebook Open Source Team опубликовали исходники демона oomd работающего в пространстве привилегий пользователя для завершения процессов при срабатывании исключения out of memory (OOM), при чрезмерном расходе памяти приложениями и сервисами.

https://code.fb.com/production-engineering/open-sourcing-oomd-a-new-approach-to-handling-ooms/

https://github.com/facebookincubator/oomd

Также для более раннего обнаружения (до срабатывания исключения OOM Killer в ядре) паразитических процессов и нагрузки создаваемой ими и чтобы не потерять контроль над уже нестабильной системой (а также для повышения стабильности и отзывчивости системы) в момент срабатывания OOM Killer механизма ядра, для включения в ядро был предложен механизм Pressure Stall Information — pressure metrics, метрики, подобные load average, по таймфреймам, для создания и определения модели нагрузки и определения livelocks состояний (взаимоблокировки процессов при попытке завладения доступом к ограниченным ресурсам) по подсистемам cpu, memory и io, и по отдельным процессам, как для отслеживания "качества жизни" отдельных процессов и их окружений cgroups, так и нагрузки по подсистемам ресурсов в целом — для предоставления информации ядру и для более раннего обнаружения процессов слишком активно требующих выделения ресурсов системы и потребляющих их:

https://lkml.org/lkml/2018/7/12/661

Данный механизм ядра совместно с демоном oomd позволяет более точно отслеживать состояние процессов и выделение ресурсов в системе, более точно локализовать проблемные места (bottle-necks) для дальнейшей оптимизации сервисов по потреблению ресурсов, а также повысить отзывчивость (время реакции, задержки, latency), стабильность и надёжность (fault tolerance) работы системы, особенно в условиях мультиконтейнерных stateless окружений микро и нано сервисов, повысить эффективность утилизации ресурсов кластерных систем и масштабируемость приложений при миграции процессов в пределах кластерной системы.

Следующий большой шаг, над которым ведётся работа - разработка и интеграция новых решений для систем инициации (systemd, а также upstart и sysVinit для более старых систем) по отслеживанию состояний потребления ресурсов процессами резидентных приложений (демонов), с высоким постоянным невыгружаемым пулом памяти (memory footprint).

Существующие механизмы в текущих системах инициализации в ОС GNU/Linux не дают необходимой гибкости управления процессами, особенно у условиях состояний ограниченных или исчерпывающихся ресурсов в системе.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=

http://upstart.ubuntu.com/cookbook/#oom-score
http://upstart.ubuntu.com/cookbook/#respawn
http://upstart.ubuntu.com/cookbook/#respawn-limit

Хочу выразить благодарность Артёму, автору канала @SysadminNotes, за публикацию данной информации (https://xn--r1a.website/SysadminNotes/877) и за прекрасный и очень интересный канал (подписывайтесь, читайте - рекомендую! 😉)

PS: На самом деле очень приятно видеть, когда то, над чем работали для конторы уходит в open source - труды не пропадают даром и подобные проекты будут полезны всему сообществу. Жаль что не столь оперативно происходит открытие исходников подобных интересных проектов.

Материалы по теме:
https://xn--r1a.website/technologique/1253
https://xn--r1a.website/technologique/1254 - в данной статье я упоминал также про подобное уже существовавшее на тот момент решение проблемы ранней упреждающей обработки OOM исключений в user space, EarlyOOM (https://github.com/rfjakob/earlyoom)
https://xn--r1a.website/technologique/1255
https://xn--r1a.website/technologique/1256
https://xn--r1a.website/technologique/1258

Daemonization for JVM

Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.

То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.

На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.

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

В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).

Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.

Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.

Благо по системам инициализации есть прекрасная документация.

http://upstart.ubuntu.com/cookbook/#stanzas-by-category

http://upstart.ubuntu.com/cookbook/#initctl-commands-summary

http://upstart.ubuntu.com/cookbook/#expect

http://upstart.ubuntu.com/cookbook/#run-a-java-application

http://upstart.ubuntu.com/cookbook/#alternative-method

https://wiki.ubuntu.com/Upstart

https://www.freedesktop.org/software/systemd/man/systemd.exec.html

И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference

#Linux
#Ubuntu
#Upstart
#systemd

Rust concurrency in a nutshell

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

Отличная лекция Алекса Крайтона, разработчика библиотечных решений для использования паттернов многопоточности в языке Rust и знаменитого фреймворка Tokio для разработки приложений, использующих многопоточный асинхронный неблокирующий ввод-вывод (concurrent event loop for asynchronous non-blocking IO) — о подходах, моделях и парадигмах использованных в языке Rust для разработки безопасного многопоточного кода более простыми и понятными методами (closures, corourines, continuations, message passing and channels, actors, futures, promises и их использование в контексте концепций языка, системы типов и компилятора языка Rust — владения и заимствования для контроля использования указателей и время жизни для областей видимости в контексте вызова и исполнения функций).

#Rust

Ещё несколько классных статей одного автора на тему паттернов многопоточности в Rust:

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-no-context-no-cancel-no-leak-b6c1ec2dafa5

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-natural-born-pipelines-4d599e7612fc

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-communicate-by-sharing-your-sender-11a496ce7791

It’s that time again! Time for us to take a look at how the Rust project is doing, and what we should plan for the future. The Rust Community Team is pleased to announce our 2018 State of Rust Survey! Whether or not you use Rust today, we want to know your opinions. Your responses will help the project understand its strengths and weaknesses and establish development priorities for the future.Completing this survey should take about 10 to 15 minutes and is anonymous unless you choose to give us your contact information. We will be accepting submissions until September 8th, and we will write up our findings a month or so afterwards to blog.rust-lang.org. You can see last year’s results here.This year, volunteers have also translated the survey into many languages! You can now take the survey in:EnglishSimplified ChineseTraditional ChineseFrenchGermanHindiItalianKoreanPolishPortugueseRussianSpanishSwedishVietnamese(If you speak multiple languages, please pick one)Please help us spread the word by sharing the survey link on your social network feeds, at meetups, around your office, and in other communities.If you have any questions, please see our frequently asked questions or email the Rust Community team at community-team@rust-lang.org.Finally, we wanted to thank everyone who helped develop, polish, and test the survey!

via The Rust Programming Language Blog https://ift.tt/2MsBOmR

ECMAScript 9 (2018)

В стандарте ECMAScript 9 (2018) добавлена долгожданная поддержка positive and negative lookbehind assertions, backreferences и named captured groups - то, чего всегда не хватало для продвинутого поиска строк. Теперь регулярные выражения в JS стали ближе к PCRE. В скором времени поддержка более продвинутого синтаксиса регулярных выражений появится в движках браузеров, в Node.js и в редакторах VSCode и Atom (чего я лично особенно жду - уже привык к синтаксису Oniguruma в Sublime Text).
Также добавлена поддержка асинхронных итераторов и генераторов на уровне языка, через async/await синтаксис и на базе библиотечной реализации Promises.

http://www.ecma-international.org/ecma-262/9.0/index.html#prod-Assertion

http://www.ecma-international.org/ecma-262/9.0/index.html#prod-annexB-Assertion

http://www.ecma-international.org/ecma-262/9.0/index.html#sec-assertion

This specification, the 9th edition, introduces support for asynchronous iteration via the AsyncIterator protocol and async generators. This specification also includes four new regular expression features: the dotAll flag, named capture groups, Unicode property escapes, and look-behind assertions. It also includes rest parameter and spread operator support for object properties. There have also been many minor updates, editorial and normative, with many contributions from our awesome community.

Официальный релиз Dart 2.0

Уже не на Google IO 2018, но на днях состоялся официальный релиз второй версии языка Dart.

https://medium.com/dartlang/dart-2-stable-and-the-dart-web-platform-3775d5f8eac7

https://news.dartlang.org/2018/08/announcing-dart-2-stable-and-dart-web.html

В транслятор DartVM внедрили строгую систему динамических типов - типы данных записываются в байт-код при компиляции исходников (их верификации и выводе типов из выражений - flow-sensitive type system), но строгий контроль типов данных, динамическое связывание типов данных (статически записанных в байт-код - gradual type system) и значений объектов в памяти происходят во время исполнения кода в run-time. Такая схема напоминает расширение mypy (PEP-484) для статически аннотируемых типов в Python, используемое для снижения риска run-time ошибок и уменьшения пространства покрытия исходных текстов динамическими юнит тестами.
С одной стороны такая sounding type system даёт больший контроль типов данных и гибкость для обобщённых типов (для поддержки параметрического импредикативного полиморфизма), особенно с учётом вывода типов, но run-time проверки приводят к бОльшим задержкам при исполнении кода, что снижает производительность и применение языка для разработки критических к скорости реакции и чувствительных к задержкам онлайн систем и облачных инфраструктур.

https://medium.com/@matanlurey/dart-2-for-fun-and-profit-types-7757de406568

Виртуальная машина DartVM и платформа Flutter, работающая на ней и созданная для нативной разработки кроссплатформенных приложений, имеют несколько режимов компиляции - от нативной машиннозависимой AoT компиляции до динамической JIT кросскомпиляции байт-кода.

https://proandroiddev.com/flutters-compilation-patterns-24e139d14177

Для Dart уже есть инфраструктура сборки проектов Pub и экосистема пакетов на её основе - есть пакеты, которые можно использовать для различных платформ (изоморфная разработка). Например фреймфорк Angel можно использовать для разработки как серверной части (MVC), так и для разработки клиентских мобильных приложений на Flutter и веб-приложений на Dart Web - используется транскомпилятор Dart2JS, который напоминает по принципам своей работы TypeScript - исходники могут быть транскомпилированы в соответствии с различными стандартами ECMAScript для кросс-браузерной совместимости.

https://medium.com/dartlang/getting-ready-for-dart-2-and-making-your-packages-look-great-on-the-pub-site-118464d7f59d

Платформа Flutter имеет огромные перспективы, т.к. фактически это shim layer для DartVM, транслирующий API вызовы платформы Flutter в системные вызовы ОС и использующий FFI интерфейс к системным библиотекам для абстрагирования над системным API мобильных ОС, при этом с близкой к нулевой стоимостью таких обращений к системным библиотекам.

В ближайшие несколько лет Google имеет долгосрочный план перехода на Fuchsia OS для замены экосистемы Android - новая экосистема разработки будет построена именно вокруг и на базе Flutter SDK и NDK.

Ссылки на предыдущие публикации по Dart, Flutter и ОС Fuchsia:

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

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

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

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

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

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

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

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

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

https://github.com/flutter/engine/wiki/Flutter-Engine-Operation-in-AOT-Mode

Команда разработчиков Dart - это много очень опытных и умных людей, разрабатыающих ранее V8, HotSpot VM, Вячеслав Егоров в свою очередь сделал вклад в развитие проекта LuaJIT (автор проекта Михаэль Пэлл, Michael Pall).

https://www.blossom.co/blog/who-is-behind-dart