Design: Haruskah WebAssembly menganggap kompatibilitas dengan Open Web Platform sangat penting?

Saya secara umum setuju dengan pernyataan seperti yang tertulis, tetapi saya tidak berpikir komitmen formal apa pun untuk itu akan menghindari banyak ketidaksepakatan yang telah Anda tautkan. Secara khusus, pernyataan Anda diutarakan terutama sebagai penghalang tambahan untuk adopsi proposal, tetapi dalam banyak masalah terkait Anda menganjurkan penambahan bahasa inti.

Ini mungkin eksperimen pemikiran yang berguna untuk mempertimbangkan posisi ekstrem hipotetis "jika fitur membantu kompatibilitas dengan Web, kita harus menambahkannya ke Wasm", yang tidak akan saya setujui karena pada akhirnya akan membuat bahasa membengkak dengan banyak Kait khusus JS. Saya tidak menyiratkan bahwa Anda menganjurkan posisi seperti itu, tetapi saya pikir pernyataan Anda seperti yang tertulis dalam OP tidak menangkap ketidaksepakatan konseptual yang tampaknya muncul dalam masalah yang Anda tautkan.

Ada juga perbedaan antara "WebAssembly" bahasa inti (yang saya rasa benar-benar harus tetap kompatibel dengan "Platform Web Terbuka"), dan ekosistem alat, antarmuka host, dan ruang nama impor yang mungkin dipilih untuk distandarisasi/direkayasa di sekitarnya . Ini kurang penting bahwa WASI tetap "Web-friendly", karena ini adalah namespace impor yang host dapat dengan mudah memilih untuk tidak menyediakan. Paling buruk, itu akan menyebabkan upaya duplikat/pemisahan rantai alat jika seseorang kemudian menstandarisasi API yang lebih ramah-Web.

Ya, beberapa dari masalah ini sedikit di sisi yang lebih tua, dan saya pasti akan mendekati mereka secara berbeda hari ini (bahkan lebih jika komitmen seperti itu ada pada saat itu). Saya akan memikirkan sedikit tentang yang ini dan poin Anda yang lain :)

Saya sedikit terkejut dengan kesan bahwa saya menganjurkan penambahan bahasa inti dalam banyak masalah, jadi mungkin ada baiknya untuk memberikan beberapa konteks. Kadang-kadang, saya memang mencari alternatif saku belakang (saya kira) di mana tampaknya membantu dalam konteks diskusi, yang dapat dilihat sebagai advokasi untuk penambahan saya pikir, terutama Universal Strings di mana saya mencoba membantu menyelesaikan kebuntuan yang dirasakan antara Antarmuka Tipe dan GC yang sama-sama menunjuk satu sama lain untuk bertanggung jawab atas kekhawatiran saya. Kalau dipikir-pikir, saya menyesal mengangkat ini lagi dalam masalah TI, karena GC tampaknya menjadi tempat yang lebih tepat. Mungkin masih meledak di sana, kalau begitu, tidak yakin. Pada akhirnya saya tidak pernah mengusulkan ini, juga mengingat ketegangan yang ada, tetapi kebanyakan menciptakannya karena keinginan untuk menjelaskan apa yang saya maksud secara konkret. Kalau dipikir-pikir, ini sedikit dilema yang saya hadapi, karena mengusulkan apa pun tampaknya akan gagal karena ketegangan, dan juga menyelesaikan argumen saya secara lebih rinci, jadi jika kita dapat membuat hidup semua orang sedikit lebih mudah dengan membuat tujuan WebAssembly lebih jelas, dan berupaya menyelesaikan ketidaksepakatan umum, saya akan sangat menghargainya.

Posisi ekstrem hipotetis cukup menarik, karena saya juga berpendapat bahwa ada fitur JS warisan yang mungkin tidak perlu dikhawatirkan Wasm secara proaktif, atau mungkin tidak sama sekali, tetapi kemudian masih ada garis yang harus ditarik di suatu tempat. Intuisi saya memberi tahu saya bahwa satu fitur terlalu banyak lebih baik daripada satu terlalu sedikit, misalnya, karena kompatibilitas sangat penting. Dengan komitmen yang ada, mungkin setidaknya akan lebih mungkin bahwa fitur yang menarik bagi minoritas dapat didiskusikan dengan lebih sedikit gesekan, dan memiliki peluang sukses yang lebih baik untuk mencapai tujuan yang lebih tinggi?

Perbedaan antara bahasa inti dan ekosistem yang lebih luas juga menarik. Saya berpendapat bahwa jika kita bisa, kita harus mencoba untuk menghindari jalan masalah ekosistem masa depan dan ketidakcocokan, dan harus berbicara lebih banyak tentang menghindari fragmentasi antara Wasm di Web dan Wasm dari Web misalnya, yang tampaknya menjadi topik sebagian besar tidak ada pada hari ini. Misalnya, di ekosistem Node.js ternyata semua API khusus yang diciptakan untuk Non-Web pada awalnya keren, tetapi juga menjadi beban hari ini, karena berpegang pada (penggunaan kembali) API Web umumnya lebih disukai daripada polyfilling wajib. Deno, upaya kedua di Node.js untuk mengatakan, menyadari hal itu, tetapi ekosistem yang lebih luas sekarang terjebak dengannya untuk waktu yang lama.

Saya tidak tahu berapa nilainya untuk menghindari upaya duplikat. Berguna untuk memilikinya sebagai opsi, selama itu tidak mengarah ke jalur fragmentasi yang mungkin dapat dihindari? Misalnya, WASI adalah standar kuasi di bawah payung WebAssembly yang sekarang menyelinap ke Wasm di Web, dan semakin matang, semakin sulit untuk memperbaiki masalah ekosistem yang kami temukan dalam prosesnya, jadi mekanisme untuk mencegahnya hasil sebelum terlambat tampaknya berguna.

Kami tidak dapat memiliki tujuan desain yang mutlak bahwa Wasm harus optimal untuk ekosistem atau kasus penggunaan tertentu, karena pada dasarnya Wasm melayani banyak sistem ramah lingkungan, kasus penggunaan, dan bahasa, yang akan selalu memerlukan beberapa tingkat kompromi.

Selain web & non-web, desain Wasm sejauh ini telah memberikan penekanan yang besar untuk menghadirkan kumpulan bahasa yang lebih luas ke web, yang seringkali merupakan bahasa yang hampir secara sengaja sangat berbeda dari JS, karena mereka paling melengkapi kemampuan JS yang ada. , dan dengan demikian menjadikan kombinasi JS+Wasm yang paling kuat. Ini juga memungkinkan sebagian besar perangkat lunak yang ada dibawa ke web, dan memungkinkan web mencapai tingkat kinerja baru. Jika Wasm telah dirancang untuk mendukung bahasa yang sangat mirip dengan JS, itu akan menjadi sia-sia.

Ini adalah hal yang baik, tetapi tentu saja berarti bahasa-bahasa ini mungkin agak berbeda dalam hal detail implementasi hal-hal seperti manajemen memori, string dll, dan kebutuhan mereka harus diperhitungkan, terutama karena inti dari penggunaan bahasa ini adalah untuk memungkinkan mereka untuk menjadi efisien dalam konteks baru ini. Ketika datang ke interop di perbatasan, tidak hanya interop dengan JS perlu dipertimbangkan, tetapi juga interop antara beberapa bahasa Wasm, dan, di masa depan, interop antara bahasa-bahasa ini dan kode asli browser dan host Wasm lainnya, yang akan sering menjadi bahasa yang sama atau mirip. Proposal seperti jenis antarmuka mencoba menyeimbangkan semua persyaratan ini, bukan hanya salah satunya.

Saya percaya ada kesalahpahaman lain dalam permainan yang mungkin bagus untuk dibicarakan. Saya memang telah menganjurkan untuk mempertimbangkan kebutuhan proyek saya, terlebih pada awalnya karena saya berharap perspektifnya yang agak unik (saya percaya bahwa beberapa masalah AssemblyScript hari ini adalah kenari untuk masalah WebAssembly besok) akan berharga bagi CG, tetapi baru-baru ini dan terutama hari ini saya tidak menganjurkan bahasa tertentu tetapi untuk tujuan kompatibilitas yang lebih tinggi di Web, sambil berharap memanfaatkan kesempatan dengan baik untuk menyelesaikan ketidaksepakatan di antara kelompok. Sama seperti Anda, saya sangat percaya bahwa Wasm seharusnya tidak menyukai bahasa tertentu, dan saya khawatir kita kehilangan jejak aspek yang lebih penting seperti kompatibilitas antara standar Web daripada berdebat untuk atau melawan bahasa tertentu, yang mengarah ke diskusi yang sangat mungkin untuk menjadi terlalu panas untuk menjadi konstruktif, pada gilirannya mengulur-ulur evolusi WebAssembly. Sebagai contoh, saya sedikit tersinggung dengan cara Anda mengungkapkan komentar Anda, karena saya merasa itu menyiratkan beberapa hal yang mungkin ada dalam agenda saya tetapi tidak, sementara saya sebenarnya setuju dengan poin tingkat Anda yang lebih tinggi untuk tidak mendukung a bahasa tertentu, melengkapi kemampuan JS yang ada, menyeimbangkan semua persyaratan, membuat kompromi jika diperlukan, dan bekerja untuk mencapai tingkat kinerja baru, selama itu tidak mengarah ke standar Web yang bukan lagi standar Web, yang akan menjadi sangat disayangkan.

Pertama, saya ingin mengatakan bahwa saya melihat pengalaman Anda memiliki musuh di CG sebagai tanda kegagalan proses. Bukanlah tujuan yang tidak masuk akal bagi kami untuk bekerja tanpa permusuhan, bahkan ketika kami sangat tidak setuju satu sama lain mengenai detail atau prioritas teknis.

Kedua, saya setuju bahwa interoperabilitas dengan JS penting untuk keberhasilan Core WebAssembly. Itu termasuk proposal seperti GC dan EH, yang belum sepenuhnya menyempurnakan JS API, tetapi akan sebelum distandarisasi. Ada juga subkelompok tumpukan, yang mempertimbangkan interop JS sebagai masalah bisnis pertamanya. Saya juga akan memasukkan dalam pernyataan itu proposal lain seperti TI yang berlapis, mungkin melalui spesifikasi terpisah, di atas Core WebAssembly, tetapi masih dimaksudkan untuk diintegrasikan ke dalam platform Web.

Saya pikir kalkulus berbeda untuk konsumen non-Web dari spesifikasi Core WebAssembly secara umum, dan WASI pada khususnya. Saya tidak berpikir CG harus (atau dapat) mencoba untuk memaksakan kontrol apa pun atas bagaimana Core WebAssembly digunakan atau disematkan di luar platform Web, dan karena subkelompok WASI saat ini tidak mengusulkan perubahan apa pun pada platform Web, saya tidak berpikir masuk akal untuk membebaninya dengan kewajiban kompatibilitas Web. Pertimbangkan bahwa subkelompok WASI selalu dapat melakukan pekerjaan yang sama dengan tujuan yang sama di beberapa organisasi standar lainnya, tetapi kita semua jauh lebih baik dalam hal kolaborasi, penyerbukan silang ide, dan overhead organisasi (belum lagi kompatibilitas! ) karena merupakan subgrup dari CG.

Berbicara tentang kalkulus, skenario ekstrim hipotetis "bagaimana jika subkelompok bertindak dengan niat jahat untuk mempengaruhi WebAssembly inti / bekerja di sekitar tujuan yang lebih tinggi" mungkin menarik di sini juga, yang saya yakin banyak yang akan setuju dengan saya tidak demikian halnya ketika subkelompok adalah WASI, tetapi saya masih ingin meningkatkan kesadaran, karena penyertaan atau pengecualian fitur Jenis Antarmuka misalnya, yang merupakan proposal inti yang secara efektif didorong oleh kelompok yang sama, dapat dengan mudah memprioritaskan kebutuhan WASI, secara efektif non -Web subkelompok bahasa tertentu, atas kebutuhan orang lain. Dari sudut pandang saya pada OP, saya mungkin sudah menyaksikan yang terakhir, jadi saya berpendapat bahwa hanya waspada terhadap risiko dan mengambil tindakan pencegahan belum tentu merupakan hal yang buruk, karena terutama ketika upaya subkelompok sebaliknya diselaraskan dengan Untuk kepentingan mayoritas, efek sampingnya mungkin sulit disadari sebelum kerusakan terjadi pada inti WebAssembly, ekosistem yang lebih luas, atau bahkan standar Web yang lebih buruk. Atau dengan kata lain: Saya pikir menjadi subkelompok di bawah payung WebAssembly harus menyiratkan tanggung jawab untuk WebAssembly inti dan tujuan yang lebih tinggi.

Saya pikir akan lebih baik untuk menjadi sedikit lebih konservatif tentang menganggap kebencian ke berbagai kelompok, bahkan secara hipotetis;)

Banyak dari isu-isu kontroversial ini, terutama dalam proposal TI, yang tidak diikuti banyak orang, hanya melibatkan dan dilihat oleh segelintir orang. Untuk masalah desain dengan visibilitas tinggi, sulit untuk mencapai keputusan yang akan ditentang oleh mayoritas CG karena sebagian kecil perwakilan CG terlibat dalam proses desain, atau setidaknya mengikuti tanpa keberatan. Namun, untuk masalah khusus, adalah mungkin untuk mencapai keputusan di antara beberapa orang yang membuat CG penuh tidak nyaman. Dalam kasus ini, akan sangat membantu untuk mengangkat masalah spesifik pada pertemuan CG untuk mengambil denyut nadi CG penuh pada arah yang diusulkan.

Salah satu contoh baru-baru ini adalah ketika @lukewagner mengangkat masalah pelarangan impor duplikat. Seperti yang Anda alami, CG tidak sepenuhnya nyaman dengan arah yang telah dibuat oleh orang-orang yang menghubungkan modul, dan sebagai hasilnya ada partisipasi yang lebih luas dalam diskusi itu dan konsensus telah bergeser ke arah yang berbeda.

Pada akhirnya proposal yang CG tidak akan nyaman tidak akan diajukan oleh CG. Tentu saja, isu-isu sebelumnya muncul dan dibahas, semakin baik. Saya berharap semua orang merasa diberdayakan untuk mengangkat masalah dalam pertemuan CG saat mereka mengidentifikasinya.

Menyatakan ini pertama dan terutama - saya pikir interoperabilitas dengan platform web sangat penting untuk adopsi WebAssembly, dan saya setuju secara luas dengan poin Anda tentang kompatibilitas. Yang mengatakan saya tidak yakin bahwa menambahkan hambatan masuk ke proposal akan menghasilkan hasil yang positif. CG WebAssembly terdiri dari orang-orang di komunitas, dan mereka semua dapat memiliki tujuan yang berbeda sambil berkontribusi untuk memajukan standar secara positif. Memiliki tujuan yang berbeda terkadang dapat menyebabkan gesekan, dan saya berharap ini adalah tempat di mana kita dapat dengan hormat tidak setuju ketika bekerja menuju tujuan yang berbeda.

Telah disarankan kepada saya untuk mengambil perhatian berikut mengenai arah umum WebAssembly sebelum forum tingkat CG yang lebih tinggi, saran yang saya ikuti sekarang dengan harapan bahwa kita sebagai komunitas pada akhirnya dapat menyelesaikannya untuk selamanya.

Seperti yang mungkin diketahui beberapa orang, perspektif saya tentang tujuan WebAssembly telah berbenturan dengan ide-ide kelompok tertentu yang bertanggung jawab atas berbagai proposal untuk waktu yang cukup lama, sering kali mengarah pada diskusi yang kurang lebih panas. Jadi saya pikir ada peluang di sini untuk mengidentifikasi akar ketidaksepakatan dan menyelesaikannya, sehingga pada akhirnya kita dapat menyelaraskan kembali ke tujuan bersama. Saya hanya dapat berbicara dari sudut pandang saya, yang lebih umum di antara orang-orang yang tertarik menjalankan WebAssembly di Web, dan _juga_ di luar Web, yang kebetulan persis seperti yang sedang saya kerjakan, dan saya sangat tertarik dengan pemikiran orang lain.

Dari sudut pandang saya, ketidaksepakatan berasal dari harapan yang disebabkan oleh awalnya dan masih mengiklankan WebAssembly sebagai bagian dari Open Web Platform (saya akan mempersingkat menjadi "Web" di bawah). Misalnya, telah dinyatakan berkali-kali bahwa Wasm tidak dimaksudkan untuk menggantikan (atau membahayakan) JavaScript, tetapi lebih merupakan teknologi pendamping, jadi saya selalu berasumsi bahwa itu adalah prioritas untuk mencapai kompatibilitas yang sangat baik (bagi saya juga berarti: interoperabilitas ) dengan Web yang ada, yang merupakan tujuan umum yang diinginkan di Web. Atau, seperti yang dinyatakan webassembly.org:

Sayangnya, selama semua diskusi panas ini, saya mendapat kesan bahwa pemahaman saya tentang tujuan WebAssembly tidak selaras dengan apa yang sedang dikerjakan oleh musuh saya yang lebih berpengaruh di CG, yang mau tidak mau saya lihat sebagai upaya untuk menciptakan status baru. quo yang sebagian besar faktor keluar kompatibilitas dengan Web. Masalah pertama ketidaksepakatan ini menunjukkan adalah STRING i32 pasang untuk UTF-16LE di Jenis Antarmuka (pada tahun 2017, pada saat pembuatan bernama Host Bindings), di mana setelah 1 1/2 tahun keheningan banyak argumen telah dipertukarkan pada apakah UTF -8, pengkodean string yang sebagian besar tidak kompatibel dengan API Web dan JavaScript, seharusnya menjadi satu-satunya pengkodean yang didukung, atau apakah akan berguna juga memperhitungkan kompatibilitas dari awal. Dalam buku saya ini harus diberikan, jadi saya sangat terkejut dengan rangkaian argumen yang bertentangan, yang pada gilirannya memicu ketidaksepakatan. Masalah akhirnya (kebanyakan) diselesaikan dengan pengakuan bahwa ada begitu banyak bahasa yang menggunakan pengkodean string seperti JavaScript yang harus kami dukung, yang pada gilirannya mengarah pada konsep menyeluruh dari fusi adaptor, namun hampir tidak pernah diakui bahwa kompatibilitas dengan Web API khususnya adalah penting. Tentu saja ada lebih banyak poin non-teknis untuk dibicarakan dalam konteks masalah ini, tetapi saya sarankan kita menghindari ini untuk saat ini dan fokus pada arahan WebAssembly.

Masalah serupa lainnya adalah cerita GC untuk string? atas proposal GC, yang sejauh ini tidak mencapai resolusi, dan mungkin juga tidak harus jika tujuannya adalah MVP yang bisa kita sepakati bersama. Namun, diskusi sejauh ini juga menunjukkan bahwa ada ketidaksepakatan yang harus kita selesaikan pada akhirnya, yaitu segera setelah GC dapat digunakan dengan cara yang memerlukan interoperabilitas antara WebAssembly dan Web API yang melibatkan string, mungkin juga melibatkan grafik modul arbitrer, jadi idealnya dengan konversi dan penyalinan minimal. Ketidaksepakatan umum juga muncul dalam masalah tindak lanjut mengenai cerita GC yang lebih baik untuk array? , yang dengan cepat beralih untuk mempertanyakan kemampuan saya dan nilai proyek yang sedang saya kerjakan alih-alih membahas masalah yang ada, yang saat ini saya lihat lebih sebagai konsekuensi yang tidak menguntungkan dari kesalahpahaman yang sudah berlangsung lama. Jika ada, itu menggarisbawahi bahwa ada peluang di sini untuk menyelaraskan kembali kesamaan.

Saya juga terkejut dengan upaya baru-baru ini untuk Melarang impor duplikat? , sebuah mekanisme yang berguna untuk diintegrasikan dengan bahasa dinamis seperti JavaScript di mana kelebihan beban dengan banyak tanda tangan adalah hal biasa. Terburu-buru untuk memilih penghapusan dalam pertemuan yang sama setelah presentasi membuat saya menaikkan alis saya setidaknya, tapi ini mungkin hanya kesalahpahaman lain, atau ketidaksepakatan tentang bagaimana proses harus bekerja.

Tidak berbicara untuk siapa pun, tetapi memberikan suara pada isu-isu telah menjadi bagian historis yang berguna dari proses untuk mengukur pendapat masyarakat, dan saya tidak akan membacanya sebagai terburu-buru untuk memilih, lebih dari jajak pendapat untuk arah. Jika Anda melihat catatan , CG memutuskan bahwa kami membutuhkan lebih banyak perhatian pada masalah ini dan masalah desain terus menjadi tempat untuk diskusi itu.

Demikian pula, saya baru-baru ini mempertanyakan apakah WASI dapat merusak kasus penggunaan Wasm di Web? , bagi saya tampaknya membangun status quo baru sebagai efek samping sebelum bagian komunitas yang lebih berfokus pada Web memiliki kesempatan untuk menemukan solusi yang mempromosikan kompatibilitas dengan Web daripada fragmentasi, karena proposal terkait tidak jauh cukup. Secara pribadi saya menganggap prioritas yang dimainkan di sana bermasalah karena alasan yang diangkat dalam masalah ini. Dan secara kebetulan, upaya di WASI didorong oleh anggota CG sebelumnya yang menentang poin saya di Jenis Antarmuka, dan sementara korelasi tidak selalu menyiratkan sebab-akibat, pada akhirnya membuat saya mempertanyakan arah umum WebAssembly, membawa kita kembali ke masalah ini.

Prinsip- prinsip desain WASI yang saya yakin Anda telah melihat dengan baik sekarang, secara eksplisit menyatakan bahwa itu tidak terbatas pada API yang mudah untuk polyfill di Web, sementara juga secara eksplisit menyatakan bahwa WASI harus bekerja dengan standar Web jika memungkinkan . Seperti yang ditunjukkan @conrad-watt sebelumnya, ada perbedaan antara bahasa inti dan ekosistem, dan ini adalah ruang nama yang dapat dipilih oleh host untuk tidak disediakan. WASI sebagai sebuah ekosistem memiliki tujuan desain yang berbeda, dan memaksa web compat menjadi salah satu tujuan mereka tampaknya tidak produktif terhadap masalah yang coba dipecahkan oleh WASI.

Seperti yang sudah jelas sekarang, saya menjadi sangat khawatir bahwa kita, sebagai sebuah komunitas, tidak melakukan apa yang diperlukan untuk memastikan kompatibilitas yang sangat baik dengan Web, sementara pada saat yang sama menoleransi proposal baru dan teknologi terkait untuk merusak kompatibilitas dengan Web terlalu banyak, atau sebaliknya mempengaruhinya secara negatif, langsung, atau tidak langsung. Ini membuat saya bertanya-tanya, misalnya, apakah Wasm, atau setidaknya dirinya di masa depan, mungkin tidak boleh menjadi rekomendasi W3C karena kompromi kompatibilitas mundur satu bagian penting pada satu waktu, yang tentu saja merupakan kesimpulan ekstrem, tetapi akan menjadi pertanyaan pamungkas yang harus kami tanyakan ketika tingkat ketidaksepakatan meningkat, saya pikir.

Komunitas terdiri dari beberapa orang yang telah bekerja pada standar Web atau berinvestasi besar-besaran di Web. Sementara saya mendengar kekhawatiran Anda, saya tidak yakin bahwa masa depan cukup mengerikan. Bisakah Anda menambahkan contoh konkret di mana kompatibilitas mundur telah dikompromikan dengan cara yang berarti?

Dengan latar belakang itu, hari ini saya beralih ke CG dengan permintaan untuk membahas tambahan berikut pada tujuan keseluruhan WebAssembly untuk semoga mengurangi gesekan yang tidak perlu di masa depan:

Kompatibilitas dengan Open Web Platform secara umum, dan Web API dan JavaScript pada khususnya, sangat penting untuk kesuksesan jangka panjang WebAssembly, dan tidak boleh dikompromikan jika dapat dihindari. Bilah sangat tinggi untuk proposal yang mempromosikan fungsionalitas yang tidak terutama menargetkan Web, karena mungkin ada sedikit insentif untuk tidak memengaruhi tujuan ini secara negatif.

Ini adalah aspek tingkat yang lebih tinggi yang telah saya anjurkan, singkatnya, dan jika kita dapat menyetujuinya, dan hanya menuliskannya, sebagian besar gesekan dalam diskusi di atas akan menjadi (kebanyakan) usang, setidaknya sejauh yang saya saya prihatin, sambil memulihkan iman saya ke dalam proses.

Apa yang bisa tersirat dari ini:

• Jenis Antarmuka baik-baik saja, tetapi pengkodean string JS penting karena kompatibilitas, dan mempromosikan UTF-8 di atasnya untuk memberikan tekanan lembut atau serupa, atau membenarkannya dengan tren yang diakui, mungkin bermasalah
• Utas, SIMD, i31ref dll. semuanya baik-baik saja, karena ini tidak terkait dan hanya menambah fungsionalitas, kecuali jika ada/tidak lagi
• GC baik-baik saja, tetapi pada akhirnya akan termotivasi untuk menemukan solusi yang cocok untuk interoperabilitas
• WASI baik-baik saja, tetapi akan termotivasi untuk mempertimbangkan alternatif untuk apa yang pada dasarnya adalah libc saat ini sebelum melangkah lebih jauh ke rute fragmentasi
• WASI-nn baik-baik saja, tetapi akan termotivasi untuk bekerja sama misalnya dengan Pembelajaran Mesin untuk Web CG

Jika ternyata CG tidak dapat menemukan konsensus untuk membuat paragraf seperti itu resmi, atau jika modifikasi besar diperlukan, saya akan sangat khawatir tentang masa depan Wasm terutama dalam konteks menjadi standar Web dan akan menyarankan untuk kembali -mengevaluasi tujuan kami, dan apa yang kami komunikasikan secara publik, secara lebih rinci. Dalam hal ini, kami mungkin juga ingin mengadakan pemungutan suara untuk melegitimasi kursus semacam itu, saya pikir.

Beri tahu saya pendapat Anda, terima kasih! :)

Kembali ke menambahkan hambatan masuk eksplisit dalam bentuk proses tidak bekerja dengan baik dalam praktiknya, dan mengingat bahwa kekhawatiran Anda adalah tentang proposal yang sudah berjalan, bahkan jika kami tahu persis di mana harus memasukkan teks ini dari perspektif proses yang ketat ini tidak akan berlaku surut. Secara historis kami telah mencoba untuk menjaga agar proses proposal tetap ringan untuk mendorong kemajuan ke depan, dan mempercayakan kepada CG untuk membuat keputusan yang masuk akal. Menambahkan hambatan proses hanya berjalan sejauh ini jika asumsinya adalah bahwa CG tidak beroperasi dengan itikad baik. Sama sekali tidak mengatakan bahwa inilah yang Anda maksudkan, hanya saja hambatan masuk bukanlah cara yang sangat baik untuk mengatasi masalah yang diangkat.

@tlively Sepertinya saya berani dalam komentar saya sebelumnya. Mohon bersabar sebentar, karena saya percaya bahwa memikirkan ini sepenuhnya dapat bermanfaat ketika menghindari hasil yang buruk atau mengurangi ketegangan di masa depan adalah tujuannya. Misalnya, skenario ekstrim hipotetis lain yang lebih halus dapat menjadi "bagaimana jika seorang aktor yang juga bertanggung jawab atas proposal inti menunda memajukan ini untuk memberikan hasil subkelompok dengan tujuan yang berbeda waktu untuk berkembang di ekosistem yang lebih luas - sementara kita tidak dapat mencegahnya, akankah kita ingin mengecilkannya?". Seperti, saya memang memikirkan hal ini untuk sementara waktu, tetapi saya ingin menekankan bahwa ini semua hipotetis dan menyebutkannya melayani tujuan yang lebih tinggi. Saya hanya tidak ingin melemahkan saran saya di OP dengan menahan aspek yang mungkin relevan untuk memahami proses pemikiran saya yang mengarah ke sana. Ini mungkin dilema lain, saya pikir, dan saya mencoba yang terbaik untuk bersikap hormat semampu saya. Misalnya, saya menghapus balasan saya sebelumnya yang berbunyi "terima kasih telah menunjukkan ini dan menjadi sangat mendukung, saya minta maaf", karena saya tidak cukup percaya diri dengan menahan apa yang ada dalam pikiran saya setelah mempertimbangkan apa yang mungkin hilang untuk kita diskusikan. . Saya harap ini baik-baik saja, mengingat apa yang saya yakini dipertaruhkan?

@dtig Terima kasih banyak atas jawaban menyeluruh Anda. Membacanya membuat saya lebih percaya diri tentang masa depan WebAssembly, dan juga lebih yakin bahwa pengalaman saya sejauh ini tidak mewakili CG secara keseluruhan seperti yang saya pikirkan sebelumnya. Contoh yang dapat saya berikan sebagian besar didasarkan pada diskusi dalam masalah individu yang saya tautkan di OP, dan tidak terlalu banyak pada aktivitas CG secara keseluruhan seperti yang saya sadari sekarang. Bahwa "WASI harus bekerja dengan standar Web jika memungkinkan" juga merupakan aspek yang sangat saya setujui, dan mungkin disalahpahami karena bagi saya tampaknya direlatifkan dalam kalimat berikutnya "di mana itu tidak penting", karena JavaScript, yang merupakan konteks, adalah standar Web, dan tidak cocok dengan pengalaman saya sejauh ini dalam masalah terkait di WASI (lihat https://github.com/WebAssembly/WASI/issues/402 di mana hasilnya adalah antarmuka seperti syslog). Saya harus memikirkan kembali implikasinya di sini sebentar, jika tidak apa-apa, tetapi saya tertarik untuk membahas poin ini, dan kemudian kemungkinan akan berdebat untuk poin tingkat yang lebih tinggi bahwa prinsip-prinsip desain WASI tidak boleh dinegosiasikan, seperti kesan saya begitu jauh, karena WASI berada di bawah payung WebAssembly tidak hanya memberinya kebebasan untuk membuat API baru, tetapi juga menyiratkan tanggung jawab karena potensi efek tidak langsung (yang ingin saya tingkatkan kesadarannya) pada WebAssembly inti.

Saya pikir WASI bukan desain yang bagus. Pertama, perakitan web yang dirancang untuk mesin virtual web, dan merancang beberapa API untuk kompatibel dengan posix tidak sejalan dengan arah pengembangan. Kedua, cara yang lebih baik untuk memperkenalkan API pihak ketiga adalah dengan mendefinisikan antarmuka (interaksi antara dua domain) sehingga jumlah API dapat dikontrol dan keamanan juga dapat dikontrol.

skenario ekstrim hipotetis lain yang lebih halus dapat menjadi "bagaimana jika seorang aktor yang juga bertanggung jawab atas proposal inti menunda memajukan ini untuk memberikan hasil subkelompok dengan tujuan yang berbeda waktu untuk berkembang di ekosistem yang lebih luas - sementara kami tidak dapat mencegahnya, apakah kami ingin mencegahnya? dia?"

Saya percaya jika ada ketidaksepakatan dalam proposal, pihak yang berbeda dapat membawa kekhawatiran mereka ke CG, yang memiliki kekuasaan atas proposal. Adopsi membutuhkan pengiriman dalam implementasi, tetapi tidak memerlukan pengiriman di semua implementasi (saya pikir dua adalah nomornya, tetapi saya belum melihatnya dalam beberapa saat). Saya tidak yakin bagaimana ini akan memungkinkan seseorang untuk menunda proposal yang bertentangan dengan keinginan orang lain, selama ada implementasi.

@penzn Sayangnya, kami tidak akan berada di sini jika prosesnya sempurna. Sebagai contoh, kita mungkin melihat ketidaksetujuan saya dengan prinsip-prinsip desain WASI. Saya tidak tahu bagaimana mendekati ini dengan benar, karena WASI sebagian besar independen dalam desain, yang dipandang baik oleh mayoritas kontemporer, jadi kekhawatiran gambaran yang lebih besar hanya dapat diangkat di WASI itu sendiri, tetapi kemudian kesan saya adalah bahwa meningkatkan kekhawatiran dengan WASI di WASI sangat kecil kemungkinannya untuk menghasilkan resolusi, karena kebanyakan di WASI tentu ingin WASI tetap apa adanya, yang bisa dimaklumi. Saya telah dikirim kembali ke Jenis Antarmuka misalnya, meskipun itu adalah grup yang sama dan mereka tahu masalah yang saya alami di sana, dan lebih sering daripada tidak apa yang saya tunjukkan adalah "tidak sesuai dengan prinsip-prinsip desain WASI" dan hanya itu. Jadi saya mencoba mengidentifikasi masalah tingkat yang lebih tinggi, yang menurut saya bermuara pada WASI yang dilegitimasi untuk hampir tidak selaras dengan tujuan inti WebAssembly, sementara pada saat yang sama tidak bertanggung jawab atas tujuan inti WebAssembly. Jadi saya menyarankan untuk menyesuaikan prosesnya, karena saya tidak dapat menggunakan prosesnya, atau tidak merasa diberdayakan untuk melakukannya.

Silakan lihat diskusi Keselamatan C API pada pertemuan CG pada 28-04-2020, itu adalah situasi serupa di mana kekhawatiran presenter tidak diselesaikan dalam proposal. Tentu saja, perbedaan dalam hal WASI adalah bahwa itu bukan proposal, tetapi CG harus tetap memiliki otoritas prosedural. Dalam hal keamanan C API, ada masalah konkret yang diangkat yang harus diterima oleh pemenang proposal setelah CG memihak para pembangkang, namun saya yakin Anda dapat hadir tanpa pemungutan suara di akhir juga.

Maaf, tapi saya tidak melihat bagaimana "Keamanan C API" sebanding dengan masalah gambaran yang lebih besar. Bisakah Anda menguraikan? Misalnya, saya merasa bahwa saya memberikan presentasi pro-Web di WASI hanya akan menambah perselisihan. Seperti yang dikatakan @dtig , melakukan itu "tampaknya tidak produktif untuk masalah yang coba diselesaikan WASI".

Dalam debat keamanan C API ada juga ketidaksepakatan tingkat tinggi tentang tujuan dan kebutuhan (apakah pemeriksaan diperlukan untuk API untuk bahasa yang tidak aman), yang diselesaikan dalam diskusi CG. Ini adalah standar terbuka - membuat proposal dan memulai diskusi adalah satu-satunya alat yang benar-benar kita miliki untuk mengubahnya.

Beberapa pemikiran tentang masalah ekosistem: Saya setuju bahwa fragmentasi antara API Web dan server adalah sebuah risiko. Dengan penambahan WASI, kami sekarang memiliki dua set API standar untuk Wasm, dan tanpa jalur yang jelas untuk penyatuan, karena saya pribadi skeptis browser akan mengadopsi WASI dan mengingat keberadaan WASI, kebalikannya tampaknya juga tidak mungkin.

Akan lebih baik untuk Web jika WASI berfokus pada porting Web API ke server. Tapi itu tidak berarti itu akan lebih baik untuk Wasm secara keseluruhan. Saya menghargai perbandingan dengan Node.js dan riwayat API di sana, tetapi saya pikir ini berlaku dua arah: Ya, akan lebih baik jika Node.js menggunakan lebih banyak API Web, tetapi mungkin kesuksesan besar Node.js sebagian karena menambahkan API yang mereka butuhkan terlepas dari Web. Mungkin WASI diperlukan agar Wasm berhasil di server - mengingat betapa berbedanya ekosistem Web dan server mungkin fragmentasi API tidak dapat dihindari.

Itulah salah satu alasan mengapa saya pribadi tidak mengkritik WASI ketika dimulai. Sementara dari sudut pandang Web tidak optimal, mungkin masih diperlukan untuk keberhasilan Wasm di server, yang mungkin baik untuk keberhasilan Wasm secara keseluruhan. (Alasan kedua adalah model keamanan WASI menarik dan mungkin juga membantu Wasm berkembang.)

Secara lebih umum, Wasm diperluas dalam banyak cara selain Web dan server, seperti plugin, solusi sandboxing, blockchain, dan lainnya. Sebagai orang yang sebagian besar bekerja di satu bidang, saya tidak ingin mengkritik orang yang bekerja di bidang lain. Kita seharusnya tidak saling memperlambat.

Saya pikir satu-satunya pengecualian untuk itu adalah bahaya yang sangat serius, fragmentasi atau sebaliknya. Saya tidak melihat bahaya seperti itu saat ini. Meskipun memiliki dua API standar membuat beberapa hal menjadi canggung dan kurang optimal, kita dapat melakukan polyfill server -> Web, dan akhirnya kita juga dapat melakukan Web -> server yang akan membantu. Untuk masalah seperti string, saya melihat pra-impor memungkinkan penggunaan string optimal di Web - yang juga akan membuat fragmentasi API di Wasm lebih jelas, tetapi dalam kasus ini sudah ada sebelumnya karena perbedaan bahasa yang tidak dapat dijembatani. Secara keseluruhan, risikonya nyata dan mengganggu tetapi tampaknya dapat dikelola dan tidak dapat dihindari.

Pikiran yang bagus, @kripken , ini sejalan dengan pemahaman saya tentang alternatifnya.

Mengenai perbandingan Node.js, apa yang saya pikirkan khususnya adalah hal-hal seperti Buffer vs Uint8Array , yang masih bertanggung jawab atas banyak polyfilling (lambat) di Web. Atau cek global vs window yang dapat dihindari di setiap modul portabel lainnya. Atau TextDecoder tidak menjadi global untuk sementara waktu untuk mengurangi waktu startup. Atau crypto.getRandomValues masih belum tersedia secara global. Atau semua jebakan dengan dukungan ESM hingga hari ini. Saya berpendapat bahwa Node.js bisa melakukan lebih baik di beberapa tempat, sementara dukungan untuk fs dll mungkin tidak dapat dihindari.

Di WASI, situasinya tampaknya serupa, di mana kita kemungkinan besar menginginkan sistem file WASI, tetapi kemudian ada API lain yang menyediakan fungsionalitas umum di seluruh ekosistem, API yang penting untuk membuat modul dasar portabel di tempat pertama, di mana saya pikir kita bisa melakukan lebih baik daripada yang kita tuju saat ini. Bayangkan misalnya sebuah modul yang menulis ke konsol ketika terjadi kesalahan, memperoleh waktu saat ini dll., di mana tergantung pada polyfill WASI (penuh) tampaknya berlebihan. Saya membayangkan bahwa beberapa modul masih memerlukan polyfill yang menyertainya untuk (hanya) sistem file WASI di Web, dan saya pikir itu memang dapat dikelola. Saya hanya tidak berpikir bahwa kita berada dalam situasi semua atau tidak sama sekali di sini, tetapi ada banyak ruang untuk kerja sama yang pada akhirnya akan membuahkan hasil "tetapi prinsip-prinsip desain". Argumen saya adalah: Jika kita bisa, kita mungkin harus, dan jika kita perlu sedikit menyesuaikan proses untuk itu, maka kita juga harus melakukannya.

Mengenai pra-impor, saya bukan penggemar berat yang mengandalkan ini untuk interop yang sangat mendasar secara pribadi, karena saya pikir string sangat penting sehingga memecah pada level ini bukanlah yang akhirnya kita inginkan. Misalnya, Anda menyebutkan di tempat lain bahwa ekosistem dengan kebutuhan akan portabilitas pada akhirnya mungkin menyatu untuk menggunakan string JS, bukan karena bagus untuk dilakukan, tetapi karena kebutuhan semata. Saya kira terutama mereka yang tidak setuju dengan saya sebelumnya tidak akan senang dengan hasil seperti itu, termasuk saya sendiri.

Mungkin agak relevan dalam konteks, kutipan dari posting blog terbaru Deno dengan penyebutan terhormat tentang fragmentasi sisi server dan nilai mengikuti API browser:

Memperluas pemrograman web di luar browser bukanlah ide baru. Memang, kami telah melakukannya dengan keberhasilan moderat dalam proyek "Node.js" kami. Tetapi lebih dari satu dekade kemudian, kami menemukan JavaScript sisi server terfragmentasi tanpa harapan, sangat terkait dengan infrastruktur yang buruk, dan diatur oleh komite tanpa insentif untuk berinovasi. Saat platform browser bergerak maju dengan cepat, JavaScript sisi server mengalami stagnasi.

Deno adalah upaya kami untuk menghembuskan kehidupan baru ke dalam ekosistem ini. Untuk menyediakan sistem pemrograman modern dan produktif yang mematuhi API browser. Deno bukanlah sistem monolitik, melainkan seperangkat teknologi yang kami yakini dapat digunakan kembali untuk berbagai kebutuhan. Tidak semua kasus penggunaan JavaScript sisi server perlu mengakses sistem file; infrastruktur kami memungkinkan untuk mengkompilasi binding yang tidak perlu. Ini memungkinkan kita untuk membuat runtime kustom untuk aplikasi yang berbeda: GUI gaya elektron, Fungsi Tanpa Server gaya Cloudflare Worker, skrip tertanam untuk database, dll.

Ini tentu saja tidak persis sama, tetapi mungkin masih ada sesuatu untuk dipelajari dari pelajaran yang mereka pelajari.

Pasti artikel yang relevan, ya. Kutipan kunci lain darinya:

Banyak pengembang, menurut kami, lebih memilih lapisan abstraksi web-first.

Alasan lain mengapa Web -> server polyfilling (seperti yang disebutkan sebelumnya) akan menjadi penting.

Catatan tambahan: Saya telah membuat sketsa blok bangunan untuk menyelesaikan sebagian dari masalah yang saya lihat dengan WASI dan fragmentasi pada tingkat yang penting, sementara itu, bernama System Essentials for WebAssembly , tetapi ingin meminta pendapat Anda tentang apakah sesuatu seperti ini terdengar bagus sebelumnya mengusulkan apa pun (jangan ragu untuk membuka masalah di sana). Jika seseorang melihat nilai di dalamnya seperti saya (atau bahkan ingin menjadi juara bersama / memberikan bimbingan), beri tahu saya. Jika tidak, saya akan tertarik dengan ide-ide alternatif yang akan mencapai efek yang sebanding :)

Dari sekilas ke dokumen Anda, daftar "penting" seluruhnya terdiri dari _capabilities_ sistem. Menyediakannya secara default akan menyiratkan adanya kemampuan ambien, dan dengan demikian akan merusak model sandboxing yang dirancang dengan cermat untuk dibuat oleh Wasm.

Selain itu, tidak ada kemampuan dalam daftar itu yang diharapkan tersedia secara universal, bahkan di seluruh lingkungan yang menampung Wasm saat ini. Misalnya, waktu saat ini (apalagi waktu lokal), atau keacakan, atau pencatatan tidak tersedia pada sistem terdesentralisasi seperti blockchain.

Menyediakannya secara default akan menyiratkan adanya kemampuan ambien

Seperti kehadiran memori, mungkin. Sepertinya tidak begitu berbeda.

dan dengan demikian akan merusak model sandboxing yang dirancang dengan hati-hati untuk dibangun.

Hanya jika memori, atau non-determinisme pada perangkat keras yang berbeda (FP, SIMD santai) juga, saya pikir. Saya tidak bermaksud, dan tidak berpikir dokter melakukannya, "merusak" "desain hati-hati" Wasm.

tidak ada kemampuan dalam daftar itu yang diharapkan tersedia secara universal

Biner Wasm berjalan pada beberapa mesin dengan beberapa VM pada beberapa OS, jadi saya tidak akan setuju di sini. Saya pikir masuk akal untuk mengharapkan ini tersedia secara universal, meskipun kasus penggunaan khusus mungkin ingin membatasi penggunaannya.

Misalnya, waktu saat ini (apalagi waktu lokal), atau keacakan, atau pencatatan tidak tersedia pada sistem terdesentralisasi seperti blockchain.

Katakanlah blockchain misalnya. Ini biasanya melarang matematika floating point mulai hari ini, dan mungkin juga melarang mendapatkan waktu atau memutuskan untuk membuang pesan log, tetapi node masih berjalan di beberapa VM pada beberapa OS. Saya juga akan mengatakan itu tergantung pada kasus penggunaan yang tepat dari buku besar, jadi ada kemungkinan besar kasus penggunaan di mana pembatasan tidak diperlukan. Saya tidak berpikir Wasm dapat menyelesaikan ini dalam arti yang murni. Ekstrem lainnya adalah perangkat IOT dengan memori kurang dari satu halaman, dengan implikasi yang berbeda.

Secara umum saya berpikir bahwa memerangi fragmentasi pada tingkat yang begitu penting itu berharga, dan saya jelas tertarik untuk memikirkan ini, bahkan jika hasilnya adalah sesuatu yang sama sekali berbeda dari yang diuraikan dalam dokumen saya (saya baik-baik saja dengan membuangnya), namun pada akhirnya mencapai sesuatu yang sebanding. Seperti kompromi yang konstruktif namun terinformasi dengan baik. Oleh karena itu, saya ingin meminta pendapat Anda tentang bagaimana kita dapat mencapai ini, bersama-sama, juga secara pribadi karena itu akan membuat saya merasa bahwa ide-ide saya dianggap berharga oleh orang-orang yang saya kagumi karena keahlian teknis mereka.

Bagaimanapun, mungkin lebih baik untuk memindahkan diskusi ini ke repo dokumen saya, atau Discord, atau E-Mail, atau obrolan suara. Jadi tolong lakukan (atau hubungi saya di tempat yang paling cocok), jika itu juga kesan Anda :)

