Design: Следует ли WebAssembly считать критически важной совместимость с Open Web Platform?

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

Было бы полезным мысленным экспериментом рассмотреть гипотетическую крайнюю позицию «если функция способствует совместимости с Интернетом, мы должны добавить ее в Wasm», с чем я бы не согласился, потому что в конечном итоге это привело бы к раздуванию языка кучей Хуки, специфичные для JS. Я не подразумеваю, что вы отстаиваете такую ​​позицию, но я действительно думаю, что ваше заявление, написанное в ОП, не отражает концептуальных разногласий, которые, кажется, возникают в вопросах, которые вы связали.

Существует также различие между основным языком «WebAssembly» (который, как мне кажется, абсолютно должен оставаться совместимым с «Открытой веб-платформой») и экосистемой инструментов, хост-интерфейсов и пространств имен импорта, которые можно выбрать для стандартизации/разработки вокруг него. . Менее важно, чтобы WASI оставался «удобным для Интернета», потому что это пространство имен импорта, которое хосты могут просто не предоставлять. В самом худшем случае это приведет к дублированию усилий/разделению цепочки инструментов, если кто-то позже стандартизирует более удобный для Интернета API.

Да, некоторые из этих вопросов немного устарели, и сегодня я бы, конечно, подошел к ним по-другому (даже тем более, если бы такое обязательство существовало в то время). Я немного подумаю над этим и другими вашими пунктами :)

Я был немного удивлен впечатлением, что я выступаю за дополнения к основному языку во многих проблемах, поэтому, возможно, было бы хорошо дать некоторый контекст. Время от времени я действительно разрабатывал альтернативу заднего кармана (я думаю), где она казалась полезной в контексте обсуждения, что можно рассматривать как поддержку дополнений, я думаю, в первую очередь Universal Strings, где я пытался помочь разрешить предполагаемый тупик между интерфейсом Типы и GC, которые указывали друг на друга, несли ответственность за мои проблемы. Оглядываясь назад, я сожалею, что снова поднял этот вопрос в выпуске ИТ, поскольку GC кажется более подходящим местом. Тогда, возможно, он все еще взорвался там, не уверен. В конце концов, я никогда не предлагал их, учитывая также существующую напряженность, а в основном создавал их из желания объяснить, что конкретно я имею в виду. Оглядываясь назад, я нахожусь перед дилеммой, так как предложение чего-либо кажется обреченным в любом случае из-за напряженности, и более подробная проработка моих аргументов также обречена, поэтому, если мы можем сделать жизнь каждого немного легче, сделать цели WebAssembly более четкими и поработать над разрешением общего разногласия, я был бы очень признателен.

Гипотетическая крайняя позиция довольно интересна, так как я бы также сказал, что существуют устаревшие функции JS, о которых Wasm, возможно, не нужно беспокоиться заранее, или, возможно, вообще не нужно, но все же где-то есть черта, которую нужно провести. Моя интуиция подсказывает мне, что одна функция лучше, чем одна слишком мало, например, потому что совместимость очень важна. При наличии обязательства, возможно, будет, по крайней мере, более вероятно, что функция, представляющая интерес для меньшинства, может быть обсуждена с меньшими трениями и имеет больше шансов на успех для достижения более высокой цели?

Различие между основным языком и более широкой экосистемой также интересно. Я бы сказал, что если мы можем, мы должны попытаться избежать будущих проблем экосистемы и несовместимости, и должны больше говорить о том, чтобы избежать фрагментации между Wasm в Интернете и Wasm вне Интернета, например, что кажется тема практически не существует на сегодняшний день. Например, в экосистеме Node.js оказалось, что все пользовательские API, придуманные для Non-Web, изначально были крутыми, но сегодня также являются обузой, поскольку придерживаться (повторное использование) Web API, как правило, предпочтительнее обязательного полифилла. Deno, вторая попытка Node.js, так сказать, осознала это, но более широкая экосистема теперь застряла на этом надолго.

Я не знаю, сколько стоило бы избегать дублирования усилий. Полезно иметь его в качестве опции, если он не ведет по пути фрагментации, которого в противном случае можно было бы избежать? Например, WASI — это квазистандарт под эгидой WebAssembly, который теперь проникает в Wasm в Интернете, и чем больше он совершенствуется, тем сложнее будет исправлять проблемы экосистемы, которые мы обнаруживаем в процессе, поэтому механизм предотвращения таких результат, пока не стало слишком поздно, кажется полезным.

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

Помимо веба и не-веб, в дизайне Wasm до сих пор большое внимание уделялось внедрению в сеть более широкого набора языков, которые часто представляют собой языки, которые почти намеренно сильно отличаются от JS, поскольку они наиболее дополняют существующие возможности JS. , что делает комбинацию JS+Wasm наиболее мощной. Это также позволяет перенести в Интернет большую часть существующего программного обеспечения и позволяет сети выйти на новый уровень производительности. Если бы вместо этого Wasm был разработан для поддержки языков, очень похожих на JS, это было бы совершенно бессмысленно.

Это хорошо, но естественно означает, что эти языки могут сильно различаться, когда речь заходит о деталях реализации таких вещей, как управление памятью, строки и т. д., и их потребности следует принимать во внимание, тем более что весь смысл использования этих языков заключается в том, чтобы позволяют им быть эффективными в этом новом контексте. Когда дело доходит до взаимодействия на границе, необходимо учитывать не только взаимодействие с JS, но и взаимодействие между несколькими языками Wasm, а в будущем взаимодействие между этими языками и собственным кодом браузеров и других хостов Wasm, что часто являются одними и теми же или похожими языками. Такие предложения, как типы интерфейсов, пытаются сбалансировать все эти требования, а не только одно из них.

