Design: O WebAssembly deve considerar a compatibilidade com a Open Web Platform extremamente importante?

Concordo amplamente com a declaração como está escrita, mas não acho que qualquer tipo de compromisso formal com ela teria evitado muitas das discordâncias às quais você vinculou. Em particular, sua declaração é formulada principalmente como uma barreira adicional à adoção de propostas, mas em muitas das questões vinculadas você está defendendo adições à linguagem central.

Pode ser um experimento de pensamento útil considerar a hipotética posição extrema "se um recurso ajuda a compatibilidade com a Web, devemos adicioná-lo ao Wasm", com o qual eu não concordaria porque acabaria inchando a linguagem com um monte de Ganchos específicos de JS. Não estou sugerindo que você defenda essa posição, mas acho que sua declaração, conforme escrita no OP, não captura as divergências conceituais que parecem surgir nas questões que você vinculou.

Há também uma distinção entre "WebAssembly" a linguagem principal (que eu sinto absolutamente que deve permanecer compatível com a "Plataforma Web Aberta") e o ecossistema de ferramentas, interfaces de host e namespaces de importação que se pode escolher para padronizar/engenharia em torno dele . É menos importante que o WASI permaneça "amigável à Web", porque é um namespace de importação que os hosts podem simplesmente optar por não fornecer. Na pior das hipóteses, isso causaria esforço duplicado/uma divisão da cadeia de ferramentas se alguém mais tarde padronizasse uma API mais amigável para a Web.

Sim, algumas dessas questões são um pouco antigas, e eu certamente as abordaria de maneira diferente hoje (ainda mais se tal compromisso existisse na época). Vou pensar um pouco sobre este e seus outros pontos :)

Fiquei um pouco surpreso com a impressão de que estou defendendo adições à linguagem central em muitas questões, então talvez seja bom dar algum contexto. Ocasionalmente, eu realmente elaborei uma alternativa de bolso (eu acho) onde parecia útil no contexto de uma discussão, o que pode ser visto como advogando por adições, eu acho, principalmente Universal Strings, onde tentei ajudar a resolver um impasse percebido entre Interface Tipos e GC que estavam apontando um para o outro para serem responsáveis ​​por minhas preocupações. Em retrospectiva, lamento trazer isso à tona novamente na questão de TI, pois o GC parece ser o local mais apropriado. Ele ainda pode ter explodido lá, então, não tenho certeza. No final das contas, nunca as propus, também dadas as tensões existentes, mas principalmente as criei pelo desejo de explicar o que quero dizer concretamente. Em retrospectiva, é um dilema em que estou me encontrando, já que propor qualquer coisa parece estar condenado de qualquer maneira devido à tensão, e trabalhar meus argumentos com mais detalhes também, então, se pudermos tornar a vida de todos um pouco mais fácil, tornando os objetivos do WebAssembly mais claros e trabalhando para resolver o desacordo geral, eu agradeceria muito.

A posição extrema hipotética é bastante interessante, pois eu também argumentaria que existem recursos JS herdados com os quais o Wasm pode não ter que se preocupar proativamente, ou talvez nem mesmo, mas ainda há uma linha a ser traçada em algum lugar. Minha intuição me diz que um recurso a mais é melhor do que um a menos, por exemplo, porque a compatibilidade é muito importante. Com o compromisso em vigor, talvez fosse pelo menos mais provável que uma característica de interesse de uma minoria pudesse ser discutida com menos atrito e tivesse mais chances de sucesso para atingir o objetivo maior?

A distinção entre a linguagem central e o ecossistema mais amplo é igualmente interessante. Eu diria que, se pudermos, devemos tentar evitar o caminho de futuros problemas e incompatibilidades do ecossistema, e devemos falar mais sobre como evitar a fragmentação entre Wasm na Web e Wasm fora da Web, por exemplo, o que parece ser um tópico em grande parte inexistente a partir de hoje. Por exemplo, no ecossistema Node.js, descobriu-se que todas as APIs personalizadas inventadas para não Web eram legais inicialmente, mas também são um fardo hoje, já que manter (reutilizar) APIs Web geralmente é preferível ao polyfilling obrigatório. Deno, a segunda tentativa no Node.js, por assim dizer, percebeu isso, mas o ecossistema mais amplo agora está preso a ele por um longo tempo.

Não sei quanto valeria a pena evitar o esforço duplicado. É útil tê-lo como uma opção, desde que não leve a um caminho de fragmentação que, de outra forma, seria evitável? Por exemplo, o WASI é um quase-padrão sob o guarda-chuva do WebAssembly que agora está se infiltrando no Wasm na Web, e quanto mais ele amadurecer, mais difícil será corrigir os problemas do ecossistema que descobrimos no processo, então um mecanismo para evitar tais um resultado antes que seja tarde demais parece útil.

Não podemos ter absolutos em nossos objetivos de design de que o Wasm deve ser ideal para um ecossistema ou caso de uso específico, porque fundamentalmente o Wasm atende a muitos ecossistemas, casos de uso e linguagens, que sempre exigirão algum nível de compromisso.

Além da web e não-web, o design do Wasm até agora colocou grande ênfase em trazer um conjunto mais amplo de linguagens para a web, que geralmente são linguagens quase de propósito muito diferentes do JS, pois complementam as habilidades existentes do JS da maneira mais , e assim torna a combinação de JS+Wasm a mais poderosa. Ele também permite que a maior quantidade de software existente seja trazida para a web e permite que a web alcance novos níveis de desempenho. Se, em vez disso, o Wasm tivesse sido projetado para favorecer linguagens muito semelhantes ao JS, teria sido bastante inútil.

Isso é uma coisa boa, mas naturalmente significa que essas linguagens podem ser bastante diferentes quando se trata de detalhes de implementação de coisas como gerenciamento de memória, strings, etc., e suas necessidades devem ser levadas em consideração, especialmente porque o objetivo de usar essas linguagens é permitir que sejam eficientes neste novo contexto. Quando se trata de interoperabilidade no limite, não apenas a interoperabilidade com JS precisa ser considerada, mas também a interoperabilidade entre várias linguagens Wasm e, no futuro, a interoperabilidade entre essas linguagens e o código nativo de navegadores e outros hosts Wasm, que muitas vezes são as mesmas linguagens ou linguagens semelhantes. Propostas como tipos de interface tentam equilibrar todos esses requisitos, não apenas um deles.

Eu acredito que há outro mal-entendido em jogo que pode ser bom para falar. De fato, tenho defendido considerar as necessidades do meu projeto, mais inicialmente porque esperava que sua perspectiva um tanto única (acredito que alguns dos problemas do AssemblyScript de hoje são um canário para os problemas do WebAssembly de amanhã) seria valioso para o CG, mas mais recentemente e especialmente hoje não estou defendendo uma linguagem em particular, mas o objetivo maior de compatibilidade na Web, enquanto espero fazer bom uso da oportunidade para resolver desacordos entre o grupo. Assim como você, acredito fortemente que o Wasm não deve favorecer um idioma específico, e temo que estejamos perdendo o controle de aspectos muito mais importantes, como a compatibilidade entre os padrões da Web, argumentando a favor ou contra idiomas específicos, levando a discussões que provavelmente tornar-se muito aquecido para ser construtivo, por sua vez, parando a evolução do WebAssembly. Para dar um exemplo, sinto-me um pouco ofendido pela forma como você formulou seu comentário, pois sinto que isso implica algumas coisas que podem estar na minha agenda, mas não estão, embora eu realmente concorde com seus pontos de nível mais alto de não favorecer um linguagem específica, complementando as habilidades existentes do JS, equilibrando todos os requisitos, fazendo concessões quando necessário e trabalhando para alcançar novos níveis de desempenho, desde que não leve a um padrão Web que não seja mais um padrão Web, o que seria muito infeliz.