Saya pikir ada nilai dalam tidak memiliki spesifikasi WebAssembly Core mengasumsikan apa pun tentang lingkungan eksekusinya, termasuk bahwa ada OS atau konsep waktu atau logging. Untuk apa pun yang bergantung pada atau bermutasi keadaan di luar semantik formal Wasm, spesifikasi Core mengukir fungsi yang diimpor sebagai pintu keluar semua, tetapi tentu saja tidak menentukan bahwa set impor tertentu akan disediakan.

Secara umum saya pikir memerangi fragmentasi pada level yang begitu penting itu berharga

Saya pikir ini adalah inti dari ketidaksepakatan di utas ini. Secara pribadi, saya merasa sangat yakin bahwa spesifikasi Core Wasm bukanlah tujuan untuk mencoba menyediakan ekosistem terpadu, tetapi ia harus mencoba memberikan abstraksi yang portabel (dan berkinerja) untuk komputasi murni mungkin. Sebagai analogi, baik X86 maupun ARM tidak berusaha menyediakan ekosistem terpadu (atau bahkan ABI terpadu); yang tersisa untuk lapisan abstraksi OS yang ada di atasnya, dan saya pikir model itu juga sesuai untuk WebAssembly.

Meskipun demikian, menghindari fragmentasi ekosistem jika memungkinkan jelas sangat berharga, tetapi saya pikir itu harus dilakukan pada lapisan di atas Wasm Inti. Kandidat yang jelas untuk lapisan penyatuan ekosistem ini adalah WASI. Apakah akan berhasil jika kemampuan penting yang Anda identifikasi disediakan oleh modul WASI yang dirancang khusus untuk bekerja dengan lem minimal baik di dalam maupun di luar Web? Di mana kekurangan fasilitas WASI saat ini untuk waktu dan keacakan?

Mungkin itulah yang dibutuhkan: satu set standar impor _optional_; tersedia di Web, sebagian besar sistem WASI (karena bersifat opsional, dan WASI dapat berjalan di lingkungan tertanam terbatas misalnya), dan tempat mana pun yang _secara opsional_ menyediakan impor standar.

Di Web, itu akan menjadi _seolah-olah_ kode lem JS meneruskannya, tetapi tidak, sistem meneruskannya dan pengembang JS tidak perlu melakukan apa pun, atau hanya harus mencantumkannya berdasarkan nama untuk memilih yang mana tersedia.

Pengembang web dapat menerima begitu saja bahwa ada impor tertentu (atau dipilih di sisi JS), sementara ini tidak memaksa Wasm sendiri untuk memilikinya dalam bahasa tersebut.

Env blockchain mungkin tidak menyediakan impor (opsional) misalnya.

Pengguna harus bertanggung jawab untuk mengetahui di env mana mereka berjalan dan impor apa yang didokumentasikan agar tersedia.

Ini berarti tidak perlunya pengalih kompiler untuk menghasilkan panggilan API yang berbeda.

WASI akan menjadi dua hal: penyedia impor standar, dan penyedia impor khusus server saja.

Saya pikir masalah menyediakan impor standar di Web tanpa JS apa pun adalah masalah yang sedikit berbeda (tetapi @dcodeIO , beri tahu saya jika Anda tidak setuju). Bahkan dengan satu set standar impor untuk digunakan di dalam dan di luar Web, JS API saat ini masih memerlukan penulisan JS untuk mengompilasi dan membuat instance modul, sehingga manfaat marjinal bagi pengembang Web dengan membiarkan beberapa impor implisit akan kecil. Mengingat seperangkat standar impor, mungkin masuk akal jika mereka disediakan secara implisit oleh sesuatu seperti proposal integrasi ESM, tetapi masalahnya di sini adalah bahwa kita belum memiliki seperangkat standar impor tersebut.

@dcodeIO

Saya pikir ide System Essentials menarik, tetapi saya tidak setuju dengan standar baru untuk mereka. Secara optimal mereka bisa masuk WASI (seperti yang dikatakan @tlively ), atau menjadi Web API.

Tentang API Web: Poin wajar dalam tautan tentang mendapatkan zona waktu yang membutuhkan objek Tanggal baru. Itu rumit dalam wasm. Tapi itu mungkin dengan JS Reflect API ( Reflect.construct secara khusus). Kami dapat menambahkan lebih banyak API semacam itu di sisi JS atau Wasm JS API sesuai kebutuhan. Impor masih perlu dideklarasikan, tetapi biaya ukuran kode harus minimal.

Tentang API WASI, saya sangat yakin kita perlu berbuat lebih banyak untuk menjembatani kesenjangan Web/WASI. Menambahkan lebih banyak API ramah-Web ke WASI masuk akal bagi saya pribadi - mungkin mirip dengan System Essentials. Saya menjelaskan kemungkinan arah lain bulan lalu dan menawarkan untuk membuat sketsa detail spesifik jika ada minat, tetapi belum menerima tanggapan dari orang-orang WASI. Umpan balik akan sangat diterima!

Aspek penting bagi saya adalah bahwa tidak boleh ada kode lem yang diperlukan untuk fungsionalitas penting di Web masing-masing fungsionalitas umum di dalam/di luar Web, karena saya percaya bahwa ekosistem yang bergantung pada polyfill wajib untuk fungsionalitas yang sangat mendasar bukanlah yang harus kita perjuangkan untuk. Saya juga berharap bahwa kita dapat menemukan sesuatu yang bekerja dua arah, dengan tidak memerlukan polyfill di Web atau di WASI, untuk menang-menang (walaupun mungkin polyfilling Web API dari Web bisa kurang bermasalah - tapi saya lebih suka melakukan sesuatu untuk keduanya).

Dari situlah ide instruksi "System Essentials" saya yang agak kurang berasal, sebagian besar didasarkan pada pengamatan saya sejauh ini bahwa menambahkan namespace impor mungkin tidak akan terjadi di browser karena alasan yang dikemukakan sebelumnya, jadi itu adalah intuisi saya bahwa mungkin instruksi sebenarnya mungkin menjadi kurang bermasalah, meskipun ada argumen yang baik menentang. Saya setuju dengan poin Anda tentang menjaga inti Wasm "inti", dan berharap ada sesuatu yang lebih baik yang dapat kita lakukan di atas Wasm inti yang berfungsi untuk kedua Web+WASI.

Karena itu, saya tidak terlalu terikat dengan ide khusus saya, dan akan senang dengan apa pun yang mencentang kotak [x] menghilangkan kode lem , baik itu melalui instruksi, namespace impor umum di+dari Web (WASI atau tidak) , atau secara tidak langsung melalui integrasi ESM dan bagian pendukungnya di luar Web, sehingga pada akhirnya kami mencapai [x] lebih sedikit fragmentasi (modul yang sama berjalan baik di dalam maupun di luar Web tanpa polyfilling ketika hanya menggunakan fungsionalitas umum; menggambar garis di Filesystem dan DOM , yang agak spesifik lingkungan). Apakah itu masuk akal? :)

Pikiran lain: Mungkin percakapan kami berguna untuk menginformasikan ide sub-bahasa - katakanlah "profil" untuk "web+wasi" atau semacamnya? Ini kemudian dapat bermuara pada standarisasi persimpangan antara permukaan API sub-bahasa.

Juga, dengan masalah ini terbuka selama hampir satu bulan sekarang, dan sayangnya hampir tidak ada orang IT/WASI yang ikut memperbaiki situasi, saya memutuskan untuk mencoba sendiri dalam analisis konflik.

Saya ingin menekankan bahwa berikut ini sangat subjektif dan benar-benar hanya mewakili model mental saya yang muncul dari lanskap Wasm. Tidak ada yang menyiratkan bahwa ada orang yang melakukan sesuatu yang buruk, hanya saja ada fokus yang berbeda-beda, yang wajar saja. Tolong beri tahu saya jika Anda merasa diperlakukan tidak adil, yang bukan merupakan niat saya, dan saya akan mengoreksi atau menghapusnya.

Tujuan saya adalah untuk mengidentifikasi keselarasan, atau kekurangannya, antara pemain Wasm, baik dalam hal membuat Wasm lebih kaya, yaitu untuk memasukkan lebih banyak fitur dan kasus penggunaan, masing-masing menjaganya tetap murni, yaitu menekan titik ISA minimal, sambil juga memasukkan fokus pada sisi mata uang tertentu, di sini terutama tertarik untuk menjalankan Wasm di Platform Web masing-masing di Edge atau di dalam Blockchain, seringkali dengan persyaratan yang sangat berbeda.

• Browser: Melayani Platform Web, yang sifatnya agak kaya. "OS desktop baru" bisa dikatakan.
• Server: Secara alami relatif barebone seperti dalam "bawa barang-barang Anda sendiri". Netral.
• Penelitian: Ingin membuat Wasm baik untuk semua orang, kecuali terikat dengan aktor lain.
• Google: Berfokus pada porting barang ke Web dan membuatnya cepat; Bolehkah mempertimbangkan kebutuhan orang lain selama itu tidak merugikan mereka?
• Dfinity: All-in di Blockchain; Membutuhkan beberapa fitur kekayaan rupanya; tapi semakin banyak barebone semakin baik?
• Cepat: Berfokus pada tepi; VM ramping/minimal sangat penting untuk produk mereka; Bertanggung jawab secara efektif untuk IT/WASI?
• Apple: Oke dengan apa yang berfungsi untuk Web; Belum tentu ingin bersaing dengan App store?
• AssemblyScript: Menginginkan kepraktisan dunia nyata; Cenderung ke Web tetapi agak kabur karena pemangku kepentingan di Edge/BC?
• Intel?: Sejauh ini tidak banyak tanda; Sebagian besar tertarik pada komputasi yang efisien?
• Redhat?: Sejauh ini tidak banyak tanda; Sebagian besar tertarik pada infrastruktur?
• Microsoft?: Sejauh ini tidak banyak tanda; .NET di Web dan akhirnya di mana-mana?
• Mozilla?: Tidak ada?

