A modern programming language that makes developers happier.

kotlinlang

Does anyone know what the workflow will look like in the future for a codebase generating wasm binaries:

• Will the compiler always generate a component? or potentially modules in certain specific scenarios?
• When working with modules we simply annotated Kotlin source with @WasmExport, will there be a similar annotation for components or is the expectation the user will need to provide their own WIT interface and bind to it?

> Will the compiler _always_ generate a component?
The answer to the "always" part is most definitely no, for the Wasm/JS subtarget in particular. Browsers in particular don't support the component model yet, and while there is some stuff going on there afaik, even if they started supporting it tomorrow, we couldn't switch everyone over to that because we need a grace period for browser support. So, speaking personally, not on behalf of the company, I would be very surprised if we drop Wasm core module emission in the next 5 years,  and personally think it won't be dropped at all for a long time in general.

For Wasm/WASI, the thing is that a valid WASI 0.2 program _has_ to be a component, and if we don't provide some of that to you, it's very hard to reconstruct it from a core module, because that requires the exact WIT that the stdlib uses to implement stdlib functions like `println`, etc. But most likely, we'll just provide the core module as well, as the compiler output itself will remain a core module for the foreseeable future; feel free to follow <https://youtrack.jetbrains.com/issue/KT-87723|KT-87723> on how we plan to get components from our core modules, from a tooling perspective.

> will there be a similar annotation for components
Providing that would be our preferred solution, but is way harder to do than it might sound. To actually be interoperable with other Wasm component tooling, runtimes, etc. (which is the whole point, after all), we will essentially have to map some subset of the Kotlin typesystem to WIT either automatically, or through user-provided annotations or some kind of DSL; if we don't provide that, no other tooling would know what the hell our high-level types are, and couldn't actually run the function.
To actually make components highly usable, we are planning on providing _something_ of that sort, so that ideally, you don't have to know WIT to export something to a component. But that is a bit far away, as we first have to get to a stage where WIT itself does work properly and has nice support, so that you only have to provide the source and we generate the bindings for you automatically, etc.

> or is the expectation the user will need to provide their own WIT interface and bind to it?
So for now, enabling people to do this comfortably (basically hiding as many implementation details of the prototype that's currently available) is our main priority, as that will be necessary regardless :)