Scripting language

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

Расширение веб-программирования за пределы браузера идея не новая. В самом деле, мы сделали это с умеренным успехом в нашем проекте Node.js. Но более десяти лет спустя мы обнаруживаем, что серверный JavaScript безнадежно фрагментирован, глубоко привязан к плохой инфраструктуре и безвозвратно управляется комитетами без стимула к инновациям. Поскольку платформа браузера развивается быстрыми темпами, серверный JavaScript находится в застое.

Deno это наша попытка вдохнуть новую жизнь в эту экосистему. Обеспечить современную продуктивную систему программирования, которая придерживается API-интерфейсов браузера. Deno это не монолитная система, а скорее набор технологий, которые, как мы считаем, можно использовать для различных нужд. Не каждый вариант использования серверного JavaScript требует доступа к файловой системе; наша инфраструктура позволяет компилировать ненужные привязки. Это в свою очередь позволяет нам создавать собственные среды выполнения для различных приложений: графические интерфейсы в электронном стиле, бессерверные функции в стиле Cloudflare Worker, встроенные сценарии для баз данных и т.д.

Чтобы активно реализовывать эти идеи, мы собрали 4,9 миллиона долларов начального капитала. Нашими инвесторами являются Дэн Шольник из Four Rivers Ventures, Гильермо из Rauch Capital, Ли Джейкобс из Long Journey Ventures, Mozilla Corporation, Shasta Ventures и наш давний соавтор Бен Нордхуис. Эти инвестиции означают, что у нас будет штат опытных инженеров, работающих над улучшением Deno. Мы позаботимся о том, чтобы проблемы были решены, ошибки были исправлены, а выпуски были своевременно выпущены мы позаботимся о том, чтобы Deno стал платформой, на которую другие могут с доверием опираться.

Не сомневайесь, что Deno останется под лицензией MIT. Чтобы Deno рос и был максимально полезным, он должен оставаться относительно бесплатным. Мы не считаем, что бизнес-модель открытого ядра подходит для такой платформы программирования, как Deno. Мы не хотим оказаться в неудачном положении, когда нам придется решать, предназначены ли определенные функции только для платных клиентов. Если вы посмотрите наши выступления на конференции, то обнаружите, что мы много лет намекали на коммерческое применение этой инфраструктуры. Мы оптимистично оцениваем стек технологий, который мы создали, и намерены сами развивать эти коммерческие приложения. Наш бизнес будет опираться на проект с открытым исходным кодом, а не пытаться напрямую его монетизировать.

Многие лучше знакомы с консолью Chrome DevTools, чем с командной строкой Unix. Более знакомы с WebSockets, чем с сокетами BSD, MDN, или с man-страницами. Сценарии Bash и Zsh, вызывающие нативный код, никогда не исчезнут. Но скрипты JavaScript и TypeScript, вызывающие код WebAssembly, будут все более распространенными. Мы думаем, что многие разработчики предпочитают сначала веб-слои абстракции.

Компания Deno надеется дать возможность миллионам веб-программистов максимально использовать свое мастерство в других областях.

• Deploy
• CLI
• Deno 1.0

В своё время посты на Хабре и Reddit о статически типизированном скриптовом языке Umka вызвали весьма активную дискуссию.

Прошедшие полтора месяца позволили мне избавиться от некоторых заблуждений, развить язык и дать чуть более вразумительные ответы на вопросы публики. Как и следовало ожидать, наиболее серьёзное испытание выпало на долю самой концепции статической типизации. Она осталась в основе языка, но потребовала компромиссов в частности, для корректной сборки мусора.

Появились первые замеры быстродействия интерпретатора в сравнении с Wren и Python их результаты внушают оптимизм. Наконец, родился более реалистичный пример использования Umka по его основному назначению, т. е. как встраиваемого языка.