Meskipun ini mungkin salah di banyak tingkatan, saya menemukan bahwa itu menggambarkan model mental saya dengan relatif baik. Saya juga telah menarik garis di mana saya akan mempertimbangkan "Web di WebAssembly" untuk ikut bermain dari harapan saya, tetapi sekali lagi ini masih bisa diperdebatkan. Jika ada, saya harap ini membantu untuk memahami dari mana saya berasal dan mengapa saya mendapat kesan bahwa ada sesuatu yang tidak beres di Wasm-land, sementara juga menyoroti situasi bagi mereka yang tertarik dengan pandangan ringkas saya tentang masalah ini. tapi mungkin tidak menyadari setiap detail yang telah terjadi. Ambil, tetapi dengan sebutir garam :)

Dua sen... Saya benar-benar terkejut bahwa percakapan ini pernah terjadi. Itu selalu merupakan ide yang buruk bagi WebAssembly untuk membiarkan ruang lingkupnya ditentukan oleh kasus penggunaan apa pun yang muncul oleh pengadopsi awal.

Web membutuhkan WebAssembly dengan cara yang tidak dimiliki platform lain, karena Web harus membatasi apa yang dapat dilakukan pengembangnya, terutama di tingkat WebAssembly.

Jika WebAssembly berjalan ke arah yang tidak disukai penambang kripto, mereka dapat melakukan fork atau apa pun. Ini bukan sesuatu yang perlu kita perhatikan ketika merancang standar Web. Semua orang memiliki kendali penuh atas platform yang mendasarinya. Di Web, kami hanya memiliki platform yang diberikan kepada kami, dan setelah itu menjadi standar, kami akan terjebak dengannya selamanya.

WASI harus bercabang untuk melakukan tugasnya sendiri, dan Web harus memiliki VM sendiri yang sepenuhnya dioptimalkan untuk browser, secara eksklusif dan khusus.

Itu selalu merupakan ide yang buruk bagi WebAssembly untuk membiarkan ruang lingkupnya ditentukan oleh kasus penggunaan apa pun yang muncul oleh pengadopsi awal.

Sebenarnya ruang lingkupnya ditentukan oleh CG, yang bisa diikuti oleh siapa saja, termasuk Anda. Di sana, orang memilih arah, yang dapat dipengaruhi jika Anda ingin meluangkan waktu untuk aktif di dalamnya, dan menyajikan argumen teknis yang dipikirkan dengan matang.

Siapa pun sudah dapat melakukan fork Wasm jika mereka mau, tetapi ada banyak keuntungan dari ekosistem bersama, jadi itulah yang diinginkan oleh sebagian besar pihak yang berkepentingan.

Setiap orang yang dapat bergabung dengan CG berarti Anda tidak dapat menghentikan orang-orang dengan minat non-Web untuk bergabung, saya khawatir.

Saya benar-benar terkejut bahwa percakapan ini harus terjadi. Itu selalu merupakan ide yang buruk bagi WebAssembly untuk membiarkan ruang lingkupnya ditentukan oleh kasus penggunaan apa pun yang muncul oleh pengadopsi awal.
...
WASI harus bercabang untuk melakukan hal sendiri

WASI _is_ melakukan hal sendiri; itu adalah namespace impor. Itu tidak distandarisasi pada tingkat yang sama dengan fitur bahasa WebAssembly. Apakah saran bahwa kita harus mendeklarasikan fitur non-Web di luar cakupan dan tidak mengizinkan spesifikasi WASI terjadi di bawah payung nominal Grup Komunitas? Apa yang akan dicapai dalam hal mencegah fragmentasi?

Ada manfaat untuk menyelidiki apakah bagian-bagian tertentu dari WASI dapat diubah menjadi lebih rapi (baik Web->WASI, atau WASI->Web seperti yang dijelaskan oleh @kripken di sini ), tetapi bahkan dalam kasus terburuk, kita hanya berakhir dengan API yang tidak dapat diimpor ke Web, persis seperti WASI yang diselesaikan sebagai proyek pihak ketiga untuk runtime non-Web.

Sekali lagi, membaca masalah yang ditautkan @dcodeIO , saya tidak melihat siapa pun yang menganggap Web tidak penting untuk WebAssembly. Yang saya lihat adalah orang-orang tidak setuju (kadang-kadang tidak sopan) pada fitur/peta jalan untuk memecahkan gesekan interop yang cukup spesifik seperti pengkodean string. Saya sangat yakin bahwa adalah suatu kesalahan untuk menggolongkan ketidaksepakatan teknis ini sebagai bukti perebutan kekuasaan Web vs non-Web, dan hal itu tidak akan menghasilkan hasil yang positif.

Saya tidak melihatnya sebagai perebutan kekuasaan, melainkan masalah dengan ruang lingkup yang terlalu luas dan efektif terbuka. World Wide Web cukup penting untuk memiliki VM sendiri, dengan spesifikasi dan standarnya sendiri, dengan persyaratannya sendiri, dan menggunakan nomenklaturnya sendiri. Upaya untuk membuat semuanya umum dan abstrak telah menghasilkan spesifikasi, dokumentasi, dan percakapan yang tidak biasa dan sering kali asing bagi pengembang web.

Untuk lebih jelasnya, isu WASI menjadi proyek resmi murni simbolis. Tidak ada perbedaan teknis, tetapi statusnya memperjelas bahwa Web menggunakan WebAssembly, tetapi itu bukan teknologi yang dibuat oleh dan untuk Web.

Saya tidak melihatnya sebagai perebutan kekuasaan...

@7ombie minta maaf, paragraf terakhir saya dimaksudkan untuk mengomentari diagram "konflik" di atas .

Upaya untuk membuat semuanya umum dan abstrak telah menghasilkan spesifikasi, dokumentasi, dan percakapan yang tidak biasa dan sering kali asing bagi pengembang web.

Saya setuju bahwa beberapa harapan teknis seputar jenis antarmuka secara khusus telah menjadi sangat esoteris. Tentu saja ada ruang di CG untuk percakapan seperti "mengapa tipe antarmuka daripada tipe string kelas satu", dan kami mengandalkan pengembang yang berpusat pada Web seperti @dcodeIO untuk membagikan pendapat dan kekhawatiran mereka agar proses tetap berjalan. Saya kecewa dengan cara percakapan terakhir tentang ini berakhir, dan saya harap kita bisa melakukan yang lebih baik di masa depan.

Dimengerti, @conrad-watt. Saya belum pernah melihat percakapan itu, tetapi untuk bagian saya, saya tidak ingin bermain di Web Vs. pola pikir non-Web, atau semacamnya. Saya hanya berbagi keluhan pribadi dengan teknologi yang secara umum sangat saya senangi, senangi, dan syukuri.

Komentar saya sebelumnya cukup kritis dan terang-terangan, tetapi saya hanya bersikap biasa saja. Aku tidak kecewa.

@conrad-watt dkk. Deskripsi teknis Jenis Antarmuka kemungkinan akan menjadi lebih esoteris sebelum menjadi kurang begitu dalam waktu dekat. Sebagai penjelasan, banyak dari ini didorong oleh keinginan untuk menggabungkan kegunaan kembali dengan ketelitian.

Saya ingin menekankan bahwa saya juga melihat nilai dalam bekerja sama (dengan WASI dan lainnya) sebanyak yang kami bisa, oleh karena itu saya menyarankan untuk menyelidiki solusi yang mengarah pada portabilitas antar ekosistem dengan cara menutupi persimpangan, termasuk di mana saya 'd saat ini menarik garis (DOM, Filesystem). Saya sadar bahwa apa yang saya sarankan mungkin sulit, atau mungkin ada cara yang lebih baik untuk mencapai sesuatu yang sebanding (beri tahu saya! :)). Hanya saja (mengutip diri saya sendiri di OP)

Saya menjadi sangat khawatir bahwa kita, sebagai sebuah komunitas, tidak melakukan apa yang diperlukan untuk memastikan kompatibilitas yang sangat baik dengan Web, sementara pada saat yang sama menoleransi proposal baru dan teknologi terkait untuk merusak kompatibilitas dengan Web terlalu banyak, atau sebaliknya mempengaruhinya negatif, langsung, atau tidak langsung.

membuat saya menyarankan untuk mengevaluasi kembali tujuan kami dengan menjelaskan bahwa

Kompatibilitas dengan Open Web Platform secara umum, dan Web API dan JavaScript pada khususnya, sangat penting untuk kesuksesan jangka panjang WebAssembly, dan tidak boleh dikompromikan jika dapat dihindari. Bilah sangat tinggi untuk proposal yang mempromosikan fungsionalitas yang tidak terutama menargetkan Web, karena mungkin ada sedikit insentif untuk tidak memengaruhi tujuan ini secara negatif.

Saya tidak terikat untuk menjadikan ini persyaratan untuk proposal (seperti yang diisyaratkan ini mungkin terjadi) lagi seperti saya di OP, karena saya setuju dengan banyak poin yang diangkat, tetapi masih akan menghargai upaya terkonsentrasi yang secara efektif mengubah kita ke arah itu.

@dcodeIO , apa item diskusi yang mungkin dalam analisis konflik Anda, apakah semua perusahaan yang Anda daftarkan perlu mengungkapkan dan membandingkan rencana mereka? Apakah menurut Anda itu mungkin dan apa yang akan dicapai?

Meskipun tidak dapat mengomentari salah satu perusahaan di bagan Anda, saya pikir membandingkan mereka seperti ini menyesatkan, karena tidak ada satu pun entitas yang dapat mengubah standar untuk diri mereka sendiri tanpa persetujuan orang lain. Saya juga menemukan sumbu bagan menjadi subjektif dan membingungkan. Misalnya, menjalankan komputasi (katakanlah rendering atau NN) di wasm di web harus "tepi", karena itu memindahkan komputasi dari "awan", tetapi kemudian juga harus "web", karena itu adalah bagian penting web interaktif sekarang (dan jelas bukan "server", karena berjalan di mesin klien). Dimensi lain bahkan lebih subjektif IMO, karena kemurnian dan kekayaan dalam definisi Anda adalah istilah relatif. Contoh - ada diskusi yang sangat panjang tentang pembatasan aliran kontrol yang dimotivasi oleh konvensi pemanggilan Go. Bergantung pada siapa Anda bertanya, pembatasan itu akan dilihat sebagai fitur yang berguna atau tidak perlu, yang menurut saya akan memengaruhi di mana orang itu akan menempatkan diskusi pada sumbu "kaya vs murni".

Untuk mengajukan pertanyaan langsung, apakah arah jangka panjang WebAssembly ditentukan oleh siapa pun yang mengadopsinya? Misalnya, jika dalam jangka panjang, adopsi oleh pengembang web rendah, tetapi ada pemain industri besar dengan miliaran yang diinvestasikan dalam menggunakan WebAssembly untuk sesuatu yang tidak terkait dengan Web, apakah kebutuhan mereka pada akhirnya akan diprioritaskan?

Untuk mengajukan pertanyaan langsung, apakah arah jangka panjang WebAssembly ditentukan oleh siapa pun yang mengadopsinya? Misalnya, jika dalam jangka panjang, adopsi oleh pengembang web rendah, tetapi ada pemain industri besar dengan miliaran yang diinvestasikan dalam menggunakan WebAssembly untuk sesuatu yang tidak terkait dengan Web, apakah kebutuhan mereka pada akhirnya akan diprioritaskan?

Kami adalah standar yang didorong oleh komunitas/konsensus. Tidak banyak gunanya mempertimbangkan situasi hipotetis ini, karena pada dasarnya mereka tidak dapat dilindungi oleh prosedur formal apa pun. Selamat datang di kecemasan eksistensial pembangunan komunitas/konsensus.

Ya, jika satu-satunya orang yang peduli dengan Wasm adalah insinyur komputasi edge hardcore, kemungkinan bahasa tersebut akan diarahkan ke arah itu. Dalam skenario ini, bahkan jika kami entah bagaimana berhasil mengukir prinsip bahwa hanya fitur yang kompatibel dengan Web yang dapat distandarisasi di CG, ini hanya akan menghasilkan percabangan, atau tidak ada yang mengerjakan bahasa tersebut.

Untuk lebih jelasnya, saya sama sekali tidak percaya bahwa ini adalah situasi yang kita hadapi. Seseorang harus percaya bahwa kepentingan Web diwakili secara memadai oleh anggota CG, atau terlibat sendiri.

Lihat, ini adalah sesuatu yang saya tidak mengerti. Tujuannya jelas untuk menghasilkan standar Web pada akhirnya, di bawah payung W3C, yang memiliki prinsip dan nilai yang sangat jelas dan banyak pengalaman dari sejarah panjang tantangan serupa. Saya tidak melihat bagaimana Web terkemuka dan semua orang dengan garpu menyelaraskan dengan apa yang orang Web datang dengan, jika itu yang mereka inginkan, akan lebih buruk. Jadi ya, saya menyarankan untuk membuat WebAssembly untuk Web terlebih dahulu, dan untuk yang lainnya kedua, karena kebalikannya adalah situasi yang tak tertahankan jika pengalaman saya sejauh ini bernilai sesuatu. Apa pun yang diperlukan, kita harus mempertimbangkan dan membicarakannya, karena itu menurut saya akar penyebab masalahnya.

Seperti yang saya katakan di atas, sementara saya setuju bahwa Web harus menjadi prioritas untuk WebAssembly, saya tidak percaya bahwa perselisihan teknis yang Anda alami dengan anggota CG lainnya terutama disebabkan oleh perpecahan faksi Web vs non-Web . Ada alasan mengapa bahkan orang yang hanya berfokus pada Web ingin mencari alternatif dari beberapa proposal Anda, dan Anda tidak boleh menafsirkan ini sebagai bukti bahwa orang yang tidak setuju dengan Anda tidak peduli dengan Web.

WASI tidak akan menjadi spesifikasi W3C, dan tidak mengganggu produksi spesifikasi W3C WebAssembly kami. Menyatakan bahwa WASI tidak boleh dikembangkan di bawah CG karena "non-Web" tidak akan membuat orang-orang yang terlibat mengalihkan perhatian mereka ke Web. Itu hanya akan menutup jalur komunikasi dan kolaborasi yang berharga, yang mungkin (misalnya) memungkinkan kami menemukan tumpang tindih dengan beberapa API ramah-Web hipotetis.

Poin yang adil, tetapi kami pada dasarnya tidak setuju saat itu, karena saya tidak dapat mendamaikan sudut pandang Anda dengan semua yang telah saya lalui. Saya pikir sudah ada indikasi yang sangat jelas bahwa masalahnya ada dan harus diatasi daripada terus-menerus mengatakan kepada saya bahwa tidak ada yang bisa kita lakukan untuk mengatasinya. Bagi saya ini tampak tidak masuk akal, sampai pada titik di mana orang harus malu dengan apa yang mereka lakukan pada WebAssembly, yang pernah menjadi bintang paling terang di antara standar Web yang jelas tidak sesuai dengan apa yang telah terjadi sebelumnya.

Saya pikir sudah ada indikasi yang sangat jelas bahwa masalahnya ada dan harus diatasi daripada terus-menerus mengatakan kepada saya bahwa tidak ada yang bisa kita lakukan untuk mengatasinya.

Saya pikir kita gagal untuk memahami masalah, daripada memutuskan bahwa tidak ada yang bisa dilakukan tentang hal itu. Ada minat yang jelas untuk meningkatkan WASI atau jenis antarmuka, tetapi tampaknya tidak ada konsensus tentang hal-hal yang pada dasarnya rusak atau salah.

Terima kasih telah membuka kunci masalah :) Saya ingin meminta maaf atas kehancuran saya di sini, yang tidak baik-baik saja dan saya berharap jauh lebih baik dari diri saya sendiri. Saya ingin terus terlibat dengan grup, termasuk mendiskusikan masalah penting ini (menurut saya), dan saya berharap dapat menunjukkan bahwa saya dapat melakukan ini dengan cara yang konstruktif.

Sebagai permulaan, saya telah mengusulkan presentasi tentang kekhawatiran saya tentang pengkodean string, dan di mana saya pikir itu relevan untuk langkah selanjutnya dalam Jenis Antarmuka masing-masing pengembangan yang lebih baru menuju Model Komponen. Dan dalam prosesnya, kami akhirnya memutuskan untuk mencoba format baru dari presentasi yang telah direkam sebelumnya, dengan waktu diskusi yang dijadwalkan untuk pertemuan video CG 22 Juni. Rekamannya dapat ditemukan di edisi terlampir yang ditautkan tepat di atas komentar ini, dan saya harap ini membantu memberikan latar belakang yang diperlukan dengan cara yang lebih padat dan konstruktif.

Jika saya dapat menawarkan saran ringan: Jika seseorang mengkompilasi ulang bagian non-WASM dari kode sumber browser web di Binaryen atau Rust, menargetkan WASI di desktop, apakah cukup untuk mengatakan bahwa sebagian besar browser hanya polyfill besar atau hanya akan mengubah argumen ke dalam dirinya sendiri, menyebabkan keruntuhan bencana dan mengubah Bumi menjadi lubang hitam?

Pada catatan serius: IIRC, web dimulai sebagai dokumentasi hyperlink dari direktori telepon Sir Tim Berners-Lee di CERN. Web itu sendiri telah melampaui semua harapan termasuk kompleksitas dan konsumsi memori. Peramban web telah berevolusi dari penampil dokumen menjadi media penerbitan keseluruhan. Itu adalah fitur-creep.

WASI, sebagai lingkungan pemrograman, memiliki potensi untuk mengembalikan teknologi web ke akarnya sebagai cabang ilmu komputer tempat penerbitan dan interaktivitas bergabung. Sejak kapan chatroom harus berjalan di browser untuk menjadi teknologi web? IRC, protokol obrolan asli, telah ada lebih lama dari yang dimiliki browser web. Demikian juga, SMTP mendahului WWW dan begitu pula FTP. Internet lebih besar dari sekedar web dan begitulah seharusnya.