Я считаю, что в игре есть еще одно недоразумение, о котором, возможно, стоит поговорить. Я действительно выступал за то, чтобы рассмотреть потребности моего проекта, особенно поначалу, поскольку я надеялся, что его несколько уникальная перспектива (я считаю, что некоторые из сегодняшних проблем AssemblyScript являются канарейкой для завтрашних проблем WebAssembly) будет ценна для CG, но в последнее время и особенно сегодня я выступаю не за какой-то конкретный язык, а за более высокую цель совместимости в Сети, в то же время, надеюсь, с пользой использовать возможность разрешить разногласия в группе. Как и вы, я твердо верю, что Wasm не должен отдавать предпочтение какому-то конкретному языку, и я боюсь, что мы упускаем из виду гораздо более важные аспекты, такие как совместимость между веб-стандартами, а не споры за или против конкретных языков, что приводит к дискуссиям, которые, скорее всего, становятся слишком горячими, чтобы быть конструктивными, что, в свою очередь, тормозит эволюцию WebAssembly. Чтобы привести пример, я слегка обижен тем, как вы сформулировали свой комментарий, поскольку я чувствую, что он подразумевает довольно много вещей, которые могут быть в моей повестке дня, но не являются, в то время как я на самом деле согласен с вашими более высокими пунктами не в пользу определенного языка, дополняя существующие возможности JS, уравновешивая все требования, при необходимости идя на компромиссы и работая над достижением новых уровней производительности, пока это не приведет к веб-стандарту, который больше не является веб-стандартом, что было бы очень жаль.

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

Во-вторых, я согласен с тем, что совместимость с JS важна для успеха Core WebAssembly. Это включает такие предложения, как GC и EH, которые еще не полностью конкретизировали JS API, но сделают это до того, как они будут стандартизированы. Существует также подгруппа стека, которая рассматривает JS-взаимодействие в качестве своей основной задачи. Я бы также включил в это заявление другие предложения, такие как ИТ, которые наслоены, возможно, с помощью отдельных спецификаций, поверх Core WebAssembly, но по-прежнему предназначены для интеграции в веб-платформу.

Я действительно думаю, что исчисление отличается для не-веб-потребителей спецификации Core WebAssembly в целом и WASI в частности. Я не думаю, что CG должна (или может) пытаться навязать какой-либо контроль над тем, как Core WebAssembly используется или встраивается за пределы веб-платформы, и поскольку подгруппа WASI в настоящее время не предлагает каких-либо изменений в веб-платформе, я не думаю, имеет смысл обременять его обязательствами веб-совместимости. Учтите, что подгруппа WASI всегда могла бы выполнять ту же работу с теми же целями в какой-нибудь другой организации по стандартизации, но мы все гораздо лучше с точки зрения сотрудничества, перекрестного опыления идей и организационных накладных расходов (не говоря уже о совместимости! ), потому что это подгруппа CG.

Говоря об исчислении, здесь также может быть интересен гипотетический экстремальный сценарий «что, если подгруппа действует со злым умыслом, чтобы повлиять на ядро ​​WebAssembly / обойти его более высокие цели». подгруппой является WASI, но я все же хотел бы повысить осведомленность о том, что, например, включение или исключение функций типов интерфейсов, которое является основным предложением, эффективно управляемым той же группой, может так легко расставить приоритеты потребностям WASI, фактически не -Веб-подгруппа определенного языка, над потребностями других. С моей точки зрения в качестве OP, я, возможно, уже был свидетелем последнего, поэтому я бы сказал, что просто опасаться риска и принимать меры предосторожности не обязательно плохо, особенно когда усилия подгруппы в противном случае согласованы с интересы большинства, побочные эффекты может быть трудно осознать до того, как будет нанесен ущерб ядру WebAssembly, более широкой экосистеме или, что еще хуже, веб-стандарту. Или, другими словами: я думаю, что быть подгруппой под зонтиком WebAssembly должно подразумевать ответственность за ядро ​​WebAssembly и его более высокие цели.

Я думаю, было бы хорошо быть немного более консервативным в приписывании злого умысла различным группам, даже гипотетически ;)

Многие из этих спорных вопросов, особенно в предложении по ИТ, за которым внимательно следят немногие, затрагивают и видят лишь горстку людей. По важным вопросам дизайна трудно прийти к решению, против которого было бы большинство CG, потому что более или менее репрезентативное подмножество CG участвует в процессе проектирования или, по крайней мере, следует за ним без возражений. Тем не менее, для нишевых вопросов можно достичь решения среди нескольких человек, с которым полная компьютерная графика была бы неудобна. В этих случаях может быть полезно поднять конкретный вопрос на собрании CG, чтобы получить полное представление о предложенном направлении.

Одним из недавних примеров этого было, когда @lukewagner поднял вопрос о запрете дублирующегося импорта. Как вы поняли, CG не совсем устраивало направление, выбранное людьми, связывающими модули, и в результате в этом обсуждении было более широкое участие, и консенсус сместился в другом направлении.

В конечном итоге предложения, которые не устроят CG, не будут выдвинуты CG. Конечно, чем раньше будут подняты и обсуждены вопросы, тем лучше. Я надеюсь, что каждый чувствует себя вправе поднимать вопросы на собраниях CG по мере их выявления.

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

Мне было предложено обсудить следующие опасения относительно общего направления WebAssembly перед форумом уровня компьютерной графики, совету, которому я сейчас следую в надежде, что мы, как сообщество, сможем решить их навсегда.

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

С моей точки зрения, разногласия проистекают из ожиданий, вызванных первоначальной и до сих пор рекламой WebAssembly как части Открытой веб-платформы (ниже я буду сокращать до «Интернета»). Например, много раз говорилось, что Wasm не предназначен для замены (или вреда) JavaScript, а является скорее сопутствующей технологией, поэтому я всегда считал приоритетом достижение превосходной совместимости (для меня это также означает: интероперабельность ) с существующим Интернетом, что обычно является желательной целью в Интернете. Или, как утверждает webassembly.org:

