Apply suggestions from code review

Co-authored-by: Sébastien Doeraene <sjrdoeraene@gmail.com>

Author: Zelenya

blog/_posts/2023-12-08-migration-to-scala-3.md

@@ -6,15 +6,15 @@ title: "Scala 3: My migration journey"
 description: I want to share my journey from Scala 2 to Scala 3 and discuss migration to Scala 3
 ---
 
-My name is Jay, I am a software engineer and developer advocate. We've recently migrated the project from Scala 2 to Scala 3 at $WORK, and in this article, I'd like to share the lessons learned and tips.
+My name is Jay, I am a software engineer and developer advocate. We've recently migrated a major project from Scala 2 to Scala 3 at $WORK. In this article, I'd like to share the lessons we learned as well as some tips.
 
 ## Implicit context
 
-Before doing any actual personal work, based on the internet discussions, I had an impression that switching to Scala 3 would be quite painful — in practice, it was pretty straightforward.
+Before doing any actual personal work, based on Internet discussions, I had the impression that switching to Scala 3 would be quite painful. In practice, it was pretty straightforward.
 
-In retrospect, our experience was determined by the technology stack and tools that I (and my team) use: microservices, Typelevel stack, VS Code with Metals, and, most importantly, no macros. It might not be as smooth if any of these wasn't the case.
+In retrospect, our experience was determined by the technology stack and tools that I (and my team) use: a microservice architecture, the Typelevel stack, VS Code with Metals, and, most importantly, no macros. It might not have been as smooth if any of these wasn't the case.
 
-Let’s start in my world first, follow the primary migration steps, and then talk about what to do if your setup and stack differ.
+Let’s first explore our experience given that setup, follow the primary migration steps, and then we will talk about what to do if your setup and stack differ.
 
 ## Step 0. What does “migration” mean in your case?
 
@@ -24,11 +24,11 @@ If you are actively writing Scala, I’d expect that you don’t choose to stay
 
 There is no one way to do the migration. Decide what’s possible and worthwhile to you (and your company).
 
-Should you rewrite one service at a time? In what order? Or should you leave the old services untouched and write all the new services in Scala 3? What about internal libraries? How much time and resources can you allocate? (The last one might be the hardest to address)
+Should you rewrite one service at a time? In what order? Or should you leave the old services untouched and write all the new services in Scala 3? What about internal libraries? How much time and resources can you allocate? (The latter question might be the hardest.)
 
-It’s also an excellent time to discuss the benefits and trade-offs. And keep it fair. For example, if you just want a new syntax, is it worth disturbing an old service that hasn’t been touched in years? Well, it’s up to you to decide.
+It’s also an excellent time to discuss the benefits and trade-offs. Keep it fair. For example, if you just want a new syntax, is it worth disturbing an old service that hasn’t been touched in years? Well, it’s up to you to decide.
 
-*We decided to write all the new services in Scala 3 (where most of the future work will happen) and keep the rest. Consequently, onboarding new devs without prior Scala experience is one of my biggest challenges. When they switch from Scala 3 service to Scala 2, they bump into hurdles — some of the “intuitive” concepts don’t work as expected anymore. This requires more explanation; they seem to have to learn some things twice.*
+We decided to write all the new services in Scala 3 (where most of the future work will happen) while keeping the existing ones on Scala 2. Consequently, onboarding new developers without prior Scala experience is one of my biggest challenges. When they switch from a Scala 3 service to Scala 2, they bump into hurdles — some of the “intuitive” concepts don’t work as expected anymore. This requires more explanation; they seem to have to learn some things twice.
 
 Okay, we defined what migration means, but how exactly do we go about it?
 
