Fix typos

Author: WojciechMazur

blog/_posts/2024-08-21-scala-3.5.0-released.md

@@ -27,7 +27,7 @@ Given the following file named `biggerThan.scala`
     .foreach(println)
 ```
 
-We can run `scala biggerThan -- ../my-directory 10`. This will download os-lib and its transitive dependencies, compile the source code, and finally run the compiled program, printing all files in `../my-directory` bigger than 10 kB. Subsequent invocations of the command will use cached bytecode, or if the source code changed, trigger incremental compilation.
+We can run `scala biggerThan.scala -- ../my-directory 10`. This will download os-lib and its transitive dependencies, compile the source code, and finally run the compiled program, printing all files in `../my-directory` bigger than 10 kB. Subsequent invocations of the command will use cached bytecode, or if the source code changed, trigger incremental compilation.
 
 As os-lib is a part of the default Scala Toolkit, we can replace `//> using dep com.lihaoyi::os-lib:0.10.3` with `//> using toolkit default`. Furthermore, we can add  `#!/usr/bin/env -S scala shebang` at the top of the file. Then, after setting the permissions (`chmod +x biggerThan.scala`), we can treat `biggerThan.scala` like any executable script. Invoking `./biggerThan.scala ../my-directory 10` will incrementally compile the file and then run it.
 
@@ -78,7 +78,7 @@ assert(0B_1000_0010 == 0x82)
 
 ### Experimental: named tuples
 
-Scala 3.5 introduces experimental support for named tuples. The feature hidden behind the `language.experimental.namedTuples` import, allows you to give meaningful names to tuple elements and use those nemes during constructing, destructuring, and pattern matching.
+Scala 3.5 introduces experimental support for named tuples. The feature, hidden behind the `language.experimental.namedTuples` import, allows you to give meaningful names to tuple elements and use those names during constructing, destructuring, and pattern matching.
 
 ```scala
 import scala.language.experimental.namedTuples
@@ -99,15 +99,15 @@ This is an implementation of [SIP-58](https://github.com/scala/improvement-propo
 
 ## Work on a better scheme for given prioritization
 
-Givens in Scala 3 have a peculiar problem with prioritization. The compiler tries to always select the instance with *the most specific subtype* of the requested type. This can lead to confusing situtaions, when user faces ambiguity errors in code that should intuitivel work. Changing the scheme of given priritization to always select the instance with *the most general subtype* that satisfies the context bound, would resolve such cases. We have conducted experiments that showed that the proposed scheme will result in a more intuitive and predictable given resolution. The negative impact on the existing projects is very small. We have tested 1500 open-source libraries, and new rules are causing problems for less than a dozen of them. We have already submitted PRs with changes that will make them work the same way under both the current and proposed rules.
+Givens in Scala 3 have a peculiar problem with prioritization. The compiler tries to always select the instance with *the most specific subtype* of the requested type. This can lead to confusing situations, when user faces ambiguity errors in code that should intuitively work. Changing the scheme of given prioritization to always select the instance with *the most general subtype* that satisfies the context bound, would resolve such cases. We have conducted experiments that showed that the proposed scheme will result in a more intuitive and predictable given resolution. The negative impact on the existing projects is very small. We have tested 1500 open-source libraries, and new rules are causing problems for less than a dozen of them. We have already submitted PRs with changes that will make them work the same way under both the current and proposed rules.
 
 For the detailed motivation of changes with examples of code that will be easier to write and understand, see our recent blogpost //// TODO LINK
 
 Our current plan is to introduce the new scheme in Scala 3.7. Starting from Scala 3.6, code whose behavior can differ between new and old rules (ambiguity on new, passing on old, or vice versa) will emit warnings, but the old rules will still be applied. 3.5 gives you a chance to detect if those changes affect your codebase. Running the compiler with `-source 3.6` will give you warnings; with `-source 3.7` or `-source future` you will get the new scheme.
 
 ## What's next?
 
-There is already 3.5.1-RC1 published on Maven Central. This release contains multiple fixes and small improvements merged after we branched off the 3.5.0 to focus on polishing it. The release of the next version in the LTS line is coming soon. Scala 3.3.4-RC1 is available for testing. It contains all the forward and backward-compatible fixes available in Scala 3.5.0.
+There is already 3.5.1-RC2 published on Maven Central. This release contains multiple fixes and small improvements merged after we branched off the 3.5.0 to focus on polishing it. The release of the next version in the LTS line is coming soon. Scala 3.3.4-RC1 is available for testing. It contains all the forward and backward-compatible fixes available in Scala 3.5.0.
 
 ## Contributors