Apply @hsyl20 suggestions

yvan-sraka · yvan-sraka · commit 7784ef275c6b · 2023-11-22T18:32:13.000+01:00
diff --git a/blog/2023-11-13-devx.md b/blog/2023-11-13-devx.md
@@ -1,13 +1,13 @@
 ---
 slug: 2023-11-13-devx
-title: The IOG Developer`s Experience Shell
+title: The IOG Developer's Experience Shell
 authors: [yvan]
 tags: [devx, haskell.nix, hix, iogx, nix]
 ---
 
 # The IOG Developer's Experience Shell
 
-The IOG's Developer Experience Shell, or `DevX` for short, is an opinionated development environment tailored for Haskell. Built on top of Nix expressions, it provides a reproducible and seamless, full-featured developer shell with tools such as `cabal-install`, `ghc`, `hls`, and `hlint`. `DevX` is built upon the battle-tested `haskell.nix`, a framework for building Haskell packages with Nix. Knowing Nix isn't a prerequisite to read the post except for the last `hix` section. In short, `haskell.nix` turns your Cabal or Stack project and its dependencies into a Nix expression. We will explain how to use `haskell.nix` on its own using `hix` in the last section.
+The IOG's Developer Experience Shell, or `DevX` for short, is an opinionated development environment tailored for Haskell. Built on top of Nix expressions, it provides a reproducible, seamless, and full-featured developer shell with tools such as `cabal-install`, `ghc`, `hls`, and `hlint`. `DevX` is built upon the battle-tested `haskell.nix`, a framework for building Haskell packages with Nix. Knowing Nix isn't a prerequisite to read the post except for the last `hix` section. In short, `haskell.nix` turns your Cabal or Stack project and its dependencies into a Nix expression. We will explain how to use `haskell.nix` on its own using `hix` in the last section.
 
  But why Nix? Haskell developers often encounter the need for distinct environments per project. While solutions like stack resolvers and cabal project files address some concerns, they often fall short in terms of environment isolation. E.g., a Cabal project file could not be enough, because external (non-Haskell / system) dependencies need to be tracked too (that's exactly what Nix does), and could lead to inconsistent (non-reproducibles) builds. For instance, working on the Cardano performance regression while migrating from GHC 8.10 to 9.2, this required different toolchains. And, addressing this without `nix` would have been an absolute mess... With the `DevX` shell and `direnv`, you can achieve seamless transitions between projects. To illustrate, consider:
 ```shell
@@ -16,9 +16,9 @@ ghc --version  # 8.10
 cd ../project2 # unloading project1/.envrc and loading project2/.envrc
 ghc --version  # 9.2
 ```
-Nix achieves reproducibility by managing the complete dependencies graph (the _closure_) of a project, this also make it a great candidate as a cross-compilation framework! While this will not be discussed in this article, it worth noticing this is one of the main reason of why we love it at IOG. Other challenges solved by Nix are: How do we sync workspaces to make sure we're all dealing with the same technical stack? How do we make sure that Developer A can reuse the work of Developer B? One last way of introducing Nix is to say that it ensure that your developer environment respect a _semantic contract_. Like you can write a program that precisely and accurately states a meaning of some thing (e.g., the meaning of `2 + 2` _is_ the symbol `4`), with Nix you get a semantic contract for, e.g. in our case, a _shell closure_, which means a developer environment.
+Nix achieves reproducibility by managing the complete dependencies graph (the _closure_) of a project. While this will not be discussed in this article, it makes it a great cross-compilation framework and it is worth noticing this is one of the main reason of why we use it at IOG. Other challenges solved by Nix are: How do we sync workspaces to make sure we're all dealing with the same technical stack? How do we make sure that Developer A can reuse the work of Developer B?
 
-So, to sum up, Nix is the tool that let you write reproducible, seamless and correct developer enviroments, and `DevX` shell is our opiniated definition on how to pack it with tools such as it is full-featured for Haskell development. This article aims to give you a technical deep dive on how to use the `DevX` shell (and other IOG Nix-related projects such as IOGx flakes' framework and `hix` CLI tool) in your own Haskell project. By the end of the following section you should be able setup it in few steps, even in your Github Action CI or GitHub CodeSpace developer environment!
+So, to sum up, Nix is the tool that let you write reproducible, seamless and correct developer enviroments, and `DevX` shell is our opiniated definition on how to pack it with tools such as it is full-featured for Haskell development. This article aims to give you a technical deep dive on how to use the `DevX` shell (and other IOG Nix-related projects such as IOGx flakes' framework and `hix` CLI tool) in your own Haskell project. By the end of the following section you should be able to setup it in few steps, even in your Github Action CI or GitHub CodeSpace developer environment!
 
 ## Getting started with `DevX` Shell
 
@@ -30,7 +30,9 @@ We need to ensure [Nix is installed](https://nixos.org/download) and configured
 
 ### Philosophy and Usage
 
-The `DevX` shell approach is a one shell fits most. This means it isn't the most minimalistic method for building a Haskell project with Nix, but it aims to be the most robust and generic approach. The `DevX` shell, built on top of `haskell.nix`, heavily utilizes IFD (Import From Derivation). Consequently, it can't be used as a build framework for distributing projects on `nixpkgs`. In such cases, you might prefer using [`haskellPackages.mkDerivation`](https://nixos.org/manual/nixpkgs/stable/#haskell-mkderivation).
+The `DevX` shell approach is a one shell fits most[^1]. This means it isn't the most minimalist method for building a Haskell project with Nix, but it aims to be the most robust and generic approach.
+
+[^1]: The `DevX` shell, built on top of `haskell.nix`, heavily utilizes IFD (Import From Derivation). Consequently, it can't be used as a build framework for distributing projects on `nixpkgs`. In such cases, you might prefer using [`haskellPackages.mkDerivation`](https://nixos.org/manual/nixpkgs/stable/#haskell-mkderivation).
 
 To start using the IOG DevX shell in your Haskell project, simply run `nix develop github:input-output-hk/devx#ghc96` within your Haskell project's folder! This will spawn a developer shell, within which you can proceed with your usual Haskell tools and development workflow; for instance, use `cabal build` to build your project. For instance:
 ```