Em primeiro lugar, quero dizer que vejo sua experiência de ter adversários no CG como um sinal de falha do processo. Não é um objetivo irracional trabalharmos de forma não adversarial, mesmo quando discordamos fortemente uns dos outros em detalhes técnicos ou prioridades.

Segundo, concordo que a interoperabilidade com JS é importante para o sucesso do Core WebAssembly. Isso inclui propostas como GC e EH, que ainda não desenvolveram totalmente as APIs JS, mas o farão antes de serem padronizadas. Há também o subgrupo de pilha, que está considerando a interoperabilidade JS como sua primeira questão de negócios. Eu também incluiria nessa declaração outras propostas, como TI, que são colocadas em camadas, possivelmente por meio de especificações separadas, no topo do Core WebAssembly, mas ainda destinadas a serem integradas à plataforma da Web.

Eu acho que o cálculo é diferente para consumidores não Web da especificação Core WebAssembly em geral e WASI em particular. Não acho que o CG deva (ou possa) tentar impor qualquer controle sobre como o Core WebAssembly é usado ou incorporado além da plataforma Web e, como o subgrupo WASI não está propondo nenhuma alteração na plataforma Web, não acho que faz sentido onerá-lo com obrigações de compatibilidade com a Web. Considere que o subgrupo WASI pode sempre realizar o mesmo trabalho com os mesmos objetivos em alguma outra organização de padrões, mas estamos todos muito melhores em termos de colaboração, polinização cruzada de ideias e sobrecarga organizacional (sem mencionar a compatibilidade! ) porque é um subgrupo do GC.

Falando em cálculo, um cenário hipotético extremo "e se um subgrupo estiver agindo com intenção maliciosa para influenciar o núcleo do WebAssembly / trabalhar em torno de seus objetivos mais altos" também pode ser interessante aqui, o que acredito que muitos concordarão comigo não é o caso quando o subgrupo é WASI, mas eu ainda gostaria de aumentar a conscientização para, uma vez que a inclusão ou exclusão de recursos de Tipos de Interface, por exemplo, que é uma proposta central efetivamente conduzida pelo mesmo grupo, pode facilmente priorizar as necessidades de WASI, efetivamente um não -Web subgrupo de determinado idioma, sobre as necessidades dos outros. Da minha perspectiva do OP, eu já posso ter testemunhado o último, então eu diria que apenas ser cauteloso com o risco e tomar precauções não é necessariamente uma coisa ruim, já que especialmente quando os esforços de um subgrupo estão alinhados com o interesses de uma maioria, os efeitos colaterais podem ser difíceis de perceber antes que o dano tenha sido causado ao núcleo do WebAssembly, o ecossistema mais amplo ou, pior ainda, um padrão da Web. Ou em outras palavras: acho que ser um subgrupo sob o guarda-chuva do WebAssembly deve implicar responsabilidade pelo WebAssembly principal e seus objetivos mais elevados.

Acho que seria bom ser um pouco mais conservador em atribuir malícia a vários grupos, mesmo hipoteticamente ;)

Muitas dessas questões contenciosas, especialmente na proposta de TI, que poucas pessoas estão acompanhando de perto, envolvem apenas e são vistas por um punhado de pessoas. Para questões de design de alta visibilidade, é difícil chegar a uma decisão contra a qual a maioria do CG seria contra porque um subconjunto mais ou menos representativo do CG está envolvido no processo de design, ou pelo menos seguindo sem objetar. Para questões de nicho, no entanto, é possível chegar a uma decisão entre algumas pessoas com a qual o CG completo se sentiria desconfortável. Nesses casos, pode ser útil levantar a questão específica em uma reunião do CG para tomar o pulso completo do CG na direção proposta.

Um exemplo recente disso foi quando @lukewagner levantou a questão de não permitir importações duplicadas. Como você experimentou, o CG não estava totalmente confortável com a direção que o pessoal da ligação de módulos havia proposto e, como resultado, houve uma participação mais ampla nessa discussão e o consenso mudou em uma direção diferente.

Em última análise, propostas com as quais o CG não se sentiria confortável não serão avançadas pelo CG. É claro que quanto mais cedo os problemas forem à tona e discutidos, melhor. Espero que todos se sintam capacitados para levantar questões nas reuniões de CG à medida que as identificam.

Afirmando isso em primeiro lugar - acho que a interoperabilidade com a plataforma da Web é fundamental para a adoção do WebAssembly e concordo em linhas gerais com seus pontos sobre compatibilidade. Dito isso, não tenho certeza de que adicionar barreiras de entrada às propostas levaria a um resultado positivo. O WebAssembly CG é formado pelas pessoas da comunidade, e todas podem ter objetivos diferentes enquanto contribuem para o avanço positivo do padrão. Ter objetivos diferentes às vezes pode levar a atritos, e espero que este seja um lugar onde possamos discordar respeitosamente ao trabalhar em direção a objetivos diferentes.

Foi-me sugerido levar as seguintes preocupações em relação à direção geral do WebAssembly antes de um fórum mais em nível de CG, um conselho que estou seguindo agora na esperança de que nós, como comunidade, possamos resolvê-los para sempre.

Como alguns devem saber, minha perspectiva sobre os objetivos do WebAssembly vem se chocando com as ideias de um certo grupo responsável por várias propostas há algum tempo, muitas vezes levando a discussões mais ou menos acaloradas. Então, acho que há uma oportunidade aqui para identificar a raiz do desacordo e resolvê-lo, para que possamos eventualmente nos alinhar em direção a objetivos comuns novamente. Só posso falar da minha perspectiva, que é mais comum entre as pessoas que estão interessadas em rodar WebAssembly na Web, e _também_ fora da Web, que coincidentemente é exatamente o que estou trabalhando, e estou muito interessado em outros pensamentos.

Do meu ponto de vista, o desacordo decorre da expectativa induzida inicialmente e ainda anunciando o WebAssembly como parte da Plataforma Web Aberta (abreviarei para "a Web" abaixo). Por exemplo, foi dito muitas vezes que Wasm não pretende substituir (ou prejudicar) JavaScript, mas sim uma tecnologia complementar, então sempre assumi que é uma prioridade alcançar uma excelente compatibilidade (para mim também significa: interoperabilidade ) com a Web existente, que é um objetivo geralmente desejável na Web. Ou, como webassembly.org afirma:

Infelizmente, ao longo de todas essas discussões acaloradas, tive a impressão de que meu entendimento dos objetivos do WebAssembly não se alinha com o que meus adversários mais influentes dentro do CG estão trabalhando, o que não posso deixar de ver como tentativas de criar um novo status quo que determina em grande parte a compatibilidade com a Web. A primeira questão em que esse desacordo mostrou é STRING i32 pairs for UTF-16LE em Interface Types (em 2017, no momento da criação chamado Host Bindings), onde após 1 1/2 anos de silêncio, muitos argumentos foram trocados sobre se UTF -8, uma codificação de string amplamente incompatível com APIs da Web e JavaScript, deve ser a única codificação com suporte, ou se seria útil também considerar a compatibilidade desde o início. No meu livro, isso deveria ser um dado adquirido, então fiquei muito surpreso com a simples cadeia de argumentos contrários, que por sua vez alimentavam o desacordo. O problema acabou (principalmente) resolvido com o reconhecimento de que existem tantas linguagens usando uma codificação de string semelhante ao JavaScript que devemos suportá-la, levando ao conceito completo de fusão de adaptadores, mas quase nunca foi reconhecido que a compatibilidade com APIs da Web, em particular, são importantes. Certamente há mais pontos não técnicos para falar no contexto deste problema, mas sugiro que evitemos esses por enquanto e nos concentremos na direção do WebAssembly.

Outro problema semelhante é a história do GC para strings? sobre a proposta do GC, que até agora não chegou a uma resolução, e provavelmente também não precisa necessariamente se o objetivo for um MVP com o qual todos podemos concordar. No entanto, a discussão até agora também indicou que há divergências que teremos que resolver eventualmente, ou seja, assim que o GC puder ser usado de uma maneira que exija interoperabilidade entre WebAssembly e APIs da Web envolvendo strings, talvez envolvendo também um gráfico de módulo arbitrário, então idealmente com conversões e cópias mínimas. O desacordo geral também aparece em uma questão de acompanhamento sobre uma melhor história de GC para matrizes? , que rapidamente se desviou para questionar minha capacidade e o valor do projeto em que estou trabalhando, em vez de discutir a preocupação em questão, que hoje vejo mais como uma consequência infeliz de um mal-entendido de longa data. Se alguma coisa, ele sublinha que há uma oportunidade aqui para alinhar novamente em um terreno comum.

Também fiquei surpreso com os esforços recentes para proibir importações duplicadas? , um mecanismo útil para integração com linguagens dinâmicas como JavaScript, onde a sobrecarga com várias assinaturas é comum. A pressa de votar a remoção na mesma reunião após a apresentação me fez levantar pelo menos as sobrancelhas, mas isso pode ser apenas mais um mal-entendido, ou um desacordo sobre como o processo deve funcionar.

Sem falar por ninguém, mas votar em questões tem sido uma parte historicamente útil do processo para avaliar as opiniões da comunidade, e eu não interpretaria isso como uma pressa de votar, mais como uma pesquisa de direção. Se você olhar para as notas , o CG decidiu que precisamos de mais olhos na questão e a questão do design continua sendo um lugar para essa discussão.

Da mesma forma, recentemente questionei se o WASI pode acabar prejudicando os casos de uso do Wasm na Web? , para mim parece estabelecer um novo status quo como um efeito colateral antes que a parte da comunidade mais focada na Web tivesse a chance de encontrar uma solução que promova a compatibilidade com a Web em vez da fragmentação, devido a propostas relacionadas não estarem muito distantes o suficiente. Pessoalmente, considero problemáticas as prioridades em jogo pelas razões levantadas na questão. E coincidentemente, os esforços no WASI são impulsionados por membros do CG argumentando anteriormente contra meus pontos em Tipos de Interface e, embora a correlação não implique necessariamente causa, ela acabou me levando a questionar a direção geral do WebAssembly, levando-nos de volta a essa questão.

Os princípios de design WASI que tenho certeza que você já olhou bem até agora, declaram explicitamente que não se limitam a APIs que são fáceis de preencher na Web, ao mesmo tempo em que declaram explicitamente que o WASI deve trabalhar com padrões da Web sempre que possível . Como @conrad-watt apontou anteriormente, há uma distinção entre a linguagem principal e o ecossistema, e é um namespace que os hosts podem simplesmente optar por não fornecer. O WASI como um ecossistema tem objetivos de design diferentes, e forçar a compatibilidade da web a ser um de seus objetivos parece não ser produtivo para os problemas que o WASI está tentando resolver.

Como já deve ser óbvio, estou muito preocupado com o fato de que nós, como comunidade, não estamos fazendo o que é necessário para garantir uma excelente compatibilidade com a Web, ao mesmo tempo em que toleramos novas propostas e tecnologias relacionadas para quebrar a compatibilidade com a Web demais, ou afetá-lo de forma negativa, direta ou indireta. Isso me levou a pensar, por exemplo, se o Wasm, ou pelo menos seu eu futuro, talvez não deveria ser uma recomendação do W3C, pois compromete a compatibilidade com versões anteriores uma peça essencial de cada vez, o que certamente é uma conclusão extrema, mas seria a última pergunta que teríamos que fazer quando o nível de desacordo aumenta ainda mais, eu acho.

A comunidade consiste de várias pessoas que trabalharam em padrões da Web ou investiram fortemente na Web. Embora ouça suas preocupações, não tenho certeza de que o futuro seja tão terrível. Você pode adicionar exemplos concretos em que a compatibilidade com versões anteriores já foi comprometida de maneira significativa?

Com esse pano de fundo, hoje estou me voltando para o CG com o pedido de discutir a seguinte adição aos objetivos gerais do WebAssembly, a fim de reduzir o atrito desnecessário no futuro:

A compatibilidade com a Open Web Platform em geral e APIs da Web e JavaScript em particular é fundamental para o sucesso a longo prazo do WebAssembly e não deve ser comprometida se puder ser evitada. A fasquia é especialmente alta para propostas que promovem funcionalidades que não visam principalmente a Web, pois pode haver pouco incentivo para não afetar negativamente esse objetivo.

Este é o aspecto de nível superior que tenho defendido, em poucas palavras, e se pudermos concordar com ele, e apenas escrevê-lo, a maior parte do atrito nas discussões acima se tornaria (principalmente) obsoleta, pelo menos até onde eu estou preocupado, enquanto restauro minha fé no processo.

O que isso pode implicar:

• Tipos de interface é bom, mas a codificação de string JS é importante devido à compatibilidade, e promover UTF-8 sobre ele para fornecer pressão suave ou similar, ou justificá-lo com tendências supostas, pode ser problemático
• Threads, SIMD, i31ref etc. estão todos bem, pois não estão relacionados e apenas adicionam funcionalidade, a menos que sejam / não mais
• O GC está bem, mas ficaria motivado a encontrar uma solução adequada para interoperabilidade eventualmente
• WASI está bem, mas estaria motivado a considerar alternativas ao que é essencialmente uma libc atualmente antes de seguir adiante na rota de fragmentação
• WASI-nn está bem, mas estaria motivado a cooperar, por exemplo, com o aprendizado de máquina para o Web CG

Se acontecer que o CG não pode encontrar consenso em tornar tal parágrafo oficial, ou se grandes modificações forem necessárias, eu ficaria muito preocupado com o futuro do Wasm, especialmente no contexto de ser um padrão da Web e sugeriria redefinir -avaliar nossos objetivos e o que comunicamos publicamente, com mais detalhes. Nesse caso, também podemos querer realizar uma votação para legitimar tal curso, eu acho.

Deixe-me saber de seus pensamentos, obrigado! :)

Voltar a adicionar barreiras explícitas de entrada na forma de processo não funciona muito bem na prática, e dado que suas preocupações são sobre propostas já em andamento, mesmo que soubéssemos exatamente onde incluir este texto de uma perspectiva estritamente processual, isso não se aplicaria retroativamente. Historicamente, tentamos manter o processo de propostas leve para incentivar o progresso e confiar ao CG para tomar as decisões que fazem sentido. A adição de barreiras de processo só vai até certo ponto se a suposição for de que o CG não está operando de boa fé. Não estou dizendo que isso é o que você está insinuando, apenas que as barreiras de entrada não são uma maneira particularmente boa de abordar as preocupações levantadas.

@tlively Parece que eu acariciei um nervo no meu comentário anterior. Por favor, tenha paciência comigo por um momento, pois acredito que pensar nisso completamente pode ser valioso quando evitar resultados ruins ou reduzir a tensão futura é o objetivo. Por exemplo, outro cenário extremo hipotético mais sutil poderia ser "e se um ator também responsável por propostas centrais atrasasse seu avanço para dar aos resultados de um subgrupo com objetivos diferentes tempo para florescer no ecossistema mais amplo - embora não possamos evitar isso, será que quer desencorajá-lo?". Tipo, eu pensei sobre isso por um tempo, mas quero enfatizar que tudo isso é hipotético e mencionar que está servindo a uma causa maior. Só não quero enfraquecer minha sugestão no OP retendo um aspecto que talvez seja relevante para entender meu processo de pensamento que o levou a isso. Este pode ser outro dilema, eu acho, e estou tentando o meu melhor para ser o mais respeitoso possível. Por exemplo, excluí minha resposta anterior que dizia "obrigado por apontar isso e ser tão solidário, minhas desculpas", porque não estava muito confiante em reter o que tinha em mente depois de considerar o que podemos estar perdendo para discutir . Espero que esteja tudo bem, dado o que acredito que está em jogo?

@dtig Muito obrigado pela sua resposta completa. Ler isso me deixou mais confiante sobre o futuro do WebAssembly, e também mais confiante de que minha experiência até agora não é tão representativa para o CG como um todo quanto eu pensava inicialmente. Os exemplos que posso fornecer são principalmente baseados em discussões sobre questões individuais que vinculei no OP, e não tanto na atividade de CG como um todo como agora percebo. Que "WASI deve trabalhar com padrões da Web sempre que possível" também é um aspecto com o qual concordo fortemente, e talvez mal entendido porque para mim parece ser relativizado na próxima frase "onde não é essencial", já que JavaScript, que é o context, é um padrão da Web e não corresponde à minha experiência até agora em problemas relacionados no WASI (consulte https://github.com/WebAssembly/WASI/issues/402 onde o resultado é uma interface semelhante a syslog). Terei que repensar um pouco as implicações aqui, se estiver tudo bem, mas estou interessado em discutir esse ponto e provavelmente argumentaria a favor do ponto de nível mais alto de que os princípios de design da WASI não devem ser inegociáveis, como era minha impressão, então longe, uma vez que o WASI está sob o guarda-chuva do WebAssembly não apenas concede liberdade para criar novas APIs, mas também implica uma responsabilidade devido a potenciais efeitos indiretos (dos quais eu gostaria de aumentar a conscientização) no núcleo do WebAssembly.

Eu acho que WASI não é um bom design. Primeiro, a montagem da Web projetada para a máquina virtual da Web e o design de algumas APIs compatíveis com posix não estão alinhados com a direção do desenvolvimento. Em segundo lugar, uma maneira melhor de introduzir APIs de terceiros é definir interfaces (interação entre dois domínios) para que o número de APIs possa ser controlado e a segurança também possa ser controlada.

outro cenário hipotético mais sutil poderia ser "e se um ator também responsável por propostas centrais atrasasse seu avanço para dar aos resultados de um subgrupo com objetivos diferentes tempo para florescer no ecossistema mais amplo - embora não possamos evitar isso, gostaríamos de desencorajar isto?"

Acredito que se houver desacordo dentro da proposta, o dissidente pode trazer suas preocupações para o CG, que tem poder sobre as propostas. A adoção requer o envio em uma implementação, mas não exige o envio em todas as implementações (acho que dois é o número, mas não o vejo há algum tempo). Não tenho certeza de como isso permitiria a alguém adiar uma proposta contra a vontade de todos os outros, desde que haja implementações.

@penzn Infelizmente, não estaríamos aqui se o processo fosse perfeito. Como exemplo, podemos ver minha discordância com os princípios de design da WASI. Não sei como abordá-los adequadamente, já que o WASI é amplamente independente por design, o que a maioria contemporânea a que serve vê como uma coisa boa, portanto, preocupações mais amplas só podem ser levantadas no próprio WASI, mas minha impressão foi que levantar preocupações com WASI na WASI é muito improvável que leve à resolução, porque a maioria da WASI naturalmente deseja que a WASI permaneça do jeito que está, o que é compreensível. Fui enviado de volta para Tipos de Interface, por exemplo, embora seja o mesmo grupo e eles saibam dos problemas que passei por lá, e na maioria das vezes o que aponto é "incompatível com os princípios de design do WASI" e é isso. Então eu tentei identificar o problema de nível superior, que na minha opinião se resume a WASI ser legitimado para ser pouco alinhado com os objetivos principais do WebAssembly, enquanto ao mesmo tempo não tem responsabilidade pelos objetivos principais do WebAssembly. Então sugiro adaptar o processo, porque ou não posso usar o processo, ou não me sinto capacitado para fazê-lo.

Consulte a discussão sobre segurança da API C na reunião do CG em 28/04/2021, foi uma situação semelhante em que as preocupações do apresentador não foram resolvidas dentro da proposta. Claro, a diferença no caso de WASI é que não é uma proposta, mas CG ainda deve ter autoridade processual. No caso da segurança da API C, houve questões concretas levantadas que o campeão da proposta teve que aceitar depois que a CG ficou do lado do dissidente, no entanto, acredito que você possa apresentar sem votação no final também.

Desculpe, mas não vejo como "Segurança da API C" é comparável a preocupações mais amplas. Você pode elaborar? Por exemplo, eu sinto que fazer uma apresentação pró-Web na WASI apenas alimentaria ainda mais o desacordo. Como @dtig disse, fazer isso "parece não ser produtivo para os problemas que o WASI está tentando resolver".

No debate de segurança da API C também houve um desacordo de alto nível sobre objetivos e necessidades (se as verificações são necessárias ou não para API para uma linguagem insegura), que foi resolvida em uma discussão de CG. Este é um padrão aberto - fazer propostas e iniciar discussões são as únicas ferramentas que realmente temos para mudá-lo.

Algumas reflexões sobre a questão do ecossistema: Concordo que a fragmentação entre APIs da Web e do servidor é um risco. Com a adição do WASI, agora temos dois conjuntos de APIs padronizadas para o Wasm, e sem um caminho óbvio para a unificação, já que sou pessoalmente cético que os navegadores adotarão o WASI e, dada a existência do WASI, o inverso também parece improvável.

Teria sido melhor para a Web se o WASI se concentrasse na portabilidade de APIs da Web para o servidor. Mas isso não significa que teria sido melhor para Wasm como um todo. Eu aprecio a comparação com o Node.js e o histórico da API lá, mas acho que vai nos dois sentidos: Sim, teria sido bom para o Node.js usar mais APIs da Web, mas talvez o enorme sucesso do Node.js se deva em parte ao adicionando as APIs necessárias, independentemente da Web. Talvez o WASI seja necessário para que o Wasm tenha sucesso no servidor - dada a diferença entre os ecossistemas da Web e do servidor, talvez a fragmentação da API seja inevitável.

Essa é uma razão pela qual eu pessoalmente não critiquei o WASI quando ele começou. Embora do ponto de vista da Web não seja o ideal, ainda pode ser necessário para o sucesso de Wasm no servidor, o que pode ser bom para o sucesso geral de Wasm. (A segunda razão é que o modelo de segurança do WASI é interessante e também pode ajudar o Wasm a prosperar.)

De maneira mais geral, o Wasm está sendo estendido de várias maneiras além da Web e do servidor, como plugins, soluções de sandbox, blockchain e outros. Como uma pessoa que trabalha principalmente em uma área, não gostaria de criticar as pessoas que trabalham em outras. Não devemos desacelerar um ao outro.

Acho que a única exceção a isso deveria ser um perigo realmente sério, de fragmentação ou não. Não vejo esse perigo atualmente. Embora ter duas APIs padrão torne algumas coisas complicadas e menos ideais, já podemos preencher o servidor -> Web com polyfill e, eventualmente, também poderemos fazer Web -> servidor, o que ajudará. Para problemas como strings, vejo pré-importações como permitindo o uso ideal de strings na Web - o que também tornará a fragmentação da API no Wasm mais óbvia, mas neste caso é pré-existente devido a diferenças de idioma intransponíveis. No geral, os riscos são reais e irritantes, mas parecem administráveis ​​e inevitáveis.

Bons pensamentos, @kripken , estão alinhados com o meu entendimento da alternativa.

Em relação à comparação do Node.js, o que eu tinha em mente em particular são coisas como Buffer vs Uint8Array , que ainda é responsável por muitos polyfillings (lentos) na Web. Ou a verificação evitável global vs window em todos os outros módulos portáteis. Ou TextDecoder não ser global por um tempo para reduzir o tempo de inicialização. Ou crypto.getRandomValues ainda não está disponível globalmente. Ou todas as armadilhas com suporte ESM até hoje. Eu diria que o Node.js poderia ter se saído melhor em alguns lugares, enquanto o suporte para fs etc. provavelmente era inevitável.

Em WASI, a situação parece ser semelhante, pois muito provavelmente vamos querer um sistema de arquivos WASI, mas existem outras APIs que fornecem funcionalidades comuns entre ecossistemas, APIs que são essenciais para criar um módulo base portátil em primeiro lugar, onde eu acho que podemos fazer melhor do que para onde estamos indo atualmente. Imagine, por exemplo, um módulo que grava no console quando algo dá errado, obtém a hora atual etc., onde depender de um polyfill WASI (completo) parece ser um exagero. Eu imagino que alguns módulos ainda precisariam de um polyfill acompanhante para (apenas) o sistema de arquivos WASI na Web, e acho que isso é realmente gerenciável. Eu só não acho que estamos em uma situação de tudo ou nada aqui, mas que há muito espaço para cooperação que acabará valendo a pena "mas os princípios de design". Meu argumento é: se pudermos, provavelmente deveríamos, e se precisarmos adaptar um pouco o processo para isso, também deveríamos.

Em relação às pré-importações, não sou um grande fã de confiar neles para interoperabilidade muito básica pessoalmente, porque acho que as strings são tão essenciais que a fragmentação nesse nível já não é o que queremos. Por exemplo, você mencionou em outro lugar que ecossistemas com necessidade de portabilidade podem eventualmente convergir para usar strings JS, não porque seja ótimo, mas por pura necessidade. Acho que especialmente aqueles que discordaram de mim anteriormente não ficariam muito satisfeitos com tal resultado, inclusive eu.

Talvez um pouco relevante no contexto, um trecho da última postagem no blog de Deno com menções honrosas de fragmentação do lado do servidor e o valor de aderir às APIs do navegador:

Estender a programação web além do navegador não é uma ideia nova. De fato, fizemos isso com sucesso moderado em nosso projeto “Node.js”. Mas, mais de uma década depois, encontramos o JavaScript do lado do servidor irremediavelmente fragmentado, profundamente ligado a uma infraestrutura ruim e irrevogavelmente governado por comitês sem incentivo para inovar. À medida que a plataforma do navegador avança em ritmo acelerado, o JavaScript do lado do servidor estagnou.

Deno é a nossa tentativa de dar uma nova vida a este ecossistema. Fornecer um sistema de programação moderno e produtivo que adere às APIs do navegador. Deno não é um sistema monolítico, mas sim um conjunto de tecnologias que acreditamos que podem ser reaproveitadas para uma variedade de necessidades. Nem todo caso de uso de JavaScript do lado do servidor precisa acessar o sistema de arquivos; nossa infra-estrutura torna possível compilar ligações desnecessárias. Isso nos permite criar tempos de execução personalizados para diferentes aplicativos: GUIs no estilo Electron, Funções Serverless no estilo Cloudflare Worker, scripts incorporados para bancos de dados etc.

É claro que não é exatamente o mesmo, mas ainda pode haver algo a aprender com as lições que aprenderam.

Definitivamente um artigo relevante, sim. Outra citação importante dele:

Muitos desenvolvedores, nós pensamos, preferem camadas de abstração web-first.

Outra razão pela qual Web -> server polyfilling (como mencionado anteriormente) será importante.

Nota lateral: eu esbocei um bloco de construção para resolver parte dos problemas que vejo com WASI e fragmentação em um nível essencial, chamado System Essentials for WebAssembly , mas gostaria de saber se algo assim soa bem antes propondo qualquer coisa (sinta-se à vontade para abrir um problema por lá). Se alguém vê valor nisso como eu (ou até mesmo quer ser co-campeão/orientar), me avise. Se não, eu estaria interessado em ideias alternativas que alcançariam um efeito comparável :)

De uma olhada rápida em seu documento, a lista de "essenciais" consiste inteiramente em _capabilities_ do sistema. Fornecê-los por padrão implicaria a presença de recursos ambientais e, assim, prejudicaria o modelo de sandboxing que o Wasm foi cuidadosamente projetado para estabelecer.

Além disso, não se pode esperar que nenhum dos recursos dessa lista esteja disponível universalmente, mesmo nos ambientes que hospedam o Wasm hoje. Por exemplo, nem a hora atual (muito menos a hora local), nem a aleatoriedade, nem o registro estão disponíveis em sistemas descentralizados, como blockchains.

Fornecê-los por padrão implicaria a presença de recursos ambientais

Como a presença de uma memória, talvez. Não parece tão diferente.

e, assim, minar o modelo de sandboxing foi cuidadosamente projetado para estabelecer.

Apenas se a memória ou o não determinismo em hardware diferente (FP, SIMD relaxado) também funcionar, eu acho. Eu não pretendia, e não acho que o doc o faça, "minar" o "design cuidadoso" de Wasm.

não se pode esperar que nenhum dos recursos dessa lista esteja disponível universalmente

Um binário Wasm é executado em alguma máquina com alguma VM em algum sistema operacional, então eu não concordaria aqui. Eu acho que é razoável esperar que eles estejam disponíveis universalmente, mesmo que casos de uso especiais possam querer restringir seu uso.

Por exemplo, nem a hora atual (muito menos a hora local), nem aleatoriedade, nem o registro estão disponíveis em sistemas descentralizados, como blockchains

Diga blockchains, por exemplo. Eles normalmente não permitem a matemática de ponto flutuante a partir de hoje e podem, da mesma forma, não permitir a obtenção de tempo ou decidir descartar as mensagens de log, mas os nós ainda são executados em algumas VMs em alguns sistemas operacionais. Eu também diria que depende do caso de uso exato de um livro-razão, portanto, há casos de uso muito prováveis ​​em que as restrições não são necessárias. Eu não acho que Wasm pode resolver isso em um sentido puro de qualquer maneira. Outro extremo são os dispositivos IOT com menos de uma página de memória, com diferentes implicações.

Em geral, acho que lutar contra a fragmentação em um nível tão essencial é valioso, e obviamente estou interessado em pensar nisso, mesmo que o resultado seja algo totalmente diferente do descrito no meu documento (não me importo em jogá-lo fora), mas, em última análise, consegue algo comparável. Como um compromisso construtivo, mas bem informado. Como tal, eu adoraria ter sua opinião sobre como poderíamos alcançar isso, juntos, também pessoalmente, porque isso me faria sentir que minhas ideias são consideradas valiosas por pessoas que admiro por sua experiência técnica.

De qualquer forma, pode ser melhor mover essa discussão para o repositório do meu documento, ou Discord, ou E-Mail, ou chat de voz. Então, por favor, faça (ou entre em contato comigo onde funcionar melhor), se essa for sua impressão também :)

Eu acho que há valor em não ter a especificação do WebAssembly Core assumindo nada sobre seu ambiente de execução, incluindo que existe um sistema operacional ou um ambiente de conceitos de tempo ou log. Para qualquer coisa que dependa ou mude de estado fora da semântica formal do Wasm, a especificação Core esculpe funções importadas como a escotilha de escape, mas é claro que não especifica que qualquer conjunto específico de importações será fornecido.

Em geral, acho que lutar contra a fragmentação em um nível tão essencial é valioso

Acho que esse é o ponto crucial da discordância neste tópico. Pessoalmente, sinto fortemente que não deveria ser um objetivo para a especificação Core Wasm tentar fornecer um ecossistema unificado, mas que deveria tentar fornecer uma abstração tão portátil (e performática) para computação pura quanto possível. Como analogia, nem X86 nem ARM tentam fornecer ecossistemas unificados (ou mesmo ABIs unificados); isso é deixado para a camada de abstração do sistema operacional acima deles, e acho que esse modelo também é apropriado para o WebAssembly.

Dito isto, evitar a fragmentação do ecossistema sempre que possível é claramente valioso, mas acho que deve ser feito em uma camada acima do Core Wasm. O candidato claro para essa camada de unificação do ecossistema é o WASI. Funcionaria se os recursos essenciais que você identificou fossem fornecidos por um módulo WASI projetado especificamente para funcionar com o mínimo de cola dentro e fora da Web? Onde as atuais facilidades WASI para tempo e aleatoriedade ficam aquém?

Talvez seja necessário: um conjunto padronizado de importações _opcionais_; disponíveis na Web, na maioria dos sistemas WASI (porque são opcionais, e o WASI pode ser executado em um ambiente embutido restrito, por exemplo), e quaisquer locais que possam _opcionalmente_ fornecer as importações padrão.

Na Web, seria _como se_ o código JS de cola os passasse, mas não, o sistema os passava e o desenvolvedor JS não precisava fazer nada ou simplesmente precisava listá-los pelo nome para escolher quais Estão disponíveis.

Os desenvolvedores da Web podem ter certeza de que existem certas importações (ou são escolhidas no lado JS), enquanto isso não força o próprio Wasm a tê-las na linguagem.

Um env blockchain pode não fornecer as importações (opcionais), por exemplo.

O usuário deve ser responsável por saber em qual ambiente ele está executando e quais importações estão documentadas para estarem disponíveis.

Isso significaria que não há necessidade de comutadores do compilador para gerar chamadas de API diferentes.

WASI seria duas coisas: um provedor de importações padrão e um provedor de importações especializadas somente para servidor.

Acho que o problema de fornecer importações padrão na Web sem qualquer JS é um problema um pouco diferente (mas @dcodeIO , deixe-me saber se você discordar). Mesmo com um conjunto padrão de importações para uso dentro e fora da Web, a API JS atual ainda exigiria escrever JS para compilar e instanciar o módulo, de modo que o benefício marginal para os desenvolvedores da Web de deixar algumas importações implícitas seria pequeno. Dado um conjunto padrão de importações, pode fazer sentido que elas sejam fornecidas implicitamente por algo como a proposta de integração do ESM, mas o problema aqui é que ainda não temos um conjunto padrão de importações.

@dcodeIO

Acho interessante a ideia do System Essentials, mas discordo de um novo padrão para eles. Idealmente, eles poderiam ir em WASI (como @tlively disse), ou ser APIs da Web.

Sobre APIs da Web: ponto justo no link sobre como obter o fuso horário exigindo um novo objeto Date. Isso é complicado no wasm. Mas é possível com a API JS Reflect ( Reflect.construct especificamente). Poderíamos adicionar mais APIs no lado da API JS ou Wasm JS, conforme necessário. As importações ainda precisariam ser declaradas, mas o custo do tamanho do código deveria ser mínimo.

Sobre as APIs WASI, acredito firmemente que precisamos fazer mais para superar a divisão Web/WASI. Adicionar mais APIs amigáveis ​​à Web ao WASI faz sentido para mim pessoalmente - talvez semelhante ao System Essentials. Descrevi outra direção possível no mês passado e me ofereci para esboçar detalhes específicos se houver interesse, mas ainda não recebi uma resposta do pessoal da WASI. Comentários lá seriam muito bem vindos!

O aspecto crucial para mim é que não deve haver código de cola necessário para a funcionalidade essencial na Web ou funcionalidade comum dentro/fora da Web, pois acredito que um ecossistema que depende de polyfills obrigatórios para funcionalidades muito básicas não é o que devemos nos esforçar para. Também espero que possamos encontrar algo que funcione nos dois sentidos, sem exigir um polyfill na Web nem no WASI, para uma vitória (mesmo que possa ser que as APIs da Web polyfill fora da Web possam ser menos problemáticas - mas eu preferiria fazer algo para ambos).

É daí que vem minha ideia de instruções "System Essentials" um tanto carente, principalmente com base em minha observação até agora de que adicionar um namespace de importação provavelmente não acontecerá em navegadores por motivos mencionados anteriormente, então foi minha intuição que talvez as instruções possam realmente ser menos problemático, embora haja bons argumentos contra. Eu concordo com seus pontos sobre manter o núcleo Wasm "núcleo", e espero que haja algo melhor que possamos fazer em cima do núcleo Wasm que funcione tanto para Web + WASI.

Como tal, não estou particularmente apegado à minha ideia em particular e ficaria feliz com qualquer coisa que marque as caixas de [x] elimine o código de cola , seja por meio de instruções, um namespace de importação comum on + off the Web (WASI ou não) , ou indiretamente por meio da integração do ESM e suportando parte dele fora da Web, para que possamos alcançar [x] menos fragmentação (o mesmo módulo é executado dentro e fora da Web sem polyfilling ao usar apenas a funcionalidade comum; traçando a linha no Filesystem e DOM , que são bastante específicos do ambiente). Isso faz sentido? :)

Outro pensamento: Talvez nossa conversa possa ser útil para informar a ideia de sublinguagens - digamos um "perfil" para "web+wasi" ou algo parecido? Pode então se resumir a padronizar a interseção entre a superfície da API de sublinguagem.

Além disso, com esse problema aberto há quase um mês e, infelizmente, quase nenhum dos funcionários de TI/WASI entrando em contato para melhorar a situação, decidi tentar a análise de conflitos fwiw.

Quero enfatizar que o seguinte é muito subjetivo e realmente representa apenas meu modelo mental emergente da paisagem Wasm. Nada disso implica que alguém esteja fazendo algo ruim, apenas que existem focos variados, o que é natural. Por favor, deixe-me saber se você se sente tratado injustamente, o que não é minha intenção, e eu vou corrigir ou excluir.

Meu objetivo foi identificar o alinhamento, ou a falta dele, entre os players do Wasm, tanto no que diz respeito a tornar o Wasm mais rico, ou seja, incluir mais recursos e casos de uso, respectivamente, mantendo-o puro, ou seja, pressionando o ponto de um ISA mínimo, ao mesmo tempo em que incorpora foco em certos lados da moeda, aqui principalmente interessado em executar o Wasm na Plataforma Web, respectivamente, no Edge ou dentro de um Blockchain, muitas vezes com requisitos muito diferentes.

• Browser: Servindo a Plataforma Web, que é bastante rica por natureza. "O novo sistema operacional de desktop", por assim dizer.
• Servidor: Relativamente barebones por natureza como em "traga suas próprias coisas". Neutro.
• Pesquisa: Quer tornar Wasm bom para todos, a menos que esteja ligado a outro ator.
• Google: Focado em portar coisas para a Web e torná-las rápidas; Tudo bem em considerar as necessidades dos outros, desde que não prejudique as deles?
• Dfinity: All-in em Blockchain; Precisa de alguns recursos de riqueza aparentemente; mas quanto mais barebones melhor?
• Rapidamente: Focado na borda; A VM enxuta/mínima é crítica para seu produto; Efetivamente responsável por TI/WASI?
• Apple: OK com o que funciona para a Web; Não necessariamente ansioso para competir com a App Store?
• AssemblyScript: Deseja praticidade no mundo real; Tende para a Web, mas um pouco confuso devido às partes interessadas no Edge/BC?
• Intel?: Não há muitos sinais até agora; Principalmente interessado em computação eficiente?
• Redhat?: Não há muitos sinais até agora; Principalmente interessado em infraestrutura?
• Microsoft?: Não há muitos sinais até agora; .NET na Web e eventualmente em todos os lugares?
• Mozilla?: Inexistente?

Embora isso provavelmente esteja errado em muitos níveis, descobri que ilustra relativamente bem meu modelo mental. Eu também tracei uma linha onde eu consideraria "A Web em WebAssembly" para entrar em jogo de minhas expectativas, mas isso novamente é discutível. Se alguma coisa, espero que ajude a entender de onde estou vindo e por que tive a impressão de que algo está errado em Wasm-land, ao mesmo tempo em que também esclarece a situação para aqueles que estão interessados ​​em minha visão condensada da questão mas pode não estar ciente de todos os detalhes que aconteceram. Tome, mas com um grão de sal :)

Dois centavos... Estou genuinamente surpreso que essa conversa tenha acontecido. Sempre foi uma má ideia para o WebAssembly permitir que seu escopo fosse definido por quaisquer casos de uso que os primeiros adotantes surgissem.

A Web precisa do WebAssembly de uma forma que nenhuma outra plataforma precisa, porque a Web deve restringir o que seus desenvolvedores podem fazer, especialmente no nível do WebAssembly.

Se o WebAssembly for em uma direção que os mineradores de criptomoedas não gostam, eles podem fazer um fork ou algo assim. Não é algo com o qual precisamos nos preocupar ao projetar padrões da Web. Todos os outros têm controle total sobre a plataforma subjacente. Na Web, temos apenas a plataforma que nos é dada e, uma vez que é um padrão, estamos presos a ela para sempre.

O WASI deve ser bifurcado para fazer suas próprias coisas, e a Web deve ter sua própria VM totalmente otimizada para o navegador, exclusiva e especificamente.

Sempre foi uma má ideia para o WebAssembly permitir que seu escopo fosse definido por quaisquer casos de uso que os primeiros adotantes surgissem.

Na verdade, seu escopo é definido pelo CG, que pode ser acessado por qualquer pessoa, inclusive você. Lá, as pessoas votam na direção, que pode ser influenciada se você quiser gastar tempo em ser ativo nela, e apresentar argumentos técnicos bem pensados.

Qualquer um já pode fazer o fork do Wasm se quiser, mas há muitas vantagens em um ecossistema compartilhado, então é isso que a maioria das partes interessadas busca.

Todo mundo sendo capaz de se juntar ao CG significa que você não pode impedir que pessoas com interesses não relacionados à Web se juntem, eu temo.

Estou genuinamente surpreso que essa conversa tenha acontecido. Sempre foi uma má ideia para o WebAssembly permitir que seu escopo fosse definido por quaisquer casos de uso que os primeiros adotantes surgissem.
...
WASI deve ser bifurcado para fazer suas próprias coisas

WASI _está_ fazendo suas próprias coisas; é um namespace de importação. Não está sendo padronizado no mesmo nível dos recursos da linguagem WebAssembly. A sugestão é que devemos declarar recursos não Web fora do escopo e não permitir que a especificação WASI ocorra sob o guarda-chuva nominal do Grupo da Comunidade? O que isso faria em termos de prevenção da fragmentação?

Há mérito em investigar se certas partes do WASI podem ser ajustadas para serem mais perfeitamente shimmable (tanto Web->WASI ou WASI->Web como @kripken apresentado aqui ), mas mesmo no pior dos casos, apenas acabamos com uma API que não pode ser importada na Web, exatamente como se o WASI fosse concluído como um projeto de terceiros para um tempo de execução não Web.

Novamente, lendo os problemas vinculados ao @dcodeIO , não vejo ninguém que pense que a Web não é importante para o WebAssembly. Tudo o que vejo são pessoas discordando (às vezes sem decoro) em recursos/roteiros para resolver atritos de interoperabilidade bastante específicos, como codificação de string. Acredito firmemente que é um erro caracterizar essas divergências técnicas como evidência de uma luta pelo poder da Web versus não Web, e que isso não resultará em nenhum resultado positivo.

Não vejo isso como uma luta pelo poder, mas sim como um problema com o escopo sendo muito amplo e efetivamente aberto. A World Wide Web é importante o suficiente para ter sua própria VM, com suas próprias especificações e padrões, em seus próprios termos e usando sua própria nomenclatura. A tentativa de tornar tudo geral e abstrato levou a especificações, documentação e conversas que são desconhecidas e muitas vezes estranhas aos desenvolvedores da web.

Para ser claro, o problema de o WASI ser um projeto oficial é puramente simbólico. Não faz diferença técnica, mas seu status deixa claro que a Web usa WebAssembly, mas que não é uma tecnologia criada pela e para a Web.

Não vejo isso como uma luta de poder...

@7ombie desculpas, meu parágrafo final pretendia principalmente comentar o diagrama acima de "conflito".

A tentativa de tornar tudo geral e abstrato levou a especificações, documentação e conversas que são desconhecidas e muitas vezes estranhas aos desenvolvedores da web.

Concordo que algumas das expectativas técnicas em torno dos tipos de interface especificamente se tornaram bastante esotéricas. Certamente há espaço no CG para conversas como "por que tipos de interface em vez de tipos de string de primeira classe", e contamos com desenvolvedores centrados na Web, como @dcodeIO, compartilhando suas opiniões e preocupações para manter o processo funcionando. Fiquei consternado com a maneira como a última conversa sobre isso terminou e espero que possamos fazer melhor no futuro.

Entendido, @conrad-watt. Eu não vi essa conversa, mas de minha parte, não tenho vontade de jogar em um Web vs. mentalidade não-Web, ou qualquer coisa assim. Estou simplesmente compartilhando queixas pessoais com uma tecnologia com a qual geralmente estou muito feliz, animado e grato.

Meus comentários anteriores foram bastante críticos e flagrantes, mas eu estava apenas sendo casual. Eu não estou chateado.

@conrad-watt et al. A descrição técnica dos Tipos de Interface provavelmente ficará mais esotérica antes de ficar menos no futuro próximo. A título de explicação, muito disso é impulsionado pelo desejo de combinar reutilização com rigor.

Gostaria de enfatizar que também vejo valor em cooperar (com WASI e outros) tanto quanto razoavelmente pudermos, por isso estava sugerindo investigar soluções que levem à portabilidade entre ecossistemas de forma que as interseções sejam cobertas, incluindo onde eu 'd atualmente desenhar a linha (DOM, Filesystem). Estou ciente de que o que estou sugerindo pode ser difícil, ou que pode haver maneiras melhores de alcançar algo comparável (me avise! :)). É só isso (para me citar no OP)

Fiquei muito preocupado com o fato de que nós, como comunidade, não estamos fazendo o que é necessário para garantir uma excelente compatibilidade com a Web, enquanto ao mesmo tempo toleramos novas propostas e tecnologias relacionadas para quebrar demais a compatibilidade com a Web ou afetá-la de outra forma. negativa, direta ou indiretamente.

me levou a sugerir reavaliar nossos objetivos de alguma forma , deixando claro que