Информация о типах во время исполнения программы (RTTI). Проект начинался с радикального отказа от хранения типов данных при исполнении программы. Вся информация о типах терялась после компиляции в байт-код виртуальной машины. В принципе, статическая типизация позволяет это сделать, а заодно избавляет от странных трюков вроде упаковки данных в NaN, к которой, например, прибегают создатели JavaScript и Wren ради увеличения быстродействия. Однако обнаружились два случая, в которых пришлось использовать RTTI:

• Приведение интерфейсного типа данных к конкретному прямой аналог утверждения типа (type assertion) в Go, а также, отчасти, оператора dynamic_cast в C++. Оно требуется и при сборке мусора, содержащегося в данных, приведённых к интерфейсному типу.
• Сборка мусора, связанного с динамическими структурами данных вроде списков и деревьев.

Быстродействие. Изначально Umka никак не предназначался для установления рекордов быстродействия. Безразличие публики к медлительности Python наводило на мысль, что скорость вовсе не то качество, которого в первую очередь ожидают от скриптового языка. Однако успех LuaJIT и активная реклама Wren заставили задуматься. После этого меня уже не удивляло, что и ранние публикации про Umka вызвали вопросы о быстродействии, хотя мне по-прежнему интересно, от кого в первую очередь исходит спрос на скорость. От разработчиков игр?

Пока полный набор тестов не готов, я могу поделиться лишь предварительными результатами замеров. В численных задачах (например, задаче многих тел) Umka надёжно опережает Python, а если в задаче активно используется цикл for, то Umka даёт выигрыш даже по сравнению с Wren, который позиционируется автором чуть ли не как самый быстрый скриптовый язык после LuaJIT. Наглядным примером служит перемножение больших матриц:


Умножение матриц 400 x 400 (AMD A4-3300M @ 1.9 GHz, Windows 7)

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

Задачи с интенсивной сборкой мусора (например, создание и обход двоичных деревьев) вызывают много сомнений по поводу эквивалентности сравниваемых алгоритмов. Например, известная реализация двоичных деревьев на Python возвращает содержимое узлов россыпью и выглядит так, будто в принципе допускает размещение всего дерева на стеке вообще без использования кучи и сборки мусора. Однако она, по-видимому, требует динамической типизации и не может быть точно воспроизведена на Umka. Если же потребовать возвращать узлы в виде структур, как в Umka (а за неимением структур приходится требовать объекты), то быстродействие Python сразу же падает в 3-4 раза. Вариант на Umka вдвое отстаёт от первой реализации и вдвое опережает вторую. Какое сравнение корректнее не знаю.

Взаимодействие с внешним кодом. Коль скоро язык рассматривается как встраиваемый, понадобился более или менее реалистичный пример взаимодействия кода на C и Umka. В нём средствами игровой библиотеки raylib формируется трёхмерная сцена, а наполнение сцены определяется внешним скриптом на Umka. В примере можно найти и вызов функций Umka из кода на C, и вызов функций C из Umka. Статическая типизация языка Umka позволила естественным образом формировать на нём структуры данных, непосредственно воспринимаемые библиотекой raylib.


Пример трёхмерной сцены, содержимое которой задаётся скриптом на Umka

Обобщённые типы и функции (generics). Как только читатель улавливает сходство Umka с Go, пускай даже синтаксическое следует вопрос о поддержке generic'ов. Работа в этом направлении пока не вышла из стадии обзора подходов. Конечно, хотелось бы воспользоваться предложениями разработчиков Go, однако сосуществование в их головах интерфейсов и контрактов всегда отпугивало, как странное дублирование понятий. К удивлению и радости, в только что вышедшей новой редакции черновика контракты исчезли по тем же причинам, о которых размышлял и я. Пока generic'ов в Umka нет, остаётся пользоваться, как и в Go, пустыми интерфейсами interface{}.

Документация. Полная спецификация Umka ещё в работе, но уже написана грамматика и расширен обзорный тур по основным возможностям языка.