К сожалению, в ходе всех этих жарких дискуссий у меня сложилось впечатление, что мое понимание целей WebAssembly не совпадает с тем, над чем работают мои более влиятельные противники внутри CG, что я не могу не рассматривать как попытки создать новый статус quo, который в значительной степени учитывает совместимость с Интернетом. Первая проблема, в которой проявилось это разногласие, — это пары STRING i32 для UTF-16LE в типах интерфейсов (в 2017 году, во время создания под названием Host Bindings), где после 1,5 лет молчания был обменялся многими аргументами о том, является ли UTF -8, строковая кодировка, в значительной степени несовместимая с веб-API и JavaScript, на самом деле должна быть единственной поддерживаемой кодировкой, или было бы полезно также учитывать совместимость с самого начала. В моей книге это должно быть само собой разумеющимся, поэтому я был очень удивлен чистой цепочкой противоположных аргументов, которые, в свою очередь, разжигали разногласия. Проблема в конечном итоге (в основном) была решена с признанием того, что существует так много языков, использующих кодировку строк, подобную JavaScript, что мы должны ее поддерживать, что, в свою очередь, привело к тщательной концепции слияния адаптеров, но почти никогда не признавалась эта совместимость с В частности, важны веб-API. Конечно, есть и другие нетехнические моменты, о которых стоит поговорить в контексте этой проблемы, но я предлагаю пока избегать их и сосредоточиться на направлении WebAssembly.

Еще одна похожая проблема — история GC для строк? на предложении GC, которое до сих пор не достигло решения, и, вероятно, это не обязательно, если целью является MVP, с которым мы все можем согласиться. Тем не менее, обсуждение до сих пор также указывало на то, что есть разногласия, которые нам придется разрешить в конечном итоге, то есть как только GC может использоваться таким образом, который требует взаимодействия между WebAssembly и веб-API, включая строки, возможно, также включая произвольный граф модулей, так что в идеале с минимальными преобразованиями и копированием. Общее разногласие также проявляется в последующем вопросе относительно лучшей истории GC для массивов? , который быстро отвлекся, чтобы поставить под сомнение мои способности и ценность проекта, над которым я работаю, вместо того, чтобы обсудить насущную проблему, которую я сегодня рассматриваю скорее как досадное следствие давнего недопонимания. Во всяком случае, это подчеркивает, что здесь есть возможность снова прийти к единому мнению.

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

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

Точно так же я недавно задался вопросом, может ли WASI навредить вариантам использования Wasm в Интернете? , как мне кажется, это устанавливает новый статус-кво в качестве побочного эффекта до того, как часть сообщества, более ориентированная на Интернет, получит возможность найти решение, которое способствует совместимости с Интернетом, а не фрагментации, из-за связанных предложений не за горами. достаточно. Лично я считаю расставленные там приоритеты проблематичными по причинам, затронутым в этом вопросе. И по совпадению, усилия в WASI продвигаются вперед членами CG, ранее спорившими с моими точками зрения по типам интерфейсов, и хотя корреляция не обязательно подразумевает причинно-следственную связь, в конечном итоге это заставило меня усомниться в общем направлении WebAssembly, вернув нас к этой проблеме.

Принципы проектирования WASI, которые, я уверен, вы уже хорошо изучили, прямо заявляют, что они не ограничиваются API-интерфейсами, которые легко полифилить в Интернете, а также прямо заявляют, что WASI должен работать с веб-стандартами, где это возможно. . Как ранее указывал @conrad-watt, существует различие между базовым языком и экосистемой, и это пространство имен, которое хосты могут просто не предоставлять. WASI как экосистема имеет разные цели проектирования, и принуждение веб-совместимости к одной из их целей кажется непродуктивным для проблем, которые WASI пытается решить.

Как уже должно быть очевидно, я очень обеспокоен тем, что мы, как сообщество, не делаем того, что необходимо для обеспечения превосходной совместимости с Интернетом, и в то же время терпимо относимся к новым предложениям и связанным с ними технологиям, которые нарушают совместимость с Интернетом. слишком много или иным образом прямо или косвенно воздействуют на него негативно. Это заставило меня задуматься, например, не должен ли Wasm или, по крайней мере, его будущая версия быть рекомендацией W3C, поскольку он ставит под угрозу обратную совместимость по одной существенной части за раз, что, безусловно, является крайним выводом, но было бы Я думаю, что последний вопрос, который мы должны задать, когда уровень разногласий возрастет еще больше.

Сообщество состоит из нескольких человек, которые работали над веб-стандартами или активно инвестировали в Интернет. Хотя я слышу ваши опасения, я не уверен, что будущее столь же ужасно. Можете ли вы добавить конкретные примеры, когда обратная совместимость уже была серьезно нарушена?

На этом фоне я сегодня обращаюсь к CG с просьбой обсудить следующее дополнение к общим целям WebAssembly, чтобы, надеюсь, уменьшить ненужные трения в будущем:

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

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

Что это может означать:

• Типы интерфейсов - это хорошо, но кодирование строк JS важно из-за совместимости, и продвижение UTF-8 поверх него для обеспечения мягкого давления или аналогичного, или оправдание его предполагаемыми тенденциями может быть проблематичным.
• Потоки, SIMD, i31ref и т. д. — все в порядке, поскольку они не связаны между собой и только добавляют функциональность, если только они больше не связаны.
• GC в порядке, но в конечном итоге будет мотивировано найти подходящее решение для обеспечения совместимости.
• WASI в порядке, но было бы мотивировано рассмотреть альтернативы тому, что в настоящее время по сути является libc, прежде чем идти дальше по маршруту фрагментации.
• WASI-nn подходит, но будет мотивирован на сотрудничество, например, с Machine Learning for the Web CG.

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

Дайте мне знать о ваших мыслях, спасибо! :)

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

@tlively Кажется, я задел нерв в своем предыдущем комментарии. Однако, пожалуйста, потерпите немного, так как я верю, что полное обдумывание этого может быть ценным, когда целью является предотвращение плохих результатов или снижение напряженности в будущем. Например, еще одним, более тонким гипотетическим экстремальным сценарием может быть «что, если субъект, также ответственный за основные предложения, задержит их продвижение, чтобы дать результатам подгруппы с другими целями время для процветания в более широкой экосистеме — хотя мы не можем предотвратить это, не могли бы мы хочешь отговорить?». Я думал об этом какое-то время, но хочу подчеркнуть, что все это гипотетически, и упоминание об этом служит высшей цели. Я просто не хочу ослаблять свое предложение в ОП, удерживая аспект, который, возможно, может иметь отношение к пониманию моего мыслительного процесса, ведущего к нему. Я думаю, что это может быть еще одной дилеммой, и я изо всех сил стараюсь быть настолько уважительным, насколько могу. Например, я удалил свой предыдущий ответ, который гласил: «Спасибо, что указали на это и оказали такую ​​поддержку, мои извинения», потому что я не был уверен в том, что сдерживаю то, что имел в виду, после рассмотрения того, что нам может не хватать для обсуждения. . Я надеюсь, что все в порядке, учитывая то, что, по моему мнению, поставлено на карту?

@dtig Большое спасибо за ваш подробный ответ. Прочитав ее, я стал более уверен в будущем WebAssembly, а также в том, что мой опыт пока не так репрезентативен для компьютерной графики в целом, как я изначально думал. Примеры, которые я могу привести, в основном основаны на обсуждениях отдельных вопросов, которые я связал в ОП, а не столько на деятельности компьютерной графики в целом, как я теперь понимаю. То, что «WASI должен работать с веб-стандартами, где это возможно», также является аспектом, с которым я полностью согласен и, возможно, неправильно понят, потому что мне кажется, что в следующем предложении «там, где это не является существенным», оно кажется относительным, поскольку JavaScript, который является context, является таким веб-стандартом и пока не соответствует моему опыту в связанных вопросах в WASI (см. https://github.com/WebAssembly/WASI/issues/402, где результатом является интерфейс, похожий на системный журнал). Мне придется немного переосмыслить последствия здесь, если это нормально, но я заинтересован в обсуждении этого вопроса, и затем, вероятно, буду отстаивать точку зрения более высокого уровня, что принципы проектирования WASI не должны быть не подлежащими обсуждению, как мне показалось. далеко, поскольку WASI, находящаяся под зонтиком WebAssembly, не только дает ему свободу создавать новые API, но также подразумевает ответственность из-за потенциальных косвенных эффектов (о которых я хотел бы повысить осведомленность) на основной WebAssembly.

Я думаю, что WASI не очень хороший дизайн. Во-первых, веб-сборка, предназначенная для виртуальной веб-машины, и разработка некоторых API для совместимости с posix не соответствует направлению разработки. Во-вторых, лучший способ внедрить сторонние API — это определить интерфейсы (взаимодействие между двумя доменами), чтобы можно было контролировать количество API и безопасность.

другим, более тонким гипотетическим экстремальным сценарием может быть «что, если субъект, также ответственный за основные предложения, задержит их продвижение, чтобы дать результатам подгруппы с другими целями время для процветания в более широкой экосистеме — хотя мы не можем предотвратить это, хотим ли мы препятствовать этому?» Это?"

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

@penzn К сожалению, нас бы здесь не было, если бы процесс был идеальным. В качестве примера мы можем рассмотреть мое несогласие с принципами проектирования WASI. Я не знаю, как подходить к ним должным образом, поскольку WASI в значительной степени независима по своему замыслу, что современное большинство, которому она служит, считает хорошей вещью, поэтому проблемы в более широком плане могут быть подняты только в самой WASI, но тогда у меня сложилось впечатление, что поднятие проблем с WASI в WASI вряд ли приведет к разрешению, потому что большинство в WASI, естественно, хотят, чтобы WASI оставалась такой, какая она есть, и это понятно. Например, меня отправили обратно в Interface Types, хотя это та же самая группа, и они знают о проблемах, через которые я там прошел, и чаще всего то, что я указываю, является «несовместимым с принципами проектирования WASI» и это все. Поэтому я попытался определить проблему более высокого уровня, которая, по моему мнению, сводится к тому, что WASI узаконен, чтобы едва соответствовать основным целям WebAssembly, и в то же время не нести ответственности за основные цели WebAssembly. Поэтому я предлагаю адаптировать процесс, потому что я либо не могу его использовать, либо не чувствую себя в силах это делать.

См. обсуждение безопасности C API на собрании CG 28 апреля 2021 г. Это была аналогичная ситуация, когда проблемы докладчика не были решены в рамках предложения. Конечно, в случае с WASI разница в том, что это не предложение, но CG все же должна иметь процессуальные полномочия. В случае безопасности C API были подняты конкретные проблемы, которые сторонник предложения должен был принять после того, как CG встал на сторону несогласного, однако я считаю, что вы также можете представить без голосования в конце.

Извините, но я не понимаю, как «Безопасность C API» можно сравнить с более широкими проблемами. Можете ли вы уточнить? Например, я чувствую, что моя презентация в поддержку Интернета на WASI только еще больше разожжет разногласия. Как сказал @dtig , это «кажется непродуктивным для проблем, которые WASI пытается решить».

В дебатах о безопасности C API также возникло разногласие на высоком уровне по поводу целей и потребностей (необходимы ли проверки API для небезопасного языка), которые разрешились в ходе обсуждения CG. Это открытый стандарт — внесение предложений и обсуждение — единственные инструменты, которые у нас есть, чтобы изменить его.

Некоторые мысли по поводу экосистемы: я согласен с тем, что фрагментация между веб-интерфейсом и серверным API представляет собой риск. С добавлением WASI у нас теперь есть два набора стандартизированных API для Wasm, и без очевидного пути к унификации, поскольку я лично скептически отношусь к тому, что браузеры примут WASI, и, учитывая существование WASI, обратное тоже маловероятно.

Для Интернета было бы лучше, если бы WASI сосредоточился на переносе веб-API на сервер. Но это не значит, что для Wasm в целом было бы лучше. Я ценю сравнение с Node.js и историю API, но я думаю, что это идет в обе стороны: да, для Node.js было бы хорошо использовать больше веб-API, но, возможно, огромный успех Node.js отчасти объясняется добавление необходимых им API независимо от Интернета. Возможно, WASI необходим для того, чтобы Wasm успешно работал на сервере — учитывая, насколько различаются веб-экосистемы и серверные экосистемы, возможно, фрагментация API неизбежна.

Это одна из причин, почему я лично не критиковал WASI, когда она начиналась. Хотя с точки зрения Интернета это не оптимально, это все же может быть необходимо для успеха Wasm на сервере, что может быть хорошо для успеха Wasm в целом. (Вторая причина заключается в том, что модель безопасности WASI интересна и может помочь Wasm процветать.)

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

Я думаю, что единственным исключением из этого должна быть действительно серьезная опасность фрагментации или чего-то еще. Я не вижу такой опасности в настоящее время. Хотя наличие двух стандартных API делает некоторые вещи неудобными и менее оптимальными, мы уже можем полифиллировать server -> Web, и в конечном итоге мы также сможем сделать Web -> server, что поможет. Для таких проблем, как строки, я рассматриваю предварительный импорт как возможность оптимального использования строк в Интернете, что также сделает фрагментацию API в Wasm более очевидной, но в этом случае она уже существует из-за непреодолимых языковых различий. В целом риски реальны и досадны, но они кажутся управляемыми и неизбежными.

Хорошие мысли, @kripken , они примерно соответствуют моему пониманию альтернативы.

Что касается сравнения Node.js, я, в частности, имел в виду такие вещи, как Buffer vs Uint8Array , которые по-прежнему ответственны за большое количество (медленных) полифиллов в Интернете. Или предотвратимая проверка global против window в любом другом портативном модуле. Или TextDecoder временно не является глобальным, чтобы сократить время запуска. Или crypto.getRandomValues по-прежнему недоступны во всем мире. Или все подводные камни с поддержкой ESM до сегодняшнего дня. Я бы сказал, что Node.js мог бы работать лучше в некоторых местах, в то время как поддержка fs и т. д., вероятно, была неизбежной.

В WASI ситуация похожая, в том смысле, что нам, скорее всего, понадобится файловая система WASI, но есть и другие API, обеспечивающие функциональность, общую для всех экосистем, API, необходимые в первую очередь для создания переносимого базового модуля, где, я думаю, мы можем добиться большего успеха, чем то, к чему мы сейчас движемся. Представьте, например, модуль, который пишет в консоль, когда что-то идет не так, получает текущее время и т. д., где зависимость от (полного) полифилла WASI кажется излишней. Я предполагаю, что некоторым модулям по-прежнему потребуется сопутствующий полифилл для (просто) файловой системы WASI в Интернете, и я думаю, что это действительно управляемо. Я просто не думаю, что мы находимся здесь в ситуации «все или ничего», но есть много возможностей для сотрудничества, которое в конечном итоге окупится за «кроме принципов дизайна». Мой аргумент таков: если мы можем, мы, вероятно, должны, и если нам нужно немного адаптировать процесс для этого, то мы также должны это сделать.

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

Возможно, несколько уместный в контексте отрывок из последнего сообщения в блоге Deno с почетным упоминанием фрагментации на стороне сервера и ценностью соблюдения API-интерфейсов браузера:

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

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

Это, конечно, не совсем то же самое, но все же есть чему поучиться на уроках, которые они усвоили.

Определенно актуальная статья, да. Еще одна ключевая цитата из него:

Мы думаем, что многие разработчики предпочитают веб-слои абстракции.

Еще одна причина, по которой полифиллинг Web -> server (как упоминалось ранее) будет важен.

Дополнительное примечание: я набросал строительный блок для решения части проблем, которые я вижу с WASI и фрагментацией на существенном уровне, названный System Essentials for WebAssembly , но хотел бы, чтобы вы думали о том, звучит ли что-то вроде этого хорошо, прежде чем предложить что-нибудь (не стесняйтесь открывать вопрос там). Если кто-то, как и я, видит в этом ценность (или даже хочет стать со-защитником/предоставить руководство), дайте мне знать. Если нет, меня бы заинтересовали альтернативные идеи, которые дали бы сопоставимый эффект :)

При беглом просмотре вашего документа список «основного» полностью состоит из системных _возможностей_. Предоставление их по умолчанию означало бы наличие внешних возможностей и тем самым подорвало бы модель песочницы, которую Wasm тщательно разработал для создания.

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

Предоставление их по умолчанию подразумевало бы наличие внешних возможностей

Как наличие памяти, наверное. Вроде не такой уж и другой.

и тем самым подорвать тщательно разработанную модель песочницы.

Я думаю, только если память или недетерминизм на другом оборудовании (FP, ослабленный SIMD) тоже. Я не собирался и не думаю, что документ «подрывает» «тщательный дизайн» Васма.

ни одна из возможностей в этом списке не может быть общедоступной

Бинарный файл Wasm запускается на какой-то машине с какой-то ВМ на какой-то ОС, так что я бы здесь не согласился. Я думаю, что разумно ожидать, что они будут общедоступными, даже если в особых случаях их использование может быть ограничено.

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

Например, блокчейны. На сегодняшний день они обычно запрещают математику с плавающей запятой и могут аналогичным образом запрещать получение времени или принимать решение об удалении сообщений журнала, но узлы по-прежнему работают на некоторых виртуальных машинах в некоторых ОС. Я бы также сказал, что это зависит от конкретного случая использования леджера, поэтому очень вероятны случаи использования, когда ограничения не нужны. Я не думаю, что Wasm может решить эту проблему в чистом виде. Другой крайностью являются устройства IOT с менее чем одной страницей памяти, с различными последствиями.

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

В любом случае, может быть лучше перенести это обсуждение в репозиторий моего документа, или в Discord, или по электронной почте, или в голосовом чате. Так что, пожалуйста, сделайте (или свяжитесь со мной, где это работает лучше всего), если это тоже ваше впечатление :)

Я действительно думаю, что есть смысл в том, чтобы спецификация WebAssembly Core не предполагала ничего о своей среде выполнения, в том числе о том, что существует ОС или окружающие концепции времени или ведения журнала. Для всего, что зависит от состояния или изменяет его за пределами формальной семантики Wasm, спецификация Core выделяет импортированные функции в качестве универсального аварийного люка, но, конечно, не указывает, что какой-либо конкретный набор импортируемых данных будет предоставлен.

В целом, я считаю, что борьба с фрагментацией на столь существенном уровне ценна.

Я думаю, что это суть разногласий в этой теме. Лично я твердо убежден, что для спецификации Core Wasm не должно быть целью предоставить единую экосистему, но она должна попытаться предоставить как можно более переносимую (и производительную) абстракцию для чистых вычислений. В качестве аналогии ни X86, ни ARM не пытаются предоставить унифицированные экосистемы (или даже унифицированные ABI); это остается на уровне абстракции ОС, находящемся над ними, и я думаю, что эта модель также подходит для WebAssembly.

При этом избегание фрагментации экосистемы, где это возможно, безусловно, полезно, но я думаю, что это должно быть сделано на уровне выше Core Wasm. Явным кандидатом на этот уровень унификации экосистемы является WASI. Будет ли это работать, если основные возможности, которые вы определили, будут предоставлены модулем WASI, специально разработанным для работы с минимальными затратами как в Интернете, так и за его пределами? В чем нынешние средства WASI для времени и случайности терпят неудачу?

Возможно, это то, что нужно: стандартизированный набор _необязательных_ импортов; доступны в Интернете, в большинстве систем WASI (поскольку они являются необязательными, а WASI может работать, например, в ограниченной встроенной среде) и в любых местах, которые могут _факультативно_ обеспечивать стандартный импорт.

В Интернете это было бы _как если бы_ JS-код передал их, но нет, система передала их, и JS-разработчик либо ничего не должен был делать, либо просто должен был перечислить их по имени, чтобы выбрать, какие из них доступны.

Веб-разработчики могут считать само собой разумеющимся, что определенный импорт существует (или выбран на стороне JS), хотя это не обязывает сам Wasm иметь его в языке.

Например, блокчейн env может не предоставлять (необязательный) импорт.

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

Это означало бы, что переключателям компилятора не нужно выводить разные вызовы API.

WASI будет двумя вещами: поставщиком стандартного импорта и поставщиком специализированного импорта только для сервера.

Я думаю, что проблема обеспечения стандартного импорта в Интернете без использования JS — это немного другая проблема (но @dcodeIO , дайте мне знать, если вы не согласны). Даже при наличии стандартного набора импортов для использования в Интернете и за его пределами текущий JS API по-прежнему потребует написания JS для компиляции и создания экземпляра модуля, поэтому предельная выгода для веб-разработчиков от того, что некоторые импорты будут неявными, будет небольшой. При наличии стандартного набора импортов может иметь смысл их неявное предоставление чем-то вроде предложения по интеграции ESM, но проблема здесь в том, что у нас пока нет такого стандартного набора импортов.

@dcodeIO

Я думаю, что идея System Essentials интересна, но я не согласен с новым стандартом для них. В идеале они могли бы пойти в WASI (как сказал @tlively ) или быть веб-API.

О веб-API: Справедливое замечание в ссылке о получении часового пояса, требующего нового объекта Date. Это громоздко в wasm. Но это возможно с JS Reflect API (в частности, Reflect.construct ). Мы могли бы добавить больше таких API на стороне JS или Wasm JS API по мере необходимости. Импорт по-прежнему нужно будет декларировать, но затраты на размер кода должны быть минимальными.

Что касается API WASI, я твердо убежден, что нам нужно сделать больше, чтобы преодолеть разрыв между Web и WASI. Добавление дополнительных веб-интерфейсов API в WASI лично для меня имеет смысл — возможно, аналогично System Essentials. В прошлом месяце я описал еще одно возможное направление и предложил набросать конкретные детали , если будет интерес, но пока не получил ответа от людей из WASI. Обратная связь будет очень кстати!

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

Вот откуда берется моя несколько отсутствующая идея инструкций «System Essentials», в основном основанная на моем наблюдении, что добавление пространства имен импорта, вероятно, не произойдет в браузерах по причинам, упомянутым ранее, поэтому я интуитивно предполагал, что, возможно, инструкции могут на самом деле быть менее проблематичным, хотя есть веские аргументы против. Я согласен с вашим мнением о сохранении ядра Wasm «основным» и надеюсь, что мы можем сделать что-то лучшее поверх ядра Wasm, которое работает как для Web, так и для WASI.

Таким образом, я не особенно привязан к своей конкретной идее и был бы рад всему, что ставит галочку напротив [x] устраняет связующий код , будь то с помощью инструкций, общего пространства имен импорта в Интернете и за его пределами (WASI или нет). , или косвенно через интеграцию ESM и поддержку его части за пределами Интернета, так что мы в конечном итоге достигаем [x] меньшей фрагментации (один и тот же модуль работает как в Интернете, так и вне Интернета без полифилла, когда используется только общая функциональность; проводя линию в файловой системе и DOM , которые скорее зависят от среды). Имеет ли это смысл? :)

Еще одна мысль: возможно, наш разговор может быть полезен для информирования идеи о подъязыках - скажем, «профиль» для «веб + васи» или что-то в этом роде? Затем это может сводиться к стандартизации пересечения между подъязыковыми поверхностями API.

Кроме того, поскольку этот вопрос открыт уже почти месяц, и, к сожалению, вряд ли кто-то из специалистов по ИТ/WASI вмешается, чтобы улучшить ситуацию, я решил попробовать себя в анализе конфликтов.

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

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