A compatibilidade com a Open Web Platform em geral e APIs da Web e JavaScript em particular é fundamental para o sucesso a longo prazo do WebAssembly e não deve ser comprometida se puder ser evitada. A fasquia é especialmente alta para propostas que promovem funcionalidades que não visam principalmente a Web, pois pode haver pouco incentivo para não afetar negativamente esse objetivo.

Não estou mais tão apegado a tornar isso um requisito para propostas (como foi sugerido que isso pode se tornar) quanto estava no OP, pois concordo com muitos dos pontos levantados, mas ainda apreciaria um esforço concentrado que efetivamente nos mudasse nessa direção.

@dcodeIO , qual é o possível item de discussão em sua análise de conflito, todas as empresas que você listou precisam revelar e comparar seus planos? Você acha que isso é possível e o que vai conseguir?

Embora não possa comentar sobre nenhuma das empresas em seu gráfico, acho que compará-las dessa maneira é enganoso, pois nenhuma entidade é capaz de alterar o padrão para si mesma sem que outros concordem. Também acho o eixo do gráfico subjetivo e confuso. Por exemplo, executar computação (digamos, renderização ou NN) em wasm na web deve ser "edge", pois move a computação para baixo da "nuvem", mas também deve ser "web", pois essa é uma parte crucial de web interativa agora (e definitivamente não "servidor", já que roda na máquina cliente). A outra dimensão é ainda mais subjetiva IMO, pois pureza e riqueza em sua definição são termos relativos. Exemplo - há uma discussão muito longa sobre restrições de fluxo de controle motivadas pelas convenções de chamada do Go. Dependendo de quem você perguntar, essas restrições seriam vistas como um recurso útil ou desnecessário, o que eu acho que afetaria onde essa pessoa colocaria a discussão no eixo "rico versus puro".

Para fazer uma pergunta direta, a direção de longo prazo do WebAssembly é definida por quem o adota? Por exemplo, se a adoção de longo prazo por desenvolvedores da Web fosse baixa, mas houvesse grandes players industriais com bilhões investidos no uso do WebAssembly para algo não relacionado à Web, suas necessidades eventualmente teriam prioridade?

Para fazer uma pergunta direta, a direção de longo prazo do WebAssembly é definida por quem o adota? Por exemplo, se a adoção de longo prazo por desenvolvedores da Web fosse baixa, mas houvesse grandes players industriais com bilhões investidos no uso do WebAssembly para algo não relacionado à Web, suas necessidades eventualmente teriam prioridade?

Somos um padrão orientado pela comunidade/consenso. Não adianta muito considerar essas situações hipotéticas, porque fundamentalmente elas não podem ser protegidas por nenhum tipo de procedimento formal. Bem-vindo à ansiedade existencial da comunidade/construção de consenso.

Sim, se as únicas pessoas que se importassem com o Wasm fossem engenheiros hardcore de computação de ponta, é provável que a linguagem fosse conduzida nessa direção. Nesse cenário, mesmo que de alguma forma tivéssemos conseguido gravar em pedra um princípio de que apenas recursos compatíveis com a Web podem ser padronizados no CG, isso resultaria apenas em um fork, ou ninguém trabalhando na linguagem.

Para ser claro, eu absolutamente não acredito que esta seja a situação em que estamos. Ou é preciso confiar que os interesses da Web estão sendo adequadamente representados pelos membros do CG, ou se envolver.

Veja, isso é algo que eu não entendo. O objetivo é claramente produzir um padrão Web no final, sob o guarda-chuva do W3C, que tenha princípios e valores muito claros e muita experiência de uma longa história de desafios semelhantes. Não vejo como a liderança da Web e todos com uma bifurcação se alinhando com o que o pessoal da Web cria, se é isso que eles querem, seria pior. Então, sim, estou sugerindo criar primeiro o WebAssembly para a Web e depois para todo o resto, pois o inverso é uma situação insuportável se minha experiência até agora valer alguma coisa. O que quer que isso exija, devemos considerar e conversar sobre isso, pois essa é a causa raiz do problema, eu acho.

Como eu disse acima, embora eu concorde que a Web deva ser uma prioridade para o WebAssembly, não acredito que as divergências técnicas que você está tendo com outros membros do CG sejam principalmente devido a uma divisão entre facções Web vs não Web . Existem razões pelas quais mesmo pessoas puramente focadas na Web gostariam de buscar alternativas para várias de suas propostas, e você não deve interpretar isso como evidência de que as pessoas que discordam de você não se importam com a Web.

WASI não será uma especificação W3C e não interfere em nossa produção da especificação W3C WebAssembly. Declarar que o WASI não deve ser desenvolvido sob o CG porque é "não-Web" não fará com que as pessoas envolvidas voltem sua atenção para a Web. Isso apenas fecharia linhas valiosas de comunicação e colaboração, que podem (por exemplo) nos permitir encontrar sobreposições com alguma API hipotética amigável à Web.

Pontos justos, mas discordamos fundamentalmente, pois não consigo conciliar seu ponto de vista com tudo o que passei. Acho que já existem indicações muito claras de que o problema existe e deve ser resolvido, em vez de me dizer constantemente que não há nada que possamos fazer a respeito. Para mim, isso parece absurdo, até um ponto em que as pessoas deveriam se envergonhar do que estão fazendo com o WebAssembly, que já foi a estrela mais brilhante entre os padrões da Web que claramente não está cumprindo o que se tornou.

Acho que já existem indicações muito claras de que o problema existe e deve ser resolvido, em vez de me dizer constantemente que não há nada que possamos fazer a respeito.

Acho que não estamos conseguindo entender o problema, em vez de decidir que nada pode ser feito a respeito. Há um interesse óbvio em melhorar o WASI ou os tipos de interface, mas não parece haver consenso sobre aqueles que estão fundamentalmente quebrados ou errados.

Obrigado por desbloquear o problema :) Quero me desculpar pelo meu colapso aqui, que não foi bom e espero muito melhor de mim mesmo. Quero continuar engajado com o grupo, inclusive discutindo essa questão (como acho) importante, e espero mostrar que posso fazer isso de maneira construtiva.

Para começar, propus uma apresentação sobre minhas preocupações com codificações de strings, e onde acho que é relevante para os próximos passos em Tipos de Interface, respectivamente, o desenvolvimento mais recente em direção a um Modelo de Componente. E no processo, finalmente decidimos experimentar um novo formato de apresentação pré-gravada, com tempo de discussão agendado para a videoconferência de CG de 22 de junho. A gravação pode ser encontrada na edição que acompanha o link logo acima deste comentário, e espero que ajude a fornecer o pano de fundo necessário de uma maneira mais condensada e construtiva.

Se eu puder oferecer uma sugestão alegre: se alguém recompilar as partes não WASM do código-fonte de um navegador da Web em Binaryen ou Rust, visando WASI na área de trabalho, bastaria dizer que a maior parte do navegador é apenas um grande polyfill ou apenas viraria o argumento para dentro de si mesmo, causaria um colapso catastrófico e transformaria a Terra em um buraco negro?

Em uma nota séria: IIRC, a web começou como uma documentação com hiperlink da lista telefônica de Sir Tim Berners-Lee no CERN. A própria web superou todas as expectativas, incluindo as de complexidade e consumo de memória. O navegador da web evoluiu de um visualizador de documentos para um meio de publicação completo. Isso é rastejamento de recursos.

O WASI, como ambiente de programação, tem o potencial de devolver as tecnologias da web às suas raízes como um ramo da ciência da computação onde a publicação e a interatividade se fundem. Desde quando uma sala de chat precisa rodar em um navegador para ser uma tecnologia web? O IRC, o protocolo de bate-papo original, existe há mais tempo do que o navegador da web. Da mesma forma, o SMTP é anterior à WWW e o FTP também. A Internet é maior do que apenas a web e era assim que deveria ser.