Здравствуйте, c-smile, Вы писали:

_>>Ты забываешь про WebGL. )))
CS>WebGL это тоже canvas
CS>

CS>gl = canvas.getContext('webgl')
CS>

Конечно, только рисуют в него совсем по другому. )

_>>Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее.
CS>Только если WebAsm'у позволено обращаться напрямую к методам DOM. Пока — нет.

Зачем ему DOM, если ему доступен OpenGL в предоставленную canvas? ))) Ну точнее пока DOM ещё используется в какой-то степени снаружи (через js), для перехвата сообщений от мышки/клавы и пересылки их в wasm приложение. Но надеюсь это они доработают, придумав какой-то аналог API для обработки "оконных сообщений". А вот DOM для вывода информации в таких приложениях точно не нужен. )

CS>>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
_>>Байткод бывает разный. Бывает JVM, а бывает LLVM. )
CS>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.

В быстродействие (ради которого wasm и придумали) разница очень принципиальная. ))) Что касается ограничений, то я ещё не смотрел детальную реализацию wasm, так что ничего сказать не могу. Но думаю что там всё реализовано достаточно эффективно, иначе бы просто во всём этом не было бы смысла. )))

Здравствуйте, alex_public, Вы писали:


_>В быстродействие (ради которого wasm и придумали) разница очень принципиальная. )))

Здравствуйте, c-smile, Вы писали:

CS>>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
_>>Байткод бывает разный. Бывает JVM, а бывает LLVM. )
CS>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.

Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. )

Здравствуйте, alex_public, Вы писали:

CS>>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.

_>Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. )

Причем здесь это ? LLVM это bytecode generator. Кто исполняет это bytecode?

Представь себе что WebAsm может читать/писать произвольные адреса внутри browser. Любой "залетевший дятел" сразу начнет писать "стыривалки" паролей, да вообще что угодно.
Неправильно ведь, да? Т.е. нужно sandbox'ить это дело. Защита памяти только на уровне процесса в текущих архитектурах. Т.е. все защиты будут делаться программно.
Ну и всё такое...

На самом деле WebAsm он не для C/C++. А для всяких там TypeScript и прочего. Т.е. WebAsm это фактически расширенный JavaScript bytecode.
Просто отцов-основателей достали стоны про то какое г. этот ваш JS. Ну вот и делается WebAsm для "хочите front end на Haskell писать- нате вам".
Работать это если и будет быстрее чем JS то не намного. Просто из-за специфики JS в котором нет int32, int64 и пр. базовых вещей.

Здравствуйте, c-smile, Вы писали:

CS>>>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.
_>>Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. )
CS>Причем здесь это ? LLVM это bytecode generator. Кто исполняет это bytecode?

LLVM тут вот https://github.com/WebAssembly/binaryen/wiki/Compiling-to-WebAssembly-with-Binaryen причём. Да, это не имеет отношения к вопросу безопасности памяти (про это ниже), но имеет отношения к оптимизации и производительности кода.

CS>Представь себе что WebAsm может читать/писать произвольные адреса внутри browser. Любой "залетевший дятел" сразу начнет писать "стыривалки" паролей, да вообще что угодно.
CS>Неправильно ведь, да? Т.е. нужно sandbox'ить это дело. Защита памяти только на уровне процесса в текущих архитектурах. Т.е. все защиты будут делаться программно.
CS>Ну и всё такое...

Хы, смешно, ты вот действительно думаешь, что описанное тобой — это какая-то проблема? С учётом того, что у нас приходят не машинные коды, а AST, которое надо ещё оттранслировать в машинные коды (и как раз тут можно встроить любую защиту)?

Память в wasm устроена очень просто: http://webassembly.org/docs/semantics/#linear-memory. Т.е. внутри своего куска памяти ты можешь развлекаться любыми "нативными" способами, как тебе угодно. Нужна только гарантия, что ты не вылезешь за пределы этого куска (т.е. что величина указателя меньше значения current_memory данного модуля). Реализация этого момента в документации оставлена на усмотрение "встраивателя" (т.е. в данном случае авторов браузера). Но понятно, что это элементарно делается при трансляции wasm инструкций load и store в машинные коды.

CS>На самом деле WebAsm он не для C/C++. А для всяких там TypeScript и прочего. Т.е. WebAsm это фактически расширенный JavaScript bytecode.
CS>Просто отцов-основателей достали стоны про то какое г. этот ваш JS. Ну вот и делается WebAsm для "хочите front end на Haskell писать- нате вам".

О, какие интересные открытия у нас тут на форуме встречаются. ))) Только вот есть небольшая неувязка — на самом сайте wasm указано прямо противоположное: http://webassembly.org/docs/high-level-goals/.

CS>Работать это если и будет быстрее чем JS то не намного. Просто из-за специфики JS в котором нет int32, int64 и пр. базовых вещей.

Ну запишем это твоё предположение. И после проведения первых же тестов вернёмся к нему. Ну просто чтобы не тратить время на лишние споры, а сразу фактами решить вопрос. ) Хотя лично я уже сейчас вижу, что ты абсолютно не прав. )))

P.S. Почитал тут эту http://webassembly.org/docs/use-cases/ их страничку. Про раздел Inside the browser я приблизительно так и представлял целевую нишу данной технологии. А вот их раздел Outside the browser довольно любопытен — как-то я не думал про подобное применение. Хотя с точки зрения эффективности голый LLVM должен быть лучше, но там нет никакой безопасности. Так что возможно оно действительно не только в вебе пригодится.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач.

А они никуда не делись, эти "старые задачи".
Тот факт, что добавились новые, не означает потерю старых.
Просто теперь конторы должны оплачивать разработку копий клиентского софта для Андроида, iOS и виндов + трахаться с поддержкой актуальности такого софта уникально для каждой платформы (внутренняя прога служб такси, система оформления заказов для оптовой конторы и т.д. до бесконечности).
Суть веба когда-то была в том, чтобы всего этого не делать.

Сейчас корпоративный сектор, считай, грубо кинут гуглом и мозиллой.

Здравствуйте, alex_public, Вы писали:

_>Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. )

На новый круг решил зайти? ))

Такая же песочница была и в Java-апплетах, и во Флеше и в Сервелате.
Причем, этим песочницам много лет, много было поймано и отлажено багов.
Гуглу только еще предстоит пройти тяжелый путь созревания технологии.

Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.

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

Скажем так.
Когда много лет назад я увидел рекламу Гугла про их новый браузер, у меня был сильный негатив по этому поводу.
Собсно, всё было понятно — это чудо потянуло свои немытые ручки туда, где его никогда не было.
И, разумеется, потянуло ручки не с целью сделать всем приятно, а ровно наоборот — подгадить всем, кому получится.

По-сути, надо было начинать разваливать Гугл в судебном порядке уже тогда, как MS за 5-6 лет до этого.
Потому что теперь мы имеем ту самую нечестную конкуренцию через манипуляцию понятием "современные стандарты".

Здравствуйте, vdimas, Вы писали:

НС>>Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач.
V>А они никуда не делись, эти "старые задачи".

Да не делись конечно. Только другие задачи стали важнее и фокус ушел на них.

V>Просто теперь конторы должны оплачивать разработку копий клиентского софта для Андроида, iOS и виндов + трахаться с поддержкой актуальности такого софта уникально для каждой платформы (внутренняя прога служб такси, система оформления заказов для оптовой конторы и т.д. до бесконечности).

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>У качественного мобильного софта тоже акценты сместились. Если приложение для вызова такси или онлайн-банкинга построено по принципу десктопного софта, оно тут же идет в мусор.

А это здесь причем?
Богатая функциональность не обязательно означает дестопный GUI.

Здравствуйте, vdimas, Вы писали:

_>>Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. )
V>Такая же песочница была и в Java-апплетах, и во Флеше и в Сервелате.
V>Причем, этим песочницам много лет, много было поймано и отлажено багов.
V>Гуглу только еще предстоит пройти тяжелый путь созревания технологии.

Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки:

1. Зависимость от одного языка/платформы.
2. Зависимость от одной компании, управляющей развитием данной технологии.

В wasm у нас эти неприятности решены от рождения: технология мультиязычная и развивается консорциумом ведущих игроков в данной области (Mozilla, Google, Microsoft, Apple).

V>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.

Что за бинарная машинка для wasm и почему она производства Гугла? )

alex_public:

_>https://geektimes.ru/post/286718/ — позитивная новость!
_>Ну что господа C++'ки, начинаем ваять сайтики? https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. )

Третий раз изобрели Джаву. Зачем?
Чем не годились первые две?
И джавовский и дотнетовский байткоды тоже строятся на стек-машинах.
Чем они плохи?
Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде.
Джава таки давно используется...

Здравствуйте, Дрободан Фрилич, Вы писали:

_>>https://geektimes.ru/post/286718/ — позитивная новость!
_>>Ну что господа C++'ки, начинаем ваять сайтики? https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. )
ДФ>Третий раз изобрели Джаву. Зачем?
ДФ>Чем не годились первые две?
ДФ>И джавовский и дотнетовский байткоды тоже строятся на стек-машинах.

Я бы сказал, что это скорее ближе к безопасному LLVM)

ДФ>Чем они плохи?
ДФ>Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде.
ДФ>Джава таки давно используется...

Оно будет побыстрее и без вендор лока. )

Здравствуйте, alex_public, Вы писали:

_>Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки:
_>1. Зависимость от одного языка/платформы.

Давай называть вещи своими именами.
Не было возможности задействовать тонны легаси кода на С/С++ в вебе. ))


_>2. Зависимость от одной компании, управляющей развитием данной технологии.

Это как раз не принципиально.

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


_>В wasm у нас эти неприятности решены от рождения: технология мультиязычная и развивается консорциумом ведущих игроков в данной области (Mozilla, Google, Microsoft, Apple).

Немного не так. Гугл+Мозилла выступили с некоей инициативой, поставив других членов W3C перед фактом: участвовать в доработке стандартов этих инициатив или совсем остаться не у дел. Когда-то за гораздо менее наглые выходки насильно в судебном порядке развалили MS.

Просто тут так странно получается, что якобы свободные разработчики ПО (какими себя усердно называют мозилловцы) по-сути остаются безнаказанными независимо от любых своих выкрутасов. Очень удобно, чо.

Но я никогда не верил, что программисты из Мозиллы работают даром, ес-но.
Кто-то им платит ЗП. С какой целью?
Тут получается та самая разновидность благопристойной (якобы благопристойной) ширмы для грубого передела рынка Сети:

Организация Mozilla огласила финансовые результаты за 2012 год. К сожалению, диверсифицировать источники дохода организации не удается. Совсем наоборот: в очередной раз увеличилась финансовая зависимость от компании Google, которая в прошлом году обеспечила 90% всех доходов Mozilla. Годом ранее этот показатель составлял 85%.

На сегодня Мозилла — это филиал Гугла.
Прикормленные с рук крестьяне.
Финита ля комедия.

Вернее, комедию ломают перед нами и держат за идиотов.
В одиночку, без Мозиллы, только лишь через свой Хром, Гугл не смог бы "запретить" популярные еще вот недавно веб-технологии, ес-но.


V>>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.
_>Что за бинарная машинка для wasm и почему она производства Гугла? )

Я уже упоминал в прошлом обсуждении, откуда у всего этого растут ноги:
https://en.wikipedia.org/wiki/Google_Native_Client
https://auth0.com/blog/7-things-you-should-know-about-web-assembly/

The web is not controlled by any single vendor, so every change must be a joint effort. Fortunately, the teams behind WebAssembly know this. At Mozilla, a group of hardcore developers tried to provide an answer in the form of asm.js: a subset of JavaScript meant to serve as a compiler target. On the other side, Google worked on Native Client (NaCl) and Portable Native Client (PNaCl), a binary format for the web based on LLVM.

Выделенное — это самая большая современная ложь.
Примерно как мантры про демократию на Западе. ))

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

Как это всё смотрится со стороны, думаю, объяснять не надо.
Пахнет это всё отвратительно.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Дрободан Фрилич, Вы писали:

_>>>https://geektimes.ru/post/286718/ — позитивная новость!
_>>>Ну что господа C++'ки, начинаем ваять сайтики? https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. )
ДФ>>Третий раз изобрели Джаву. Зачем?
ДФ>>Чем не годились первые две?
ДФ>>И джавовский и дотнетовский байткоды тоже строятся на стек-машинах.

_>Я бы сказал, что это скорее ближе к безопасному LLVM)

А какая разница? И то и то требует JIT — компиляцию в target машину.

Единственная принципиальная разница в том что Java bytecodes имеют ввиду GC. Что есть большой плюс в контексте browser based UI — ownership graph в event driven системах крайне сложный.

На самом деле JavaVM, это не побоюсь этого слова, архитектурно идеальное решение для работы именно внутри browser. Там всё заточено именно для этого use case. Да и создавалась она именно для этого изначально. Server side Java usage это не от хорошей жизни.
Если бы там была конструкция типа VARIANT то мы бы сейчас вместо JavaScript наблюдали бы толпу разных скриптовых языков транслируемых в .class файлы работающих в browser.


ДФ>>Чем они плохи?
ДФ>>Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде.
ДФ>>Джава таки давно используется...

_>Оно будет побыстрее и без вендор лока. )

"Оно будет побыстрее"... если и будет то совсем незначительно. JIT c managed прослойками в обоих случаях.

Здравствуйте, vdimas, Вы писали:

_>>Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки:
_>>1. Зависимость от одного языка/платформы.
V>Давай называть вещи своими именами.
V>Не было возможности задействовать тонны легаси кода на С/С++ в вебе. ))

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

_>>2. Зависимость от одной компании, управляющей развитием данной технологии.
V>Это как раз не принципиально.
V>Мои претензии тут того плана, что некая новая технология должна естественным путём выигрывать конкуренцию, а не по той единственной причине, что все остальные оказались под искусственным запретом.

Общетеоретически я тут с тобой конечно же согласен. Но в данном конкретном случае я всё же предлагаю оценить трезво предоставленный "неконкурентный" продукт — пока он по всем параметрам выглядит интереснее "заблоченных" конкурентов. )

V>>>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.
_>>Что за бинарная машинка для wasm и почему она производства Гугла? )
V>Я уже упоминал в прошлом обсуждении, откуда у всего этого растут ноги:
V>https://en.wikipedia.org/wiki/Google_Native_Client
V>https://auth0.com/blog/7-things-you-should-know-about-web-assembly/
V>

V>The web is not controlled by any single vendor, so every change must be a joint effort. Fortunately, the teams behind WebAssembly know this. At Mozilla, a group of hardcore developers tried to provide an answer in the form of asm.js: a subset of JavaScript meant to serve as a compiler target. On the other side, Google worked on Native Client (NaCl) and Portable Native Client (PNaCl), a binary format for the web based on LLVM.

Ну как бы всё верно. LLVM очень хорош по эффективности, но в прямом виде небезопасен. Asm.js очевидно полностью безопасный, но не такой эффективный. А сейчас мы видим в wasm оптимальную смесь — эффективное и безопасное решение. Причём в инструментарий wasm входят как раз компиляторы llvm->wasm и asm.js->wasm.

V>Выделенное — это самая большая современная ложь.
V>Примерно как мантры про демократию на Западе. ))
V>Ну и изначальная ориентировка на LLVM — оно не принципиально ни разу, ес-но. Т.е. это НЕ важно, каков будет конечный стандарт байт-кода этой виртуальной машинки, бо не за тонкости будущего стандарта идёт битва, а за право контролировать процесс разработки стандартов и технологий. за право навязывать свои правила игры.
V>Как это всё смотрится со стороны, думаю, объяснять не надо.
V>Пахнет это всё отвратительно.

Нуу "политику" мне обсуждать уже лень... ) Скажу только что все материалы и инструменты для wasm изначально выложены в открытый доступ (здесь https://github.com/WebAssembly) и лицензии там везде Apache. Так что на данный момент меня всё устраивает. Пусть даже это и результат хитрых подковёрных игр. )))

Здравствуйте, c-smile, Вы писали:

_>>Я бы сказал, что это скорее ближе к безопасному LLVM)
CS>А какая разница? И то и то требует JIT — компиляцию в target машину.
CS>Единственная принципиальная разница в том что Java bytecodes имеют ввиду GC. Что есть большой плюс в контексте browser based UI — ownership graph в event driven системах крайне сложный.

Так же ещё например такие радости как рантайм рефлексию, боксинг и т.п. )

CS>На самом деле JavaVM, это не побоюсь этого слова, архитектурно идеальное решение для работы именно внутри browser. Там всё заточено именно для этого use case. Да и создавалась она именно для этого изначально. Server side Java usage это не от хорошей жизни.
CS>Если бы там была конструкция типа VARIANT то мы бы сейчас вместо JavaScript наблюдали бы толпу разных скриптовых языков транслируемых в .class файлы работающих в browser.

Ну как бы JS сейчас не сильно медленнее Java. ) Смысл Java был бы разве что в статической типизации, актуальной для сложных проектов. Но сейчас же ещё TypeScript появился...

_>>Оно будет побыстрее и без вендор лока. )
CS>"Оно будет побыстрее"... если и будет то совсем незначительно. JIT c managed прослойками в обоих случаях.

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

Здравствуйте, alex_public, Вы писали:

V>>Мои претензии тут того плана, что некая новая технология должна естественным путём выигрывать конкуренцию, а не по той единственной причине, что все остальные оказались под искусственным запретом.
_>Общетеоретически я тут с тобой конечно же согласен. Но в данном конкретном случае я всё же предлагаю оценить трезво предоставленный "неконкурентный" продукт — пока он по всем параметрам выглядит интереснее "заблоченных" конкурентов. )

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

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


_>Ну как бы всё верно. LLVM очень хорош по эффективности, но в прямом виде небезопасен. Asm.js очевидно полностью безопасный, но не такой эффективный. А сейчас мы видим в wasm оптимальную смесь — эффективное и безопасное решение. Причём в инструментарий wasm входят как раз компиляторы llvm->wasm и asm.js->wasm.

Еще раз, конечный формат бинарного байт-кода не принципиален ни разу.
Я не сомневаюсь, что во втором десятилетии 21-го века нарисуют необходимую схему с учётом специфики веба.

Тут другая интрига нарисовывается:
Собсно, сейчас функциональность "песочниц" встроена прямо в современные OS — в Win 8 и выше, в iOS.
Т.е., имеет ли смысл в браузере делать еще одну собственную "песочницу", если сам браузер работает из под песочницы?
Вернее, сразу из под кучи песочниц, т.к. имеет возможность запускать по песочнице на страницу прямо ср-вами ОС — ведь приложению-браузеру доступно только "песочное" ограниченное АПИ ОС.

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

Т.е., пока что выглядит так, что они ниасилили песочницу на уровне ОС (линуха), поэтому делают её на уровне браузера.
Ну и заодно решили превратить этот недостаток в достоинство через давление на W3C, пользуясь своим монопольным положением на рынке браузеров. ))


_>Скажу только что все материалы и инструменты для wasm изначально выложены в открытый доступ (здесь https://github.com/WebAssembly) и лицензии там везде Apache. Так что на данный момент меня всё устраивает. Пусть даже это и результат хитрых подковёрных игр.

Я не против, пусть выкладывают что угодно куда угодно.
Я против того, чтобы некие выложенные сырые вещи (или даже не сырые — не принципиально) использовались как оправдание для зачистки конкурентов.

Здравствуйте, Дрободан Фрилич, Вы писали:

ДФ>Третий раз изобрели Джаву. Зачем?
ДФ>Чем не годились первые две?

1. Были завязаны на ООП.
2. NIH.

Здравствуйте, fddima, Вы писали:

F>Так там туда же ссылка и стоит. Что-то будет точно

Пока что даже GC не планируется для вебасма.
Сказано так: GC может быть выполнен в виде скомпиллированной в webasm VM.
То бишь, возьми реализацию VM джавы или дотнета, портируй её на webasm, вот и будет тебе GC.
Правда, к GC JS браузера он не будет иметь никакого отношения.


F>а вот с какими ограничениями — уже будет видно по факту. Что они подразумевают под opaque reference types — мне вот не очень понятно...

Некий тип без объявления "тела". Такой тип можно получать и передавать по ссылке.

Это похоже на одну из идей, как можно сделать вызовы из нейтивной (по архитектуре) webasm в управляемую JS-среду.
Например, как-то так:

class JsObject;
typedef JsObject * JsRef;

И затем погнали некое АПИ сверху, типа такого:

void incrementRef(JsRef jsObj);
void decrementRef(JsRef jsObj);
size_t memberCount(JsRef jsObj);
JsObject getMemberByIndex(JsRef jsObj, size_t index);
JsObject getMemberByName(JsRef jsObj, JsStringRef name);

Тут одно плохо — они в эту сторону не то, что делать что-то еще не начали, тут даже еще серьезного обсуждения нет.

Т.е., все эти вещи если и появятся — то очень не скоро и скорее всего сам JS будет уже не актуален на тот момент.


F>если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.

Не-е-е-е. Ты не понял. "Плоская память" VM WebAsm и память JS-машинки вообще никак не пересекаются по GC.

Я рядом давал ссылки, они рассуждают так, что для GC объектов (если GC когда-нить и будет частью webasm) будет выделена совсем отдельная куча. Более того, если почитать вот эту ссылку внимательно:
https://github.com/WebAssembly/design/blob/master/GC.md
то выглядит так, что они уже и сами поняли, что в случае GC у них получится Java/Дотнет, вид сбоку, ы-ы-ы.

Посмотри, что ни хотят сделать с JS:
https://github.com/nikomatsakis/typed-objects-explainer/blob/master/README.md

Здравствуйте, vdimas, Вы писали:

Я как раз всё понял и правильно.
Отсутствие внятного интеропа с сервисами браузера (читай с тем же DOM) — пока-что сильно ограничивает применимость технологии в массах. Если и когда сделают интероп — надо будет смотреть по факту, какой механизм для этого привлекут. Остальное шелуха.