• Браузер: обслуживание веб-платформы, которая довольно богата по своей природе. Так сказать, «новая десктопная ОС».
• Сервер: Относительно простой по своей природе, как в «принеси свои вещи». Нейтральный.
• Исследование: Хочет сделать Васм хорошим для всех, кроме тех, кто привязан к другому актеру.
• Google: сосредоточился на переносе материалов в Интернет и ускорении их работы; Согласны ли вы с учетом потребностей других, если это не вредит их собственным?
• Dfinity: олл-ин на блокчейне; По-видимому, нуждается в некоторых функциях богатства; а чем больше баребонов тем лучше?
• Быстро: сфокусировано на крае; Бережливая/минимальная виртуальная машина имеет решающее значение для их продукта; Эффективно отвечает за IT/WASI?
• Apple: согласен с тем, что работает в Интернете; Не обязательно конкурировать с магазином приложений?
• AssemblyScript: хочет практической реализации в реальном мире; Склонен к Интернету, но несколько размыт из-за заинтересованных сторон в Edge/BC?
• Intel?: Пока не так много знаков; В основном заинтересованы в эффективных вычислениях?
• Redhat?: Пока не так много знаков; Больше всего интересует инфраструктура?
• Microsoft?: Пока не так много признаков; .NET в Интернете и, в конечном итоге, везде?
• Мозилла?: Не существует?

Хотя это, вероятно, неверно на многих уровнях, я обнаружил, что это относительно хорошо иллюстрирует мою ментальную модель. Я также подвел черту, согласно которой я считаю, что «Интернет в WebAssembly» вступает в игру, исходя из моих ожиданий, но это снова спорно. Во всяком случае, я надеюсь, что это поможет понять, откуда я пришел и почему у меня сложилось впечатление, что что-то не так в Стране Васмов, а также прольет некоторый свет на ситуацию для тех, кого интересует мой сжатый взгляд на проблему. но может не знать всех подробностей, которые произошли. Берите, но с недоверием :)

Два пенни... Я искренне удивлен, что этот разговор вообще состоялся. Для WebAssembly всегда было плохой идеей позволять определять свою область действия любыми вариантами использования, которые случайно придумали ранние последователи.

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

Если WebAssembly пойдет в направлении, которое не нравится криптомайнерам, они могут разветвить его или что-то в этом роде. Это не то, чем нам нужно заниматься при разработке веб-стандартов. Все остальные имеют полный контроль над базовой платформой. В Интернете у нас есть только та платформа, которую нам дали, и как только она становится стандартом, мы как бы застреваем с ней навсегда.

WASI следует разветвить, чтобы он занимался своими делами, а в Интернете должна быть своя собственная виртуальная машина, полностью оптимизированная для браузера, исключительно и конкретно.

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

Собственно, его объем определяется КУ, к которой может присоединиться кто угодно, в том числе и вы. Там люди голосуют за направление, на которое можно повлиять, если вы хотите потратить время на то, чтобы быть активным в нем, и представить хорошо продуманные технические аргументы.

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

Боюсь, что каждый, кто может присоединиться к CG, означает, что вы не можете запретить присоединяться людям с интересами, не связанными с Интернетом.

Я искренне удивлен, что этот разговор вообще состоялся. Для WebAssembly всегда было плохой идеей позволять определять свою область действия любыми вариантами использования, которые случайно придумали ранние последователи.
...
WASI следует разветвить, чтобы она занималась своими делами.

WASI занимается своими делами; это пространство имен импорта. Он не стандартизирован на том же уровне, что и функции языка WebAssembly. Является ли предложение объявить не-веб-функции вне сферы действия и не допускать, чтобы спецификация WASI происходила под номинальным зонтиком группы сообщества? Что бы это дало с точки зрения предотвращения фрагментации?

Есть смысл исследовать, можно ли настроить определенные части WASI, чтобы сделать их более аккуратными (как Web-> WASI, так и WASI-> Web, как @kripken изложено здесь ), но даже в самом худшем случае мы просто получаем API, который нельзя импортировать в Интернет, точно так же, как если бы WASI был завершен как сторонний проект для среды выполнения, отличной от Интернета.

Опять же, читая проблемы, связанные с @dcodeIO , я не вижу никого, кто думает, что Интернет не важен для WebAssembly. Все, что я вижу, это люди, не согласные (иногда неприлично) по поводу функций/дорожных карт для решения довольно специфических проблем взаимодействия, таких как кодирование строк. Я твердо убежден, что было бы ошибкой характеризовать эти технические разногласия как свидетельство борьбы за власть между Интернетом и не-Интернетом, и что это не приведет ни к каким положительным результатам.

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

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

Я не считаю это борьбой за власть...

@7ombie извиняюсь, мой последний абзац был предназначен в первую очередь для комментариев к приведенной выше диаграмме «конфликта».

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

Я согласен с тем, что некоторые технические ожидания, связанные с типами интерфейсов, стали довольно эзотерическими. В CG, безусловно, есть место для таких разговоров, как «почему интерфейсные типы, а не первоклассные строковые типы», и мы полагаемся на веб-ориентированных разработчиков, таких как @dcodeIO , которые делятся своими мнениями и проблемами, чтобы процесс работал. Я был встревожен тем, как закончился последний разговор по этому поводу, и я надеюсь, что в будущем мы сможем добиться большего.

Понятно, @conrad-watt. Я не видел этого разговора, но, со своей стороны, я не хочу играть в Web Vs. невеб-мышление или что-то в этом роде. Я просто делюсь личными претензиями к технологии, которой я, как правило, очень доволен, взволнован и благодарен.

Мои предыдущие комментарии были довольно критическими и вопиющими, но я был просто случайным. Я не расстроен.

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

Я хотел бы подчеркнуть, что я также вижу ценность в сотрудничестве (с WASI и другими) настолько, насколько это возможно, поэтому я предложил исследовать решения, которые приводят к переносимости между экосистемами таким образом, чтобы были покрыты пересечения, в том числе там, где я в настоящее время рисует линию (DOM, файловая система). Я понимаю, что то, что я предлагаю, может быть трудным, или что могут быть лучшие способы добиться чего-то сопоставимого (дайте мне знать! :)). Это просто (цитирую себя в ОП)

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

