Apply suggestions from code review

Co-authored-by: Iwan <[email protected]>

Author: bobzhang

_blogposts/2020-09-25-release-8-3-2.mdx

@@ -40,22 +40,23 @@ Note such vertical integration not only brings better performance, smaller sizes
 
 ## Build system enhancements for editor diagnostics
 
-When people are coding in their favorite editors, they expect the editor to deliver the feedback loop in real-time, for example, 
+When people are coding in their favorite editors, they expect to see syntax and type errors in real-time.
+There are multiple ways to achieve this. The most and reliable way is to always invoke the build system whenever the user saves a file. Due to not having an in-memory cache, our build system is very reliable. However we didn't yet optimize the build system for live feedback in editors.
 what syntax errors, type checking errors do they have when editing? There are multiple ways to achieve this, the most easy 
 and reliable way is to always invoke the build system whenever the user saves the files, since it's the same build system 
 without any in-memory cache, the reliability is very high, however, there's several challenges to use the build system output as editor diagnostics.
 
-### The build system/compiler has to be fast to deliver feedback loop in one hundred milliseconds for typical projects
+### The build system/compiler has to be fast to deliver real-time feedback
 
-Our build system is fast enough to deliver feedback loop for reasonable sizes of projects, 
+Our build system is fast enough to deliver feedback for reasonable sized projects in less than 100ms.
 thanks to our previous [hard work](/blog/scalable). We continue improving 
-the build performance during each release, we believe such approach is reliable using our build tools.
+Pushing the limits of performance in the build system allows us to provide real-time feedback in editors.
 
 ### The warnings for each file should not be flushed during a rebuild
 
 For a typical file based build system, if the file A is compiled successfully with some warnings, the rebuild will not build A anymore.
-This is problematic if we use the build system output as editor diagnostics. Since the second build will not capture those warnings, we 
-could use some caching mechanism to cache previous build output, but it will render such system stateful and not reliable.
+This is problematic if we use the build system output for editor diagnostics. Since the second build will not capture those warnings, we 
+could use some caching mechanism to cache previous build output. But… stateful systems are not reliable and come with a whole range of different problems.
 
 To solve such challenging problem, we did some innovations to co-ordinate the compiler and build system. When the file A is compiled with warnings, 
 the compiler will produce some marks to the build system, the build system will keep building but such marks are encoded in the build rules
@@ -66,42 +67,44 @@ The benefit is two fold:
 - Rebuild will re-capture those warnings
 - Rebuild will be fast since only those files with warnings get rebuilt, it will not trigger unnecessary builds since our build is [content-based](https://rescript-lang.org/blog/scalable) build system.
 
-The integration between compiler and build system is encoded in a specialized protocol so that this new feature's almost cost-free.
+The integration between compiler and build system is encoded in a specialized protocol. This makes it almost cost-free.
 
-### A tiny client notification via .comipler.log
+### Notifying clients through .compiler.log
 
-To get the build output, instead of communicating with IPC, we adopted a simple protocol, whenever a build is done, we wrote the output to a file called `.compiler.log`.
+To get the build output, instead of communicating through IPC, we adopted a simple protocol. Whenever a build is done, we write the output to a file called `.compiler.log`.
 This makes the editor integration build-system agnostic, it does not need talk to the build system directly.
 
-It also makes our build tool can work with other watchers including Facebook's [watchman](https://facebook.github.io/watchman/).
-Watchman is  a more scalable watcher tool for specific platform and less memory hungry, however, we still need a watchman-client to get the output of triggerred job.
-Now since we write the output to `.compiler.log` per each build, such client is available for free.
+It also makes our build tool work with other watchers including Facebook's [watchman](https://facebook.github.io/watchman/).
+Watchman is  a more scalable watcher tool for specific platform and less memory hungry, however, we still need a watchman-client to get the output of triggered job.
+We write the output to `.compiler.log` per each build, allowing clients to read compiler diagnostics when they want.
 
 ## A better algorithm for removing stale outputs
 
-Whenever we do some renaming from `a.res` to `b.res`, the output caused by `a.res` will be stale output. Thanks to the deeper integration of the build system and compiler, 
-we employ a more advanced strategy to remove stale outputs in this release, such pruning stale outputs is done in the beginning of each build.
+Whenever we rename a file, e.g. `a.res` to `b.res`, will lead to the output of `a.res` being stale. Thanks to the deeper integration of the build system and compiler, 
+we employ a more advanced strategy to remove stale outputs in this release. Pruning stale outputs is done in the beginning of each build.
 
-There're two  ways of removing staled artifacts, the second one is introduced in this release:
+There are two ways of removing staled artifacts, the second one is introduced in this release:
 
-- Based on live analysis and  prebuilt-in knowledge
+- Based on live analysis and prebuilt-in knowledge
 
 We scan `lib/bs` directory and check some dangling cm{i,t,j,ti} files, if it does not exist in 
 the current build set, it is considered stale artifacts. If it is `cmt` file, it would trigger some hooks of `genType`, notably -cmt-rm. 
 
 - Based on previous build logs
-We stored previous compilation stats, so that for a file, if it is previous output, but no longer a output of the new build, 
+We store previous compilation stats.  If a file is in the previous compiler output, but no longer in the output of the new build, it is considered stale and can be removed.
 it is considered stale output which can be removed.
 
-In general, the new introduced strategy 2 is more reliable and efficient.
+In general, strategy two is more reliable and efficient.
 
-- We don't need redo the path calculate since it's already done by the build system.
+- We don't need to recompute the path since it is already done by the build system.
 - When we change the in-source build to out-source build, it will still do the pruning properly
 
-however, the former could be more customized for other buid system not aware systems including `genType`,
+However, strategy one is easier for tooling like `genType`. Not every tool has knowledge of the build system.
 we employ a combination of the two strategies.
 
-When removing js outputs, we use strategy two, when removing .cm* files, we use the first strategy.
+Sometimes a combination of both strategies is needed.
+- When removing .cm* files, we use the first strategy.
+- When removing generated javascript, we use strategy two,