Mozilla собирается использовать WASI для всех устройств, компьютеров и операционных систем

Автор оригинала: Thomas Claburn
  • Перевод

Всем привет! На связи TestMace и мы продолжаем знакомить вас с самыми горячими новостями из мира JavaScript. На очереди перевод статьи о WASI — технологии, которая позволит использовать WebAssembly вне браузеров


Один формат, чтоб править всеми



Компания Mozilla на этой неделе представила проект под названием WASI (WebAssembly System Interface), призванный стандартизировать взаимодействие WebAssembly-кода с операционной системой. Если проект окажется успешным, он будет выполнять те же функции, что и виртуальная машина Oracle Java, но гораздо эффективнее и с расширенным функционалом.


WebAssembly (WASM) — это бинарный формат инструкций для виртуальной машины, который может выполняться на различных аппаратных архитектурах. Код, написанный на многих языках вроде C/C++, Go, Rust может быть скомпилирован в WASM-код.


Многие веб-браузеры ввели поддержку WebAssembly, но до этого момента не существовало стандарта, позволяющего работать с ним вне браузера. А теперь появился WASI.
"Необходим способ взаимодействия кода с системой за пределами браузера, то есть системный интерфейс", — объяснил разработчик компании Mozilla Лин Кларк в этом посте блога Mozilla Hacks. "У платформы WebAssembly такого способа пока нет".


WASM+WASI


С помощью WASI WASM-код может быть запущен в браузере или любой другой совместимой среде, что предоставляет возможность кроссплатформенной разработки, независимой от языка. В то время как переносимый интерфейс операционных систем (POSIX) направлен на обеспечение переносимости исходного кода программ между UNIX-подобными операционными системами, WASI предназначен для поддержки совместимости скомпилированных бинарных файлов на разных устройствах и операционных системах. Стандарт предоставляет универсальную среду выполнения, скорость работы которой близка к нативной.


Виртуальная машина Java (JVM) делает всё то же самое, но для запуска Java-кода в браузере необходим плагин. Несмотря на то, что гибкость языка, подобная предлагаемой платформой WebAssembly, может быть достигнута в Java с помощью GraalVM, экосистема Java всё ещё находится в тени из-за событий, связанных с претензиями компании Oracle по нарушению их интеллектуальной собственности.


Формат WASM, обеспечивая безопасность доступа к памяти и удобную валидацию, имеет преимущество над Java-апплетами по части безопасности, хотя и может подвергаться атакам, направленным на изменение изначального потока управления программой. А ещё он отлично ладит с языками C/C++ и Rust.


Лидер команды, занимающейся WebAssembly в компании Mozilla, Тилль Шнайдерайт объясняет разницу между WebAssembly и Java в Твиттере следующим образом: "WebAssembly был спроектирован чтобы масштабироваться с миниатюрных устройств на огромные группы серверов или CDN. Формат куда более независим от языка, чем Java, да и реализация куда менее требовательна к ресурсам".


Если вам еще не очевидны потенциальные преимущества WASI, то вот что сказал о нём один из создателей Docker Соломон Хайкс: "Если бы WASM+WASI существовали в 2008, нам и не пришло бы в голову создавать Docker. WebAssembly на стороне сервера — за этим будущее вычислений. Нам так не хватало стандартизированного системного интерфейса. Надеюсь, WASI решит эту проблему!"


На этой волне оптимизма компания Fastly в четверг выпустила Lucet — нативный компилятор и среду для выполнения WASM-кода WebAssembly в облачных средах. Он дополняет Mozilla Wasmtime — среду выполнения WASM-кода за пределами браузера.


Конечно, WASI ещё далек от идеала. WebAssembly также было бы неплохо подвергнуть дальнейшей доработке, например, добавить возможность получения доступа к DOM браузера. Хотя разработчики уже отлично постарались, предоставив единый платформонезависимый бинарный формат. А пока желаю вам удачного опыта с Java.


Наша команда создает крутой инструмент TestMace — мощная IDE для работы с API. Создавайте сценарии, тестируйте эндпоинты и пользуйтесь всей мощью продвинутого автодополнения и подсветки синтаксиса. Пишите нам! Мы тут: Telegram, Slack, Facebook, Vk

Поделиться публикацией

Комментарии 10

    0
    Пока не очень понятно зачем сейчас компилировать C/C++/Rust/Go в WASM и запускать все это дело на сервере, когда задача доставки этого кода успешно решена.
      0
      Альтернативная контейнеризация/изоляция.
      среду для выполнения WASM-кода WebAssembly в облачных средах
      twitter.com/solomonstre/status/1111004913222324225
      github.com/wasmerio/wasmer/tree/master/examples
        0
        Альтернатива это всегда хорошо, но тут есть нюансы. Как профилировать C++/Rust/Go/PHP/Python код, насколько добавляет оверхед.
          0
          По PHP можно посмотреть здесь medium.com/wasmer/php-ext-wasm-migrating-from-wasmi-to-wasmer-4d1014f41c88
          Finally, the PHP extension provides a faster execution than PHP itself! php+wasmer(cranelift) is 8.6 times faster than php to be exact. And it is 28.6 times faster than php+wasmi. Can we reach the native speed (represented by rust-baseline here)? It’s very likely with LLVM. That’s for another article.
            0

            Пусть сперва возьмут какой нибудь пример из жизни, например Wordpress, на котором тестировали PHP7.


            Например есть такая замечательная библиотека simdjson, которая использует SIMD инструкции. И судя по Features to add after the MVP ни потоков, ни SIMD пока еще нет, а это значит что о производительности остается только мечтать.

              0
              Так ведь никто и не говорит что оно готово для продакшена, но для некоторый вещей уже можно использовать.
      –3
      Я всегда говорил что Docker это один сплошной костыль. Рад что ситуация исправляется. WASI в скором будущем обьет не только Docker, но и кучу сопутствующей ему инфраструктуры.

      А ведь тысячи идиотов веровали в то, что контейнеры захватят мир.
        +2
        КМК, WASI и контейнеры решают разные задачи
        +1

        Кто покусал автора этого опуса? Сплошные лозунги и восхваления ещё не запущенной системы, зачем-то сравнивается с java, в которой апплеты — это вообще отдельный стандарт… и сейчас начисто выкушено из браузеров. Если вы говорите про системные вызовы, не связаные с браузерами, так и сравнивайте с обычной jvm, а не кастрированной апплетной подсистемой.

          +1
          Мое любимое место в статье:

          Если проект окажется успешным, он будет выполнять те же функции, что и виртуальная машина Oracle Java, но гораздо эффективнее и с расширенным функционалом.


          Ключевое слово не «будет» (оно ой как вилами на воде писано), а «если».

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое