Hacker News Reader

At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency:

https://github.com/WebAssembly/component-model/blob/main/des...

View on HN

The concurrency part of the C-M is complicated (I think for inherent reasons), but won't be exposed to end users. It's basically defining an API that language toolchains can use to coordinate concurrency.

For end users, they should just see their language's native concurrency primitives (if any). So if you're running Go, it'll be go routines. JS, would use promises. Rust, would have Futures.

Real programs, whether native JavaScript or in any other language that targets Wasm, have concurrency. Would you rather the component model exclude all concurrent programs, and fail to interact with concurrent JavaScript? The component model is meeting the web and programmers where they're at. Unless you're one of the few people implementing the low level bindings between components and guest or host languages, you don't have to ever read the CM spec or care about the minutae of how it gets implemented.

I was looking there because the high-level documentation doesn't seem detailed enough to understand how it works. Maybe some intermediate-level explanations are needed?

Reply on news.ycombinator.com