@@ -50,9 +50,9 @@ Thanks to the [interoperability](https://docs.scala-lang.org/scala3/guides/migr
 
 ## Step 2. Draw the rest of the owl
 
-After all the meetings and/or writings comes the time to do the actual work. When you have concrete questions or action items, remember that [Scala 3 migration guides](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html) are your friends. For example, they cover how to port compiler options and build configurations. Great reference resource.
+After all the meetings and/or write-ups comes the time to do the actual work. When you have concrete questions or action items, remember that [Scala 3 migration guides](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html) are your friends. For example, they cover how to port compiler options and build configurations. They are a great reference resource.
 
-> Note that you can find further help from the community on [Scala Discord](https://discord.com/invite/scala).
+> Note that you can find further help from the community on the [Scala Discord](https://discord.com/invite/scala).
 
 We don’t have to go into these details right now. Instead, let’s talk about the bigger picture and a few other things to remember.
 
@@ -66,7 +66,7 @@ There are multiple ways of sharing a library between Scala 2 and Scala 3 service
 
 **The good news** is that it’s pretty easy to deal with.
 
-Imagine you have an internal library (e.g., auth-handling, specific DB-connector, peculiar API) used by your existing Scala 2 services that will also be used by Scala 3 services. If your library on Scala 2 uses the `ducks` library and your Scala 3 application uses `ducks` as well, you get two conflicting versions `ducks_2.13` and `ducks_3`.
+Imagine you have an internal library (e.g., authentication handling, a specific database connector, a peculiar API) used by your existing Scala 2 services that will also be used by Scala 3 services. If your library on Scala 2 uses the `ducks` library and your Scala 3 application uses `ducks` as well, you get two conflicting versions `ducks_2.13` and `ducks_3`.
 
 To solve this, with sbt, you can cross-publish your library to both versions by adding one line to your build:
 
@@ -86,15 +86,15 @@ sbt> + compile
 
 ### Dealing with dependencies
 
-If all the libraries you use are actively maintained and published for Scala 3, good, there is nothing for you to worry about.
+If all the libraries you use are actively maintained and published for Scala 3, there is nothing for you to worry about.
 
 Otherwise, you might need [to help them](https://docs.scala-lang.org/contribute/) with migration or eliminate the dependency. Some libraries can be redundant on Scala 3 (because, for instance, Scala 3 has support for [Type Class Derivation](https://docs.scala-lang.org/scala3/reference/contextual/derivation.html)), and some have new alternatives.
 
 *For example, at this stage, we’ve discovered [Iron](https://github.com/Iltotore/iron), [a great lightweight library](https://www.youtube.com/watch?v=4pq1elOap9k&ab_channel=ImpurePics) for type constraints, which replaced refined and newtype libraries in one go.*
 
 ### Dealing with plugins
 
-Similar to dependencies, some plugins stay working, and some — are redundant and can be dropped.
+Similarly to dependencies, some plugins support Scala 3, while some others are redundant and can be dropped.
 
 For instance, the first plugin I was happy to retire was `better-monadic-for`, because Scala 3 already gives me better for-comprehensions. For example, we can define implicit values inside for-comprehensions:
 
@@ -116,15 +116,15 @@ yield doY(result)
 
 The second one is `kind-projector`. Scala 3 has [built-in type lambda syntax](https://docs.scala-lang.org/scala3/reference/new-types/type-lambdas-spec.html) and [kind-projector compatible syntax](https://docs.scala-lang.org/scala3/reference/changed-features/wildcards.html).
 
-> For even more information, see the [Kind Projector Migration](https://docs.scala-lang.org/scala3/guides/migration/plugin-kind-projector.html) guide.
+> For even more information, see the [Kind Projector migration guide](https://docs.scala-lang.org/scala3/guides/migration/plugin-kind-projector.html).
 
 ### Finally, dealing with code
 
 Much of the Scala 2.13 code is still valid in Scala 3. If you want, you can use [the migration tools](https://docs.scala-lang.org/scala3/guides/migration/tooling-tour.html). Otherwise, if it sounds too boring, you can copy-paste the code over and fix whatever’s red.
 
 > You can review the incompatibilities in the [Incompatibility Table](https://docs.scala-lang.org/scala3/guides/migration/incompatibility-table.html). 
 
-You might be wondering about all the new concepts and changes. For example, what should be done about `implicit` splits or enums? You don’t have to rewrite everything right away. Here and there, you can keep using the `implicit` keyword instead of `given` and `using`. Same with enums — you can keep using ADTs in the form of sealed traits with case classes and refactor to the new enums later.
+You might be wondering about all the new concepts and changes. For example, what should be done about `implicit` splits or enums? You don’t have to rewrite everything right away. Here and there, you can keep using the `implicit` keyword instead of `given` and `using`. The same applies to enums: you can keep using ADTs in the form of sealed traits with case classes and refactor to the new enums later.
 
 However, it’s an exceptional opportunity to think about the style, patterns, and consistency. The code tends to replicate and spread around via copy-paste. You must decide whether to pay upfront or take shortcuts and do a more significant refactoring later.
 
@@ -134,20 +134,20 @@ Scala-3-rewrite allows you to get rid of the old workarounds as well as challeng
 
 ### What to do about IDEs / IntelliJ IDEA
 
-*I might not be the last person you should ask about IDEs, but I am still quite biased when it comes to tooling. I vividly remember a few years ago when the functional code (with `cats`) was primarily red. Also, I haven’t touched any Java IDEs in years; I mainly work with unpopular functional languages and am happy with syntax (plus error) highlighting and go-to-definitions. And if I don’t need to restart the LSP server a few times a day, I’m in heaven.*
+*I might not be the best person you should ask about IDEs, but I am still quite biased when it comes to tooling. I vividly remember a few years ago when the functional code (with `cats`) was primarily red. Also, I haven’t touched any Java IDEs in years; I mainly work with unpopular functional languages and am happy with syntax (plus error) highlighting and go-to-definitions. And if I don’t need to restart the LSP server a few times a day, I’m in heaven.*
 
 To me, using VS Code with Metals and Scala 3 doesn’t feel different from using these with Scala 2 a couple of years ago. And it’s only getting better.
 
-[IntelliJ IDEA 2023.2](https://blog.jetbrains.com/scala/2023/07/26/intellij-scala-plugin-2023-2-is-out/) brought enhanced Scala 3 support, and the team is constantly working on improvements ([IntelliJ IDEA 2023.3](https://blog.jetbrains.com/scala/2023/12/07/intellij-scala-plugin-2023-3-is-out/) was released just when I was writing this). [Metals](https://scalameta.org/metals/) has regular [releases](https://scalameta.org/metals/blog/) driven by [Scala Center](https://scala.epfl.ch/), [VirtusLab](https://virtuslab.com/), and contributors from the community. So, if you haven’t recently tried either, now is a good time.
+[IntelliJ IDEA 2023.2](https://blog.jetbrains.com/scala/2023/07/26/intellij-scala-plugin-2023-2-is-out/) brought enhanced Scala 3 support, and the team is constantly working on improvements ([IntelliJ IDEA 2023.3](https://blog.jetbrains.com/scala/2023/12/07/intellij-scala-plugin-2023-3-is-out/) was released just when I was writing this). [Metals](https://scalameta.org/metals/) has regular [releases](https://scalameta.org/metals/blog/) driven by the [Scala Center](https://scala.epfl.ch/), [VirtusLab](https://virtuslab.com/), and contributors from the community. So, if you haven’t recently tried either, now is a good time.
 
 ### What to do about macros (and other issues)
 
-First, as discussed earlier, you should ask whether macros live in a separate unmaintainable service? Can you leave these services alone for now and rewrite them later? Or can you extract the usage of the macros into an independent service or a library?
+First, as discussed earlier, you should ask whether macros live in a separate service? Can you leave these services alone for now and rewrite them later? Or can you extract the usage of the macros into an independent service or a library?
 
-And if the macros rewrite is unavoidable but unattainable, consider asking for help. For instance, [VirtusLab](https://virtuslab.com/) offers [free support with migration](https://virtuslab.com/scala-3-support-and-migration/).
+If the macros rewrite is unavoidable but unattainable, consider asking for help. For instance, [VirtusLab](https://virtuslab.com/) offers [free support with migration](https://virtuslab.com/scala-3-support-and-migration/).
 
 ## Next steps
 
-Hope this clears up and demystifies some things. 
+I hope this clears up and demystifies some things. 
 
-I’d also encourage you to share your migration stories even if they seem boring. Also, remember that the IntelliJ Scala plugin team asks for [feedback](https://blog.jetbrains.com/scala/2023/09/21/intellijscala-scala-days-2023-madrid/), and [Scala Center](https://scala.epfl.ch/) regularly collects feedback.
+I’d also encourage you to share your migration stories even if they seem boring. Also, remember that the IntelliJ Scala plugin team asks for [feedback](https://blog.jetbrains.com/scala/2023/09/21/intellijscala-scala-days-2023-madrid/), and the [Scala Center](https://scala.epfl.ch/) regularly collects feedback.