Apply suggestions from code review

Co-authored-by: Michał Pałka <[email protected]>

Author: Kordyjan

blog/_posts/2022-01-17-scala-3.1.1-released.md

@@ -13,7 +13,7 @@ Scala 3.1.1 is the patch release focused on bug fixes. Although there are no new
 
 - You can use `using` clauses to introduce subtyping relations between types in the function body.
 
-  Now, the code like below should compile. Any value of type `A` can be assigned to a value of type `B`:
+  Now, the code like below should compile. Any value of type `A` can be used where a value of type `B` is expected as long as a given instance of `A <:< B` is in scope:
 
   ```scala
     def example[A, B](a: A)(using A <:< B) =
@@ -30,19 +30,19 @@ For a comprehensive list of fixes, take a look at [the full changelog on GitHub]
 
 ## 3.1.2-RC1 and forward compatibility improvements
 
-Together with 3.1.1 we have released first RC version of next patch release of the compiler. 3.1.2-RC1 contains further fixes, but most importantly it is our first step in improving forward compatibility in scala.
+Together with 3.1.1 we have released the first RC version of the next patch release of the compiler. 3.1.2-RC1 contains further fixes, but most importantly it is our first step in improving forward compatibility in Scala.
 
-Scala 3 has excellent backward compatibility guarantees between the minor versions. Right now, that means that code compiled with Scala 3.1 can depend on libraries published with 3.0 without any problems. The opposite, hovewer, is not true. Code compiled with 3.0 is not able to read dependencies compiled with 3.1. After the recent release of Scala 3.1.0, we can see that the libraries should be really cautious with updating the compiler version, as it is forcing the bump on every user of that library. We do not want library authors to be stuck on old versions of the compiler as that would mean that they are locked out of many bugfixes, or we would need to spend enormous effort on backporting every bugfix to all past versioning lines.
+Scala 3 has excellent backward compatibility guarantees between the minor versions. Right now, that means that code compiled with Scala 3.1 can depend on libraries published with 3.0 without any problems. The opposite, hovewer, is not true. Code compiled with 3.0 is not able to read dependencies compiled with 3.1. After the recent release of Scala 3.1.0, we can see that libraries should be really cautious with updating the compiler version, as it forces a bump on every user of that library. We do not want library authors to be stuck on old versions of the compiler as that would mean that they are locked out of many bugfixes, or we would need to spend enormous effort on backporting every bugfix to all past versioning lines.
 
-We are sure we want to mitigate those difficulties. We already have implemented the first and most important part of the solution and have it ready for public testing. Beginning in Scala 3.1.2-RC1 compiler is able to generate output that can be consumed by older versions. To enable that, you need to specify a minimum version of the language using the experimental `-Yscala-release` flag.
+We are sure we want to mitigate those difficulties. We already have implemented the first and most important part of the solution and have it ready for public testing. Beginning with Scala 3.1.2-RC1 the compiler is able to generate outputs that can be consumed by its older versions. To enable that, you need to specify the minimal targeted minor language version by using the experimental `-Yscala-release` flag.
 
-We expect that in the future authors will use the newest available version of the compiler with `-Yscala-release` set to the lowest language version that support all features they need. This way they will be able to benefit from the all bugfixes without restricting their potential audience.
+We expect that in the future authors will use the newest available version of the compiler with `-Yscala-release` set to the lowest language version that support all features they need. This way they will be able to benefit from all the bugfixes without restricting their potential audience.
 
 So, for example, compiling your library using Scala 3.1.2-RC2 with `-Yscala-release:3.0` flag, you make it possible for people still using Scala 3.0 to depend on your library. This has one limitation, you won't be able to use any symbol added to the standard library after 3.0. They are marked in the code and in the documentation by the `@since` annotation that was also added in this version.
 
 One important note is that the `-Yscala-release` flag is experimental and not yet available in any stable release of the compiler. It means the build tools, such as SBT or Mill, are not yet aware of its existence. Of course, you can declare usage of the flag in your build file, and the compiler will respect it. However, there may still be some hiccups, like generated artifacts depending on the incorrect version of the stdlib. We will do our best to help fix those minor issues before the stable release of 3.1.2.
 
-You can read about potential next steps and leave your feedback in [the discussion](https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298) that initiaded this change.
+You can read about potential next steps and leave your feedback in [the discussion](https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298) that initiated this change.
 
 If you are interested in other changes brought by 3.1.2-RC1, there is, as always, [a changelog on GitHub](https://github.com/lampepfl/dotty/releases/tag/3.1.2-RC1).