Minor tweaks

blogs/2024/06/06/wasm-part2.md

@@ -35,9 +35,9 @@ async function main(): Promise<void> {
 main().catch(RAL().console.error);
 ```
 
-All the code does is create a connection to communicate with the extension host main worker and initialize the connection with the `calculator` world generated by the `wit2ts` tool.
+The code creates a connection to communicate with the extension host main worker and initializes the connection with the `calculator` world generated by the `wit2ts` tool.
 
-On the extension side, all we need to do is load the WebAssembly module and bind it to the world. The corresponding calls to perform the calculations need to be awaited since the execution happens asynchronously in the worker (for example, `await api.calc(...)`).
+On the extension side we load the WebAssembly module and bind it to the `calculator` world as well. The corresponding calls to perform the calculations need to be awaited since the execution happens asynchronously in the worker (for example, `await api.calc(...)`).
 
 ```typescript
 // The channel for printing the result.
@@ -84,8 +84,8 @@ vscode.commands.registerCommand('vscode-samples.wasm-component-model-async.run',
 There are a couple of important things to note:
 
 - The WIT file used in this example is no different from the one used for the [calculator example](https://code.visualstudio.com/blogs/2024/05/08/wasm#_a-calculator-in-rust) in the previous blog post.
-- Since the execution of the WebAssembly code happens in a worker, the implementation of imported services (for example, the `log` function above) can return a `Promise` as well, but they don't have to.
-- Every call from the worker that executes the WebAssembly code to the extension host main thread requires synchronizing the two workers using `Atomics.wait` and `Atomics.notify`. This synchronization adds overhead, so the imported API should be designed with this constraint in mind.
+- Since the execution of the WebAssembly code happens in a worker, the implementation of imported services (for example, the `log` function above) can return a `Promise` as well, but it doesn't have to.
+- Every call from the worker that executes the WebAssembly code to the extension host main thread requires synchronizing the two workers using `Atomics.wait` and `Atomics.notify`. This synchronization adds overhead. The imported API should be designed with this constraint in mind.
 
 You can find the full source code for this example in the [VS Code extension sample repository](https://insiders.vscode.dev/github/microsoft/vscode-extension-samples/blob/main/wasm-component-model-async/src/extension.ts#L1).
 
@@ -233,11 +233,11 @@ Running this on the `vscode-languageserver` repository shows the following notif
 
 ![Running count all files](count-files.png)
 
-It should also be highlighted that a language server doesn't necessarily need to implement any of the features specified in the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) specification. If an extension wants to integrate library code that can only be compiled to the WASI Preview 1 target, implementing a language server with custom messages might be a good choice until VS Code supports the WASI 0.2 preview in its component model implementation.
+Please note that a language server doesn't necessarily need to implement any of the features specified in the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) specification. If an extension wants to integrate library code that can only be compiled to the WASI Preview 1 target, implementing a language server with custom messages might be a good choice until VS Code supports the WASI 0.2 preview in its component model implementation.
 
 ## What Comes Next
 
-As mentioned in the previous blog post, we continue our efforts to implement the WASI 0.2 preview for VS Code. We also plan to broaden the examples to include other languages that compile to WASM.
+As mentioned in the previous blog post, we continue our efforts to implement the WASI 0.2 preview for VS Code. We also plan to broaden the code examples to include languages other than Rust that compile to WASM.
 
 Thanks,