побудил меня предложить каким- то образом переоценить наши цели, дав понять, что

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

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

@dcodeIO , какой возможный пункт обсуждения в вашем анализе конфликтов, все ли перечисленные вами компании должны раскрывать и сравнивать свои планы? Как вы думаете, возможно ли это и что это даст?

Хотя я не могу комментировать ни одну из компаний в вашей таблице, я думаю, что сравнение их таким образом вводит в заблуждение, поскольку ни одна организация не может изменить стандарт для себя без согласия других. Я также нахожу ось диаграммы субъективной и запутанной. Например, выполнение вычислений (скажем, рендеринга или NN) в wasm в Интернете должно быть «периферийным», поскольку оно перемещает вычисления из «облака», но тогда оно также должно быть «сетевым», поскольку это важная часть. интерактивной сети (и определенно не «серверной», так как она работает на клиентской машине). Другое измерение еще более субъективно, IMO, поскольку чистота и богатство в вашем определении являются относительными терминами. Пример. Существует очень долгая дискуссия об ограничениях потока управления, мотивированных соглашениями о вызовах Go. В зависимости от того, кого вы спросите, эти ограничения будут рассматриваться как полезная функция или ненужная, что, я думаю, повлияет на то, где этот человек поместит обсуждение по оси «богатые против чистых».

Чтобы задать прямой вопрос, определяется ли долгосрочное направление WebAssembly тем, кто его примет? Например, если в долгосрочной перспективе внедрение веб-разработчиками было низким, но были крупные промышленные игроки, инвестировавшие миллиарды в использование WebAssembly для чего-то, не связанного с Интернетом, стали бы их потребности в конечном итоге приоритетными?

Чтобы задать прямой вопрос, определяется ли долгосрочное направление WebAssembly тем, кто его примет? Например, если в долгосрочной перспективе внедрение веб-разработчиками было низким, но были крупные промышленные игроки, инвестировавшие миллиарды в использование WebAssembly для чего-то, не связанного с Интернетом, стали бы их потребности в конечном итоге приоритетными?

Мы являемся стандартом, основанным на сообществе/консенсусе. Нет особого смысла рассматривать эти гипотетические ситуации, потому что в принципе их нельзя защитить никакими формальными процедурами. Добро пожаловать в экзистенциальную тревогу сообщества/построения консенсуса.

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

Чтобы быть ясным, я абсолютно не верю, что это та ситуация, в которой мы находимся. Нужно либо верить, что интересы Интернета адекватно представлены членами CG, либо вмешиваться самому.

Видите ли, я что-то не понимаю. Очевидно, что цель состоит в том, чтобы в конце концов создать веб-стандарт под эгидой W3C, который имеет очень четкие принципы и ценности и большой опыт из долгой истории подобных проблем. Я не вижу, как лидеры Сети и все, у кого есть развилка, согласующаяся с тем, что придумали люди Сети, если они этого хотят, могут быть хуже. Так что да, я предлагаю сначала создать WebAssembly для Интернета, а затем для всего остального, поскольку обратная ситуация невыносима, если мой опыт до сих пор чего-то стоит. Чего бы это ни потребовало, мы должны рассмотреть и обсудить это, поскольку я думаю, что это основная причина проблемы.

Как я уже сказал выше, хотя я согласен с тем, что Интернет должен быть приоритетом для WebAssembly, я не верю, что технические разногласия, которые у вас возникли с другими членами CG, в первую очередь связаны с расколом фракций между Вебом и не-Вебом. . Есть причины, по которым даже люди, ориентированные исключительно на Сеть, захотят найти альтернативу нескольким вашим предложениям, и вы не должны интерпретировать это как свидетельство того, что людям, не согласным с вами, наплевать на Сеть.

WASI не будет спецификацией W3C и не мешает нам создавать спецификацию W3C WebAssembly. Заявление о том, что WASI не следует разрабатывать в рамках CG, потому что это «не-Web», не приведет к тому, что вовлеченные люди обратят свое внимание на Web. Это просто закроет ценные каналы связи и сотрудничества, которые могут (например) позволить нам найти совпадения с некоторыми гипотетическими веб-дружественными API.

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

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

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

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

Для начала я предложил презентацию о своих опасениях по поводу кодирования строк и о том, где я думаю, что это актуально для следующих шагов в типах интерфейсов, соответственно, для более поздней разработки компонентной модели. И в процессе мы в конечном итоге решили опробовать новый формат предварительно записанной презентации, время обсуждения которой было запланировано на видеоконференцию компьютерной графики 22 июня. Запись можно найти в сопроводительном выпуске, указанном прямо над этим комментарием, и я надеюсь, что она поможет предоставить необходимую предысторию в более сжатой и конструктивной форме.

Если бы я мог предложить беззаботное предложение: если бы кто-то перекомпилировал не-WASM-части исходного кода веб-браузера в Binaryen или Rust, ориентируясь на WASI на рабочем столе, было бы достаточно сказать, что большая часть браузера просто большой полифилл или он просто повернет аргумент внутрь себя, вызовет катастрофический коллапс и превратит Землю в черную дыру?

А если серьезно: IIRC, Интернет начинался как гиперссылка на документацию телефонного справочника сэра Тима Бернерса-Ли в ЦЕРН. Сеть сама по себе превзошла все ожидания, в том числе по сложности и потреблению памяти. Веб-браузер превратился из средства просмотра документов в полноценное средство публикации. Это особенность ползучести.

WASI, как среда программирования, может вернуть веб-технологии к их истокам как отрасли информатики, в которой объединяются публикации и интерактивность. С каких это пор чат должен работать в браузере, чтобы быть веб-технологией? IRC, оригинальный протокол чата, в любом случае существует дольше, чем веб-браузер. Точно так же SMTP предшествует WWW, как и FTP. Интернет больше, чем просто сеть, и именно таким он и должен был быть.