похоже вот так:
https://github.com/CraneStation/wasi-sysroot/blob/320054e84f8f2440def3b1c8700cedb8fd697bf8/libc-bottom-half/headers/public/wasi/core.h#L451

https://reviews.llvm.org/D57160

Fluence тоже на AssemblyScript продолжает писать, к слову :)

шта? вебсокеты работают по tcp

https://github.com/libp2p/rust-libp2p/pull/971
например

libp2p - это transport agnostic протокол

именно поэтому он не может заменить как tcp, так и websocket =)

ну, на уровне API имеется ввиду )

а реальный протокол можно определить как раз handshake'ом

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

чтобы не юзать низкоуровневые

Изучая пейперы по самым навороченным GC я пришел к выводу, что универсального GC не существует, либо у тебя будут низкие паузы, либо   низкие накладные расходы ну или дикие расходы по памяти из-за фрагментации. Поэтому нет смысла делать что то гиперсложное. Наиболее оптимальный вариант - это статический range analysis + RC для acyclic ссылок и GC для циклических ссылок. Ну и дать возможно пользователю тюнинговать GC

либа сама может заняться хендшейком по разным протоколам одновременно

это не тоже самое, что договориться по протоколу изначально

а можно плагибал интерфайс

?

есть отдельные gc со своими abi если ты об этом

к ним можно прикрутить примитивы и структуры разных языков

но обычно такие гц говно

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

еще есть языки разного назначения