After listening to the excellent interview of Giacomo Cavalieri on the FuncProg podcast (hi Christoffer!) I thought I would do the online tour of Gleam to get a better taste of it.

Here are my first impressions in three convenient buckets: "noice", "hmmm...", "hell no!".

Noice

• FP language with familiar constructs for lists, options, results, partial application, etc...

• Pattern matching with reasonable machinery: named values, catch-all, guards, elided values, alternatives, etc...

• Records with record getters / updates, enums, variants.

• Type aliases, opaque types.

• Simple language, easy to learn, nice error messages.

• Interop story with JavaScript and Erlang (with the @external annotation)

• The gleam build tool seems to be inspired by cargo:

  • Using a TOML file

  • build, test, fmt out of the box.

  • With nice dependencies management (from Hex, local paths, or a git repository)

• Did I mention statically-typed?

Hmmm...

• The <<>> syntax for bit arrays with tags like utf-8. Just hmmm, because I'm not familiar but could be noice.

• No exceptions but 3 keywords that can panic: todo, panic, assert.

• // (expression), /// (function) and //// (module) as a way to start comments.

• No macros but 3 predefined annotations: @deprecated, @external, @target.

• Function syntax with fn(a) -> b. Why not the simpler a -> b? Hard to beat Haskell there.

• Generics syntax with parentheses List(Int). Why does everyone insist on doing that differently 😫?

  • Haskell: List a

  • Scala: List[A]

  • Rust: List<A>

  • OCaml: 'a list

• The gleam build tool creates a new project with a Github workflow + .gitignore out of the box. Can this be customized?

Hell no!

• Division by 0 is equal to 0.

• No syntax for early return of results, like ? in Rust.

• |> can apply a value as the first parameter of a function (like f(a: Int, b: Int)) or as the argument to a 1-argument function (like fn(Int) -> Int). That looks troublesome.

• A brand new concept [1] for named parameters: fn all(in list: List(a), satisfying predicate: fn(a) -> Bool) -> Bool. in and satisfying are "labels" and can be used to passed named values: all(in: [1, 2], satisfying: fn(x) { x > 3 }).

• Short-hand syntax for named parameters do we really special support for this?

• Expressions have to be grouped with {} , like { 1 + 2 } * 3 and not with regular parentheses. I thought it was to parse more easily tuples, but they have their own ugly syntax #(1, 2, 3). What's wrong with (1, 2, 3)? Good thing that lists are just [1, 2, 3].

• Nil value representing a "unit/void" type. That hurts me as a Scala programmer.

• as as a keyword just to pass a message to todo / panic / assert.

• A keyword, echo just to output debug statements.

Conclusion

I am definitely happy that a statically-typed programming language exists in the BEAM ecosystem and would love to use Gleam if I had to use BEAM. My main concerns are:

• The syntax is designed to be lightweight but feels a bit ad-hoc. I feel we could have done better here.

• The type system looks minimal (no type classes for examples) but this might be the price to pay for an easy interop story with BEAM and Javascript.

• The OTP story is supposed to be a strong selling point (systems with great uptime!) but the OTP library seems to be still in infancy and easy concurrency could sold better on the front page IMO.

• gleam seems to follow the path of cargo but with less power (workspaces, plugins, etc...)

I apologize in advance to Gleam authors and fans for writing possibly inaccurate or unfair comments on this post. I hope I can come back and write some more serious code with Gleam to get a more informed opinion in the future!

[1]: Brand new to me! Swift also has parameter labels.

Scratching an itch

When you create Unison programs, your code is type-checked and then saved to a database. You don’t exchange files with others but use Unison terms. Revolutionary. Perhaps a bit too much, since a full ecosystem had to be built from scratch to support this approach. GitHub becomes unusable. In its place, there is Unison Share where you can browse projects and collaborate with others. Unfortunately, Github is the portfolio of many developers, and as a Unison developer, all your frantic activity is invisible to most of the development world.

Fortunately Unison Share provides an API and a system of webhooks. You can install webhooks that will be notified every time an event related to your project occurs: a new push, a new ticket, etc… Hence the straightforward idea to use a webhook to mirror the Unison Share project activity to a Github repository.

Designing it

The most direct way to implement this system is to deploy an HTTP server that will listen to webhook payloads and create commits to a Github repository. This is exactly what Unison Cloud supports out of the box!

However, the details matter. At first, I wanted to deploy and operate a service that any Unison developer could use. They would register, configure their webhooks to send payloads to my server, and I would create commits. But this requires trusting me with a very sensitive resource, their Github API token. After looking carefully into the configuration of Github tokens, I concluded that there was no way to make the system trustworthy. Instead of me deploying a service and operating for multiple users, I preferred to let everyone start their own server with their own secrets. It’s a bit sad because I was looking forward to operating a Unison service supporting many users.

The whole system is eventually composed of:

• A HTTP service listening to webhook payloads.

A CLI application to:

• Deploy the service.

• Synchronize a Unison Share project and a Github repository (or all of your projects at once).

• Get some status information.

You notice that the CLI gives you the possibility to deploy the service with one command. This is, after all, one of the strength of Unison Cloud, the deployment code is still Unison code!

Implementing it

That was actually the fun part! I have, for the past year, created a few Unison libraries and this was finally the opportunity to use many of them in the same project:

• potions a CLI library.

• registry a dependency injection library.

• json-encoder / json-decoder two libraries to create encoders / decoders for a given data model.

• to-text a library to create flexible ToText instances for a data model.

Since eating your own dog food is the best way to improve your projects, I made a few improvements and fixes:

• potions

  • Improv the display of enum flags.

  • Add the possibility to specify command name aliases.

  • Fix the missing item in a numbered list.

  • Better error message in the case of an incorrect subcommand.

  • Render colored text as Word and not Paragraph.

  • Add grey color style.

  • Upgrade the terminus library (I found an issue with the latest release in the process which was promptly fixed by Runàr)

• registry

  • Expand the API for overriding components (setValueFrom, overrideValue but I’m still not satisfied with this API).

  • Add a makeDiagram function to produce a Mermaid diagram for an application.

Talking about that last feature, I can now display a diagram of the application!

The diagram is directly derived from the declaration of the components of the application (and pasted to Mermaid Live).

This diagram reveals some interesting points about the use of dependency injection:

• An HttpClient gets an AuthorizationToken that is automatically provided to make queries to both Unison Share and Github.

• However this token must be different when the HttpClient is used by the ProjectApi than when it is used by the GithubApi, and the registry library supports this use case.

• Since the Application uses APIs to communicate with other systems, it is possible to implement in-memory versions of those APIs to write purely in-memory tests for the Application. There are still some integration tests against those APIs, actually creating / deleting repositories for example, to check that everything works ok.

• You can also notice a difference between the Console and the Logger. The Console is used to display user messages on screen (with the help of the excellent terminus library) while the Logger is only activated on demand or when there are errors.

Using it

Finally, I can use the application for my own needs! I used tiles deploy to deploy the service:

I can even tail it directly from the Unison Command Manager, ucm:

Now, let’s have a look at all the synchronized projects:

They are all synchronized but you will notice that some of them are private. In that case the corresponding Github repository, created when using the sync command, is private too.

Finally, what does it look like on Github?

For now I’m only creating one commit per push, with the full payload updating the README file of the project.

I hope to be able to use the newly announced history comments of ucm-0.5.50 to produce specific commit messages when possible.

What’s next?

This was the perfect chance to create and deploy a simple Unison service. Next, I want to deploy something that will attract more users, include some storage, and offer meaningful analytics so I can enjoy more of the Unison ecosystem. 😊

When I was working at Macquarie Bank in Sydney, I would implement new features for the bonds trading back-office. Then, I would sit down with a business analyst, Greg (if I remember correctly) and he would test various cases with me. One thing that struck me was how meticulously he would select a specific bond name, expiry date, and price. I thought, "It doesn't matter if the price is 1099.94 AUD or 100 AUD! Why is he spending so much time on this?"

Still, that made me think. I realized (much later) that I was wrong for at least two reasons. First, I was missing a good testing opportunity to use the system in conditions closer to reality. From a testing perspective, this had a better chance of revealing interesting bugs, where a business analyst might say, "Huh, that withholding tax amount doesn't make sense at all."

The second reason is a bit more subtle. I was not really caring about the service I was building, I was not living and breathing “bonds back-office”. The purpose of this post isn't to focus on this aspect, but I've often noticed the difference it makes when you genuinely care about what you are building, not just how you are building it.

Real-world data ingestion

The next step in my “data journey” was running ingestion pipelines. Every single time I ingested some large amounts of data I found some data that didn’t have the shape / properties I was expecting: “Oh, there could be no associated product metadata?”, “Yes, of course, because some products were created before the Big Migration”.

Property-based testing

Then came property-based testing (PBT). Wow, I can write properties that test my code in many different conditions! And I would find bugs. But also sometimes realize that my nicely crafted property would not catch a specific bug. Why? Well, looking at the generated data I would realize for example that I was generating lists of strings that were mostly rubbish and not really suited to my domain. Hmm, I really needed to have a look at that data…

This can be an interesting exercise. Take a moderately complex domain model and create data generators for it. Now, examine the data and ask yourself: “How good is the coverage?” and “Am I really generating interesting cases?” Then, do a quick calculation on how many possible combinations exist for that model. You'll likely reach millions quite fast. What is the chance of hitting an interesting case when you run your property test only 100 times? What if you even run it 100000 times? Just, a drop in the ocean. As useful as PBT is, we cannot generated data mindlessly.

For a while I was interested by “enumeration testing”. The idea is to start enumerating exhaustively all the possible shapes of a given data model with the assumption that most bugs can be found with small examples. Then my idea was to randomly sample that enumeration when it becomes too large to explore.

When I got the chance to discuss this idea with John Hughes (of QuickCheck fame), he quickly dispelled my illusions. First of all, some bugs only show up after a rather complicated set of steps. John has an example of an issue in a stateful system that only shows up after 17 steps, but that counter-example was shrunk from an original failing test case of more than 100 steps! Then he told me that in his experience business knowledge is indispensable when driving your data generation strategy.

That shouldn’t be surprising to any seasoned QA or test-minded person but the consequence is that we can’t consider data as a purely randomly generated artefact. The more we know its business meaning and edge cases, the better it is.

Serialization

The next example comes from serialization. I previously worked on a project where a "Ledger" (think of it as an immutable list of transactions) was shared across nodes. The data was serialized using CBOR to keep it compact. Serialization was a major concern because, as the system evolved, the data types changed, new data was stored differently, and we still needed to read data from the very beginning.

So, I began examining different pieces of data, both before and after changes: which fields were serialized and in what way. Then, I noticed we were quite inefficient in how we stored data. For example, we would allocate an array nested three times: [[[a]]] when [a] would have been sufficient.

Why? Because of the power (or curse) of macro annotations. Many languages now support serialization where you simply annotate the fields of a data type to automatically get serialize/deserialize instances. This is very useful, especially for prototyping when you want to quickly import or export data. However, I have come to dislike this feature in production code for two reasons:

1. Serialization requirements are not “one size fits all”. For example I had issues with serde in Rust where some annotations were incompatible depending on the target format bare or JSON.

2. It becomes impractical to implement data model evolutions on large models.

I'm going off-topic a bit, but my point is this: I only realized how inefficient our data serialization strategy was once I took a close look at the data.

Visualizing data

Over time, I've realized how helpful it is to display data clearly. This starts with logs. Sure, we can dump a Debug instance of some data type and get created: Node { name: Name("n1"), peers: std::Vec(Peer { peerName: "p1" }, Peer { peerName: "p2" }) }. But it would be much nicer to read something like created node n1 [p1, p2] instead. When you're reading hundreds of lines of logs, this can make a big difference and help you spot discrepancies faster.

Another situation is when data, whether it's incoming messages or your system state, is somewhat complex. In such cases, being able to visualize it over time is very helpful. Here is a recent example:

I created a simple HTML page that helps us visualize the main stages of a simulation trace for the system I'm currently working on. While running the simulation and observing messages move from stage to stage, I noticed that the final stage, forward_chain, was receiving some duplicate messages. This should not happen! It means our node is sending unnecessary information to other nodes.

This isn't really a correctness issue—the data is still accurate. However, in a distributed system, this could mean that our node might get evicted due to its spammy behavior.

The great thing is that I only noticed this issue because I closely examined the data. The code was compiling, and all our tests were passing. It's important to note that I probably wouldn't have discovered this issue just by looking at the logs.

Conclusion

I am increasingly convinced that it's worthwhile to carefully examine the data, whether it's:

• Test data

• Incoming data

• System state

• Outgoing data

But data is quickly messy and too voluminous so it can really pay off to build small visualization tools to abstract the relevant parts and skim the rest. The good news is that we don’t have to be UI wizards anymore, LLMs can create these tools for us 😊.

variable "db_username" {
  description = "Postgres username"
  type  = string
}

The Terraform motto is “infrastructure as code”, but what I see above is a configuration file masquerading as a programming language!

Later on, at work, I got into a fight with the AWS Secret Manager and our EKS Cluster. The problem is simple:

• The AWS Secret Manager holds our Postgres database password, and is in charge of rotating it. Wonderful.

• The EKS Cluster starts a pod where one container uses an environment variable expecting the database password. Great.

Question: how do we pass this piece of information between those 2 systems?

The path to madness

The current solution consists in aligning precisely several pieces of text:

• The name of the secret created in the Secrets Manager.

• The “secrets provider” resource in Kubernetes.

• The “volumes” section of the Kubernetes pod.

• The “mounted volume” for a given container.

• The environment variable with a “secret reference”.

Let’s have a look at those pieces.

The secrets provider

First the secrets provider:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
    name: database-secrets
spec:
    provider: aws
    parameters:
        objects: |
            - objectName: "rds!db-63dfcfd8-9b62-482a-ac60-faad5f806344"
              objectType: "secretsmanager"
    secretObjects:
    - secretName: database-username-and-password
      type: Opaque
      data:
      - objectName: "rds!db-63dfcfd8-9b62-482a-ac60-faad5f806344"
        key: DATABASE_USERNAME_AND_PASSWORD

This piece of configuration maps a secret name in the AWS Secret Manager to a Kubernetes Secret. It actually does more than just a mapping. It also guarantees that both will be synchronized when the secret is rotated.

That’s great, but why does the secret name have to be repeated twice? That name now lives in 3 places: the Secrets Manager, the parameters definition, the secretObjects definition. Since everything is a string, there was also nothing to force us to use a secret name for the objectName field. We could have passed rds!db-63dfcfd8-9b62-482a-ac60-faad5f80634 only to discover much later that a digit was missing.

We also have just introduced 3 new strings!

• The name of the secrets provider: database-secrets.

• The secretName and the key of the secret because Kubernetes secrets are effectively maps of maps of strings.

The volumes section

In the pod deployment file we need a section declaring which volumes are mounted:

volumes:
- name: secrets-provider-volume
  csi:
  driver: secrets-store.csi.k8s.io
  readOnly: true
  volumeAttributes:
    secretProviderClass: "database-secrets"

There, we need to make sure that we use the right name for the secretProviderClass, by using a string defined in another file. But look, we are introducing yet another string for the volume name: secrets-provider-volume!

Mounting a volume

Next we need to mount that volume inside the container that will use the secret:

volumeMounts:
  - name: secrets-provider-volume
    mountPath: /mnt/secrets/database
    readOnly: true

Once more we need to be careful to match the volume name and we add yet another string for the mountPath.

The environment variable

Finally we can declare an environment variable that will hold the secret:

- name: OCKAM_DATABASE_USERNAME_AND_PASSWORD
  valueFrom:
    secretKeyRef:
      name: database-username-and-password
      key: DATABASE_USERNAME_AND_PASSWORD

Like before we need to make sure to reuse the same names that we declared in the secret provider, secretName and key, except that they are now called name and key.

Note that nothing tells us that the volume secrets-provider-volume needed to be mounted and if the mountPath, /mnt/secrets/database, was relevant.

In summary

In order to use one AWS Secrets Manager secret in a Kubernetes pod we have to carefully align:

• One generated string (the secret name).

• 4 user defined strings.

• In 10 different spots.

This is the definition of programming by coincidence!

Can we have a real programming language, please?

This short video is funny:

It basically says “We made all this YAML so that you don’t have to do it“.

One objective of the Unison programming language is to have a cloud offering where declaring services and all sorts of resources can be done programmatically. This has numerous advantages:

1. We can name variables that hold values, and refer to those names everywhere.

2. We can type those variables to prevent runtime errors.

3. We can use abstractions to isolate from implementation details.

What would it look like for our “secret” example to use a programming language?

The secret sauce

If we had a programming language at our fingertips we could start by defining the concept of “secret source”, that can be implemented by an AwsManagedSecret (all the code that follows is pseudo-Haskell-like code):

databaseManagedSecret : IO AwsManagedSecret
databaseManagedSecret = getOrCreateAwsManageSecret "prod-database" RotationPolicy.MONTHLY

class SecretSource s where
  getSecret : s -> IO Secret

instance SecretSource AwsManagedSecret where
  getSecret = todo

The purpose of a SecretSource is to give us the most recent secret when we ask for it. The real thing would actually give us more, like the frequency of the rotation, or how to access it via the network.

The implementation is using the AWS secrets manager but it could an Azure Key Vault. You will notice that we give the managed secret a name but it is not relevant for the rest of the code.

Next, we need to define a Kubernetes Secret that uses the SecretSource:

-- A KubernetesSecretFromSource takes care of synchronizing 
-- the secret from the source, including
data KubernetesSecretFromSource = todo

makeKubernetesSecret : SecretSource s => s -> IO KubernetesSecretFromSource
makeKubernetesSecret s = todo

class KubernetesSecret s where
  getSecretMap : s -> IO SecretMap

instance KubernetesSecret KubernetesSecretFromSource where ...

Now, we define an environment variable from a KubernetesSecret:

-- An environment variable getting its value from a KubernetesSecret
-- It is responsible to mounting the right volume when used for creating a Pod
data EnvVarFromKubernetesSecret = todo

makeEnvVarFromKubernetesSecret : KuberneteSecret s => s -> IO EnvVarFromKubernetesSecret
makeEnvVarFromKubernetesSecret s = todo

class EnvironmentVariable v where
  getName : v -> Text
  getValue : v -> IO Text

instance EnvironmentVariable EnvVarFromKubernetesSecret where ...

Finally we can create a Pod, using an EnvironmentVariable which abstracts the details of how the value is retrieved:

createPod : EnvironmentVariable v => v -> ... -> IO Pod
createPod variable ... = do
  -- this mounts the right volume for the pod
  setEnvironmentVariable variable

-- The full configuration
databaseClientPod :: IO Pod
databaseClientPod = do
  managedSecret <- databaseManagedSecret
  k8sSecret <- makeKubernetesSecret managedSecret
  envVar <- makeEnvVarFromKubernetesSecret k8sSecret
  createPod envVar

All of this is just a sketch, and the important points are:

1. We use typed variables to pass information around.

2. We use interfaces / typeclasses to hide implementation details.

3. We have library functions that declare exactly what is necessary to build:

   1. A Pod,

   2. An EnvironmentVariable backed by a KubernetesSecret,

   3. A KubernetSecret from a SecretSource.

This is just good old software engineering practices! With huge benefits:

• Less possibilities to make mistakes,

• More discoverability of how things work,

• A lot more fun programming our resources!

Let’s do it?

If we wanted to go that route there would be a number of obstacles:

1. I am not sure a mainstream programming languages can support that approach if, at some stage, we need some fancy types. However, if we just need type-safe heterogeneous maps we should be covered.

2. There would be a need for dependency injection in order to be able to easily define a configuration based off another configuration (what “override files” are attempting to do).

3. The sheer size of the project! The number of data structures and APIs to cover is enormous. I suspect that only a company-backed project (like Pulumi) could sustain this kind of effort.

So, what do you all think? Can we do better? Can we do much better?

I can group most of my highlights of 2024 in 3 categories:

1. Becoming a technologist

2. Unison

3. The small stuff

Becoming a technologist

I have always thought about myself as a “Software Engineer”. My main activity was to produce proper code forming reliable systems, and culminating in desirable products. 2024 marks a shift where I learned to become a technologist. What do I mean by this?

It turns out that many issues pertaining to software have largely been solved:

• Provision machines to execute applications.

• Persist vast amounts of data.

• Run distributed systems reliably.

• Identify users and control access.

• Analyze data.

• etc…

Many of these solutions are available as services, under the AWS umbrella for example:

When you build software products it would be foolish to not stand on the shoulder of giants and not reuse, or integrate with, those services. The consequence is that you spend a lot less time programming, and a lot more time configuring. I think that the right question to ask is “can we go back to programming?” and will try to give an answer after a few examples.

What’s going on with my users?

Getting proper feedback is essential to understanding if your product is going in the right direction. At Ockam, we enable users to securely connect any system to any other system, without having to open any internet ports. Our command-line executable, ockam, supports many commands to establish what we call portals and manage them (by creating cryptographic identities, permissions, etc…).

We want this experience to be as seamless as possible and, if we can, be proactive in assisting users with any issue that they might face. We tried to leverage OpenTelemetry traces in order to gather as much actionnable data as possible:

• Which command is invoked?

• What are the response times in various parts of our pipeline?

• What errors might be raised?

• Are there frequent command-line errors?

• Are there some stuck users who can’t create a portal for some reason?

My job has been to instrument our command-line tool to structure this data, collect it, and slice it to:

• Show the “journey” of a user.

• Being able to track down issues to relevant traces and log messages.

The “structure” / “collect” / “slice” parts were not entirely under my control: OpenTelemetry is a standard with a strict (and large!) specification, and there are many offerings for collecting and aggregating telemetry data. This is where the technologist part comes in. Most of the work consists in:

• Understanding the data model and behavior of a system that someone else built.

• Put the right information at the right place.

• Respect constraints established by someone else (maximum number of spans for a trace for example).

• At a reasonable cost! Yes, this is also a dimension to optimize for and we’ve all heard of horror stories with software bills gone wrong.

I could probably make quite a long blog post around this piece work but I am going summarize my learnings here:

• What we want to do is not really supported by any vendor. Many services focus on aggregating data and being able to drill down on an error. What we want to see is the most relevant events for each user.

• OpenTelemetry is a bit of a bloated specification in need of a radical change (tl;dr “wide structured events” instead of traces/logs/metrics).

• I had UML vibes from the past, realizing that the same standard was not supported in the same way by different vendors.

• Testing and non-regression is difficult. How do you check that events are still properly sent and aggregated across your service and someone else’s?

• Visualization of data is non-trivial and the complexity of the OpenTelemetry data model does not help.

• The existence of a generic “collector” where you can send all the traces centrally, and then dispatch to the backend of your choice is a huge benefit. A good example of interface/implementation separation at the system level!

• That being said, and despite the existence of the OpenTelemetry specification, each new vendor comes with its own configuration, project model, users model, visualization tools, query language, etc… It’s almost like starting from scratch every time.

• Costs are definitely a factor. Are we getting the most out of a given service? (answer: not quite).

We’re all snowflakes

The other big piece of technology that I worked on this year is Snowflake. In summary Snowflake is a platform allowing you to import huge amounts of data and process it without having to worry about dealing with any infrastructure. A giant database and application environment at your fingertips.

Ockam is a particularly good fit for Snowflake since we allow users to import data from their private systems without exposing them on the internet, and then export analyses back. In order to help customers get started with instant connectivity to Snowflake we built a set of connectors to import/export data from/to Kafka, Postgres, SFTP, WebDAV.

This is very much an exercise in assembling technologies:

• Learn about the Snowflake model: Warehouses, database, tables, streams, users, organizations, etc…

• Learn about the deployment model of Snowflake: versions, patches, deployment directives, cloud regions, marketplace, accounts…

• Assemble the software as docker images with specific restrictions on networking. Juggle security restrictions to configure our own service.

• Use Python to develop small clients.

• Use Javascript to implement some stored procedures.

• Use SQL (Snowflake’s version of SQL) to write queries.

• Configure a myriad of YAML files.

• Use Streamlit to develop small configuration applications.

• Deploy Kafka locally via a docker image. Use docker compose to also deploy our own service.

• Click on many buttons, many, many times.

We eventually got those connectors to work after a lot of head-scratching but there is a stark contrast with traditional software development:

• You have to fit in the vendor’s model. That model contains a lot more information than you actually need for the specific job you have. It’s on you to sort it out.

• Many attempts can be necessary to understand exactly how that model behaves. Many things are left unspecified and you discover them only by trying.

• The user experience can be limited, and fixing it is out of your reach (we can’t get users table metadata to display source/target mappings in our connectors for example).

• Automatic testing in general is out of question, that would be a massive project in itself.

• There is almost no way to compile or typecheck anything:

  • Configuration happens by accident. Not the right name is the right place? Wait 5 minutes to see your service crash after deployment.

  • Streamlit uses Python. Change some shared UI code somewhere and see silly and avoidable bugs somewhere else at runtime (if you happen to manually re-test all your applications…).

Who are you? A solved problem?

The last piece concerns my use of Auth0. Signing-up / Signing-in a service is such a ubiquitous and critical requirement that it makes sense to found a company around it (and it’s not a simple as it sounds).

At Ockam, we want to give the best onboarding experience to our users and, instead of re-inventing the proverbial wheel, we use Auth0. Once more my job was step away from the programming mode, to enter the configuring mode. At first glance, it’s not that bad:

• We can customize the sign-up / login screens.

• We can add some pieces of code to intercept and act on parts of the process (deny some email domains for example from signing-up).

• We can monitor major events and errors.

Unfortunately, using Auth0 is not devoid of problems:

• A user trying to sign-in with the sign-up page will be rejected, even if their credentials are correct. There is no way so far to fix this UX issue.

• There are many parameters to configure, the effect of some of them is not clear. One example: if you use a custom URL to present your Auth0 service, the URL domain will be automatically picked-up for some redirects. You can’t control that.

• By default, there’s no version control of your configuration. Fortunately there is a Terraform provider, allowing you to save all your configuration as, horror,… more YAML files. But there’s no guarantee that the Auth0 UI uses the last version of your configuration.

Special mention: ChatGPT

2024 is the year when I really started to use AI. While I haven’t used it much for coding, I have extensively used ChatGPT to solve all sort of issues when dealing with technologies new to me. And I am not the only one:

I must say that the ability to have a conversation with a knowledge base about a given problem is really a game-changer.

Where do we go from there?

Don’t get me wrong, I think it’s great to be a technologist. More than ever, we have to possibility to create incredible systems by building on top of amazing services. My biggest complaint is that, when building in the large, we lose all the good tools we have when building in the small:

• Version control.

• Typechecking.

• Linting.

• Unit / Integration tests.

• Code completion / code navigation across libraries.

• Specifications / models for our code.

• Dependency injection.

• Integrated documentation.

• Rich development environments and terminals.

• Dependency bots.

• Hot reloading.

• Notebooks.

• Deployment as code.

• CI / CD.

Note that the situation above is far from perfect in the small! There’s no actual environment where all those features are available at the same time by default. We can get somewhere near this picture by, once more, becoming technologists and assemble all tools we need (with the same issues as before).

I think that we can massively improve the situation by fundamentally make everything look like code. Especially code that deals with code:

• Deployment code: to associate services with resources.

• Observability code: to define how we want to monitor our systems.

• Testing code: to assert properties of our code.

• Documentation code: to give executable examples.

• Configuration code: to describe how the code is assembled.

• Graphical code: to represent and modify the configuration in a 1-1 correspondence.

This leads me to my second highlight for 2024.

Unison

Around April I decided to take the plunge and learn more about the Unison programming language and platform. I explain some of my motivations in “What is so unique about Unison?”, but in retrospect a huge motivation is present in what I wrote above about “code everywhere”:

• Unison services are deployed using Unison code, monitored using Unison code.

• The documentation is type-checked and executable.

• Dependencies are tracked very finely so that tests can be cached.

• There’s is not data to serialize / deserialize between services or persistent storage. It’s all just Unison terms.

Step 1

My overall goal for this year was to write and deploy a service to export some bank transactions from one of my bank accounts and import them into my accounting software. I started by writing a modest MultiMap library to get a better feel for the development cycle.

Step 2

When I first tried to connect to my bank, via HTTP, I quickly realized that Unison was missing some cryptography primitives (RSA) to sign some payloads. Time to re-open my Haskell toolbox and contribute to the language itself! (+ a bit of glue on the base library side).

Step 3

I then realized that having a command-line parsing library would be nice in order to run my service with different arguments, in particular API keys and account numbers which I did not want to store as term.

That sounds antithetical with my “everything as code” objective and it is! Still, I took this huge detour to:

• Create the potions library for parsing command-line options.

• Talk about it at the Unison forall conference, because this is an interesting problem to solve and a good example of how to use some Unison features to design a library.

In retrospect, I think it would be a good idea to make a small library for embedding encrypted data, so that one key only can unlock the whole configuration of an application as Unison terms, and make that a secret in a Unison Cloud Environment.

Step 4

I was finally able to come back to my application, write some code to make HTTP queries, retrieve transactions, decode them from JSON (shocking, not everyone is using Unison yet!), write a bit of logic to create accounting transactions and post them to my favorite accounting software, YNAB (thanks for having an API!).

That led me to another pet peeve of mine. I think that we are plagued by the lack of dependency injection in our industry. We are sometimes lucky to have nice compositional software, thanks to functional programming, so we know how to assemble code. But when it comes to say “give me the same piece of code with one slightly different bit” we just don’t have the words.

Configuration is a good example of this. We use all sorts of tricks to say “I want the same configuration but change x and y for the development environment”: environment variables, “overlays”, scripts to write YAML, templating languages, etc…

I think that we should recognize this problem as a dependency injection problem, and have the possibility to replace any piece of a software system, from the billing component, to an API key. Ideally the language used should be the same as the programming language. This is not a big ask, in principle we just need a bit of meta-programming to do so. Here is an example on how to support DI in Haskell. An added benefit is that we automatically get a picture of the system structure because we have “code about code” at our disposal.

Given that my application was starting to grow (with 13 components in different configurations for local our Cloud testing), I set out to write a library to support dependency injection in Unison. This is still work in progress (I use it but it’s undocumented for now) but I’ll have the opportunity to share more about it next year.

And now?

My application is still not online, and I can only blame myself because I just took another detour (one more time against the spirit of “everything as code”, I’m not so consistent there) since I implemented a TOML parser (to be released soon). That was a great exercise in parsing but also in exploring the complexity of what is supposed to be a simple configuration language (I hope to blog about that experience separately).

When that is done, I will finally deploy my application in “production” (I’ve only deployed it and made it run for a limited amount of time for now).

All in all, it was a great year for my use of Unison. I think that this language has both niche and tremendous potential, if that makes sense! And special mention to the Unison team, you’re all amazing!

Tidbits

In no specific order, here are some other thoughts about 2024 from a tech side.

Flox

I have been using flox, my favorite package manager, for 2 years now. I really like the peace of mind that Nix brings to the table for managing my environments, with the very reasonable set of command-line instructions that Flox provides. This year brought services, easier CI/CD, installing from flakes, better support for shells, and many, many fixes and improvements. Many thanks to the Flox team for their great support, even with my sometimes convoluted configuration!

Elixir

I started using Elixir + Phoenix (Web framework) + Ecto (Persistence framework) at work. I really appreciate:

• The functional programming angle.

• A working REPL with hot-reloading.

• Hot-reloading also in Phoenix.

On the other hand, I am still not a fan of dynamic languages:

• IMO they encourage sloppy data modeling (is this a string, an atom, a Map, a struct?).

• They make the codebase harder to navigate and understand (especially when macros are involved).

• They make refactoring harder and riskier.

• Error can be hard to decipher.

• Type signatures can be added but are only checked on demand, and not particularly quickly.

I really hope that Gleam is going to replace Elixir in many applications but rewrites are expensive and risky so I wouldn’t bet on it.

Blogging

I didn’t blog a lot this year, even if I wanted to. Only 3 posts, including this one, and one of the 3 is not even about tech, it’s about Free Will!

Conferences

I initially wanted to go to ICFP Milan but that eventually did not work out. I was however invited to give a presentation at the Philips Developer Days (Thanks Rodolfo!) and really enjoyed the afternoon over there because: 1. It was in the medical sector where lots of interesting software is being developed, 2. The talks were really excellent and somewhat connected to mine (about modularity), 3. The venue was quite unusual!

jj, zed, ocaml

No, I’m not falling asleep on my keyboard. Those are 3 things I tried this year but did not pursue:

• OCaml: I didn’t do much simply because I was taken aback by the syntax (yes, I know, it is a silly reason).

• Zed: I tried it (Helix also) but 2024 is still not the year when I will get super effective with an editor.

• jj (Jujutsu): I’m convinced that we can do better than Git, and jj seems to be it. I tried it a bit but did not quite understand how to work effectively with a Github workflow based on branches. I will probably give it another go next year.

Onwards to 2025!

That’s it for 2024. If you have read so far, I hope that this post triggered some interesting thoughts for you (don’t hesitate to share!). It definitely helped me put some vague feelings into words.

I feel now ready for 2025 and I hope you are too, it’s gonna rock!

• When Scala was introduced, it brought an incredible amount of (statically-typed) functional programming features to the JVM. This changed the way we approached mutability, error management, concurrency, and structured our programs.

• Verse unifies functional-programming and logical programming, where notions of failure, multiple-valued variables, and transactions, are baked into the language. This changes the way we think about control flow.

• Unison is a frictionless language. It builds on the idea of "immutable code" to give us a huge productivity boost for writing cloud applications.

In this post, I am sharing my first steps with Unison. The parts where I was delighted but also the parts where I was confused. I will only talk about my experience of developing a small library for now. Part 2 will be about developing a full cloud application for my own needs.

First steps

I didn't need much to get started with Unison:

• An executable called the Unison Code Manager (ucm for short). It is available as a nix package, so it was very easy for me to install it with flox.

• VS Code with the Unison plugin.

I then created a quickstart project with project.create quickstart using ucm. With this project, I was all setup for coding. Here is a simple hello function:

The first unusual thing with unison is that files don't matter. A convenient setup for your editor is a split screen as above with just one file on the left, and ucm on the right. Where is my code then? It is in a database:

ll $HOME/.unison/v2
Permissions Size User        Date Modified Name
.rw-r--r--@    0 etorreborre 14 Apr 12:48  unison.lockfile
.rw-r--r--@  13M etorreborre 14 Apr 12:55  unison.sqlite3

Then, I went through the Unison language tour and learned how to:

• Search for functions: by name, but also by type!

• Create new functions and add them to my codebase.

• Test my code by either running it or writing tests.

Not impressed? Let's have a closer look!

Search by type

Haskell users know the benefits of a tool like Hoogle. With such a tool, you can search functions by type. This is soooooo convenient! "How do I serialize Text to Bytes?". Just type find : Text -> Bytes and ucm returns all the functions with that signature:

  1. lib.base.Text.toUtf8 : Text -> Bytes
  2. lib.base.IO.net.URI.Path.encode.segment : Text -> Bytes

This even works when there are type parameters (Hoogle is better though because it will also show you functions where the order of parameters is slightly different).

Add a function to the project

Once a function typechecks, you can add it to your project, or update it, if was added before. This has profound implications:

• All the code added to your project always compiles. If an updated definition conflicts with the previous version, then all the conflicting code is brought up to be fixed.

• Adding a function to your project is also the equivalent of committing it. No more git add .; git commit -m "add some code". Later on, sharing the code with others is just a matter of running push.

• Codebase changes can be reversed by using the reflog, as you would do with git.

• The project knows about functions, not just text. This means that:

  • You can easily rename a function.

  • You can give several aliases to the same function. Internally, a function is identified by the hash of its contents.

  • You can create patches that are selectively applied to part of the code, so that the result still typechecks (I haven't played too much with that though).

Run and test my code

Veteran LISP programmers know the value of having a REPL at their fingertips. With Unison, it is as simple as writing a "watch expression", with >:

That expression is automatically evaluated in ucm so you get immediate feedback on your code. Writing a test is no different, except that you give it a name, and use the test library functions:

test> hi.test = verify do
  ensureEqual (hi "Eric") "Hi, Eric!"

This test is just another term that can be added to the code base to grow the test suite. If it passes of course! Two things to note:

• When you change code in your editor, all the tests are re-executed. If those tests don't depend on some changed code, their result is cached, they are not re-executed!

• This also means that you can break previously added tests, which are present in your editor anymore, when updating a function. In that case, you can call test in ucm to re-run all the tests.

Some feedback from my first steps

I don't want to give the impression that everything is perfect. The language tour and first experience could be improved:

• In ucm, typing fn + ← does not go to the beginning of the line as it does in my zsh terminal.

• Hovering over a term shows its definition. It would be great to also be able to:

  • Show the doc.

  • Show the code.

  • Open the term in the editor to modify it.

• This would reduce the amount of back and forth switching between the editor and ucm.

• Selecting a term to edit it is a bit crude. The term to edit is added at the top of the current file and the rest of the file is commented out. In many cases, I want my existing code to stay in scope.

• Some crucial aspects of the platform are still being polished! While I was going on the language tour, the Unison team realized that the functions used to do property-based testing were not so great and revamped the whole thing. This means that some of the documentation or blog post you read about Unison might not always reflect the latest and greatest.

• Similarly, the concept of namespacing for terms (the name1.name2.term notation) is a bit in flux. There are still a number of issues regarding the interactions of ucm commands for navigating/updating the code: cd, up, ls, move,... and the qualifiers that need to be written or not in the edited code.

• The VS Code integration with ucm could be improved. Some specific windows would be nice to display:

  • All the compilation errors (and being able to jump to one of them)

  • All the tests (in the current file, in the whole project)

  • All the watch expressions (in the current file, in the whole project)

• I think I had a few bugs with the editor:

  • Sometimes ucm is happy with a function, yet the editor shows an error message.

  • If you define a == function, with its documentation, add it, and try to edit the documentation again, then the editor shows an "offset" error for (Name.==.doc).

• Since we pay less attention to files, it's easy to delete terms that were not yet added, i.e. losing that code! In that case having an editor with a good local history is important.

My first library

I want to use Unison to develop a cloud application but I think that it is important to get comfortable first with a new programming language and the full lifecycle of: coding, testing, releasing. So I decided to implement a library that did not exist yet: @etorreborre/multimap.

This library provides a data type, a MultiMap. This is simply a wrapper for a Map k vs where vs is a list of values. MultiMaps can be useful in a variety of contexts. For example, in Unison we could have a MultiMap tracking all the existing names for a given term hash.

That led me to appreciate a few more cool things about Unison.

Documentation is first class

Yes, in Unison, the documentation for a term is itself a term. It has a name, a namespace, can be added and edited. It can also be executed! This means that you can put both Markdown text in a block of documentation and some valid Unison code:

Then, the docs command executes and displays the result on the right. And eventually that documentation is published as some beautiful HTML:

Why is this important? This matters a lot because now we have a much greater incentive to write great docs:

• They always typecheck.

• They are refactored like the rest of the code when a name is updated.

• Links to other terms are always working.

• You can provide great examples inline.

Less attention to files = more focus

When writing Unison code we don't jump from file to file. We keep editing code in the same window. This means that it's perfectly ok to clear everything and just focus on one or two functions at the time, with the corresponding tests. This is strangely liberating.

Less attention to files = more normalization

Many people came to the idea that a good syntax formatter was the best way to put formatting discussions to rest. For example, Go came up with a default formatter from the start, and in Haskell, a "no-configuration" formatter like ormolu, won the hearts of many teams.

Unison goes one step further since no text is really stored, only an AST. This means that you don't really care if you prefix all your functions with their namespace, or add a bunch of use clause at the beginning of the file. Eventually the code will be stored and rendered in the same way. For example:

use MultiMap empty size isEmpty
test> MultiMap.tests.ex1 = verify do
    size empty === 0
    isEmpty empty === true

is reformatted as:

MultiMap.tests.ex1 : [Result]
MultiMap.tests.ex1 = test.verify do
  use MultiMap empty
  MultiMap.size empty === 0
  MultiMap.isEmpty empty === true

Todo

This is a small but useful thing when you use types to design your code. For example, you know that you will need a function with a given type but you don't want to lose focus by implementing it right away. Just leave todo as its implementation. This is always a valid term!

Testing

Testing is great! Unison comes with an effect system, called abilities, where a piece of code can interact with a handler to decide how the computation should be executed. This possibly sound nebulous, but you probably have already used something like this if you have:

• Thrown exceptions. Then, a handler knows what to do with the exception. "Resumable exceptions" are even better since the handler can provide a value to continue the computation.

• Used async in Rust. The handler is an executor that puts the current code on hold, then resumes it when a thread is available.

• Used a generator in Python with yield. In that case, the handler uses the yielded value then resumes the code, to get the next value.

The abilities used for testing in Unison are:

• Random to provide randomly generated values.

• Each to repeat a piece of code, possibly with a different value, taken from a list of values.

• Exception to abort the test in case of a failure.

This means that you have a very convenient way to mix enumeration testing, where data is tested exhaustively, and random testing, where you let randomness explore the test data. You can read some examples on Paul Chiusano's blog post on the subject.

Publishing the library

Publishing a library is very easy:

• Provide a README, in the form of a documentation term called,... README.

• Use the License datatype to provide a license for your project (and mit as a LicenseType for example).

• push and press the Cut a new release button on the project page.

Some question marks

The MultiMap library is not so small. It contains more than 200 terms and 2000 lines of code (counting the documentation. It's code, right 😊?).

With this library I could get a taste of what it meant to work with larger projects in Unison and ask myself a few questions.

Namespaces

Namespaces are mostly irrelevant for a library like MultiMap since everything is at the same level. But where do you put tests? Possibly, we want to separate the testing code from the "production" code. I opted for the MultiMap.tests namespace (Unison's base library does things a bit differently). This has the advantage of offering a clear separation, and if you want to have a look at all the tests you can edit.namespace MultiMap.tests.

There is also a bit of "convention over configuration". The lib namespace in a given project is treated specially. It contains all the project dependencies, including Unison's base library. If you want to upgrade that library or add another library as a dependency you need to pull it, inside the lib namespace:

pull @unison/json-core/releases/1.0.3 lib.jsonCore_1_0_3

As you can see, there are no real constraints for going from json-core/releases/1.0.3 to lib.jsonCore_1_0_3. I think I would have preferred a pull dependency @unison/json-core/releases/1.0.3 command doing the right thing for me.

I also made the mistake of pulling the full Unison base library directly into my top-level namespace 😰. Then I really had to learn how to remove terms and namespaces 😁.

Privacy

Closely related to namespaces is privacy. There's no notion of public/private in Unison and no notion of modules. Only namespaces. In MultiMap there are only 2 functions that are implementation functions. I decided to "hide" them in a private namespace.

I think that having the ability to truly forbid some terms to be seen outside of their packages would help when scaling Unison programs to large programs.

No typeclasses

I like to call typeclasses "interfaces for data types", and as such, I think they play an important role for modularity. They also come with all sort of questions:

• How do you pass typeclass instances where needed?

• How do create/resolve typeclass instances?

Unison does not have typeclasses, and I can understand why. While they are incredibly convenient, they also make a programming language a lot more complex. OCaml, or Elm, for example, are two functional programming languages with no support for typeclasses.

As a matter of convenience, Unison has universal equality and universal ordering, which are both structural. What does that mean?

This means that when you define any data type, for example Person, equality and ordering are based on what is inside the data type:

type Person = {
  name: Text,
  age: Nat,
}

The Universal.eq and the Universal.gt functions compare 2 Persons first based on their name, then on their age. This even works with functions! Two functions are equal if the hash of their content is equal.

Structural equality is not controversial, but structural ordering is more questionable:

• We might want to define different orderings for the same data type.

• I'd rather avoid breaking code if I simply swap two fields in my data type.

As a result, some Unison APIs use a comparison function parameter to specify exactly how elements must be compared. But this is not the case for some data types like Map or Set.

Large refactorings

While developing the MultiMap library, I inadvertently set myself up for a large refactoring. I initially started with MultiMap = Map k [v] and later, much later, realized that a more correct definition was MultiMap = Map k (List.Nonempty v).

Changing the datatype, and trying to add the new definition, triggered the typechecker, which was very unhappy with this change. ucm brought most of the definitions into scope and told me to fix them. This has been unfortunately a bit painful experience:

• Only some errors are displayed at the time. Fixing one issue triggers another issue in a different place and you don't really know when the whole process is going to stop.

• Some names were replaced with their hash.

• After fixing all issues in sight, I entered update but ucm told me that some code was still not compiling, commented out all the previous code, only to put another wall of text in front of me. Was it some new code, a bit of the old code that was still not compiling, some additional tests? Eventually, I had the impression of writing some fixes twice.

That made me wonder if more tooling was needed for large codebases, in order to support deep refactorings.

My first contributions

During the development of the MultiMap library, I added a few functions that were missing from the List and List.Nonempty data types. The whole process was really simple:

• Create a branch in @unison/base: branche.create /mybranch.

• Add some new functions + doc + tests.

• push.

• Open a contribution in the corresponding project (much like a pull request in Github).

All of this, except the last step, is done in ucm and I can foresee a future where even the last step is supported in ucm so that you don't even have to leave your development environment to collaborate on projects.

Conclusion

Despite some of the shortcomings mentioned above, I can't wait to develop my first cloud application. This is going to be an application for importing bank data into my accounting software. My prediction is that most of the difficulty will come from the core of the application:

• Dealing with authentication on both systems.

• Navigating both data models.

• Determining what is "new" data and what is already imported data.

I hope that, on the contrary, thanks to Unison Cloud, the technical aspects will be a breeze:

• Deploying the application.

• Monitoring it.

• Using secrets.

• Interacting with HTTP APIs.

• Maybe storing a bit of data.

Stay tuned for part 2, and don't hesitate to give Unison a go, it is really a refreshing experience!

After watching the videos, I read "Why zebras don't get ulcers". That book made me think twice about the devastating effects of stress on the human body. I followed with "Behave: the biology of humans at our best and worst", which explores the biology of how nice or terrible we can be to each other. That book quite convincingly makes the case that our sense of ethics, and our actual actions, are determined by what happens in our body, from one second before, to one day before, to years ago (and even millennia if you account for evolution).

Robert Sapolsky's new book, "Determined, a science of life without free will", follows the same thread to reach some troubling conclusions:

• There is no free will.

• Yes, really, wherever you're looking for it, you can't find it.

• This changes how we see the world in terms of responsibility, punishment, merit.

The revolting biology of our actions

The book is divided in two parts. The first part goes into the biology of our behavior and shows that there's no place to shoehorn free will. The second part tries to draw some social conclusions.

Robert Sapolsky was reluctant to write this book. Although he became convinced at an early age, just 14 years old, that free will does not exist, Robert Sapolsky is well aware that he represents a minority position. Most people, including scientists and philosophers are "compatibilists". They acknowledge that we are determined by all sort of influences, yet we still have have free will. We must have. Otherwise the world makes no sense. Don't even suggest it, this is revolting!

With this book, Robert Sapolsky proposes to avoid jumping to a conclusion that we would like to prove. He just asks: "ok, where is free will because I can't find it? The more I search, the more I see things over which we have no control".

Who is really pressing our buttons?

Prof. Sapolsky starts with presenting the neuroscience behind our decisions. A wildly debated series of experiments, initiated by Libet more that 40 years ago, shows that actions are in motion in our brains well before we are conscious that we want to take those actions. Consciousness is an afterthought, after biology has triggered the right neurons.

Even our judgements are an afterthought. Put some people in a room with a fetid odor and ask people to judge if some behavior is moral or not. The experiment shows that subjects tend to be more conservative. Why? Because the neurons processing for physical disgust (in order to avoid food poisoning) are the same as the neurons processing for moral disgust! It even goes both ways. When people make bad actions, they want to clean-up!

What is fascinating is that we are not aware of those influences. Ask the subjects being tested and they will post-rationalize why they became more conservative.

This is however not enough to put the last nail in the coffin of free will. Let's consider another example. Our amygdala quickly triggers fear in us when we see faces of a different skin color. This works in under one tenth of a second and we don't have control over this. Fortunately, our pre-frontal cortex (PFC) comes-in next to reason about it: "it's ok, there's no reason to scared" (unless you are unabashedly racist 🙁).

The compatibilist rejoices: "Ha, you see, I can decide to not succumb to fear!". Well, not really. The amount of stress you have today, and over which you have no control, will make it hard to calm down your amygdala. Some genetic deficiency, or head concussion will also make it hard for the PFC to play its role. All of these causes have been thoroughly studied now, and there's little you can do about it. This shows for example when you have to decide if someone putting their hand under their jacket is going to draw a gun or their phone.

What exactly decides what happens in the PFC when it takes a decision? Sapolsky goes back in time to show that any activation now, is the result of:

• What happened a second before: are you under a sudden stress?

• To hours before: are you hungry? Hungrier judges give harsher sentences.

• To days before: do you have a lot more estrogens in your blood? Hormones have tremendous influence: give vasopresin to a polygamous mole and it becomes monogamous! Give oxytocin to people and they become more cooperative,... but only with US, not THEM!

• To years before:

  • Were you mobilized and came back with PTSD?

  • Did you have traumas in your childhood? The "Adverse Childhood Experiences" score is a good predictor of future difficult behaviors.

  • How was your mother when you were in her womb? Economically stressed, depressed? We can see the impacts on your brain.

  • Did you grow up in a nice or in a terrible weather? Yes, it has a noticeable impact too.

  • Which genes did you inherit from your parents? How were they expressed or not?

• To centuries before: do you originate from a collectivist or an individualist culture?

The more we look for biological explanations, the more we find them. They stack up, we find the causes that cause the causes. It's "turtles all the way down".

Surely there must be some space for free will

Free will advocates still want to prove that, beside all the biological explanations for our thoughts and actions, free will has to exist. Some common arguments are:

1. We cannot predict everything, so there is something that allows us to make decisions, our decisions.

2. Physics is fundamentally quantic and this radical indeterminacy is the root for our free will.

3. Beyond basic biology, there is some high-level conscience / intelligence that cannot be explained via low-level mechanisms.

What is Sapolsky's answer to those arguments?

Determinism vs predictability

The fact that we cannot predict the evolution of a system does not mean that it is not deterministic. The Game of Life is a system with very few rules, which can be simulated on a computer:

It is however undecidable. There is no algorithm allowing us to say if a given pattern is going to appear once you start the game. The only way to know, is to run the game, possibly for an infinite amount of time. Very deterministic rules, unknown outcome.

Another example comes from Chaos Theory. Take the equations for gravitation, apply them to 2 bodies (2 planets, 2 stars, etc...) and you will be able to predict their movement. Try to do the same with 3 bodies and all of a sudden the trajectories starts having fluctuations that are non-periodic and very dependent on the initial state of the system.

Not only it is hard to predict the future of some purely deterministic systems, but it can also be difficult to recover their past! A given position in the Game of Life can result from two completely different initial states. Some positions don't have any antecedents (also an undecidable property).

Clearly, determinism does not mean predictability.

Quantum entanglement

It is quite fascinating to see how science can be the perfect medium for pseudo-science. The discovery of electricity and magnetism generated all sorts of demonstrations that "magnetic waves", "energy flows", could heal you (provided that you shell a significant amount of your hard-earned cash of course). Similarly the development of quantum mechanics brought us quantum healing and quantum organizations (I just googled the terms, and, of course, got some results 😁).

Quantum physics is truly hard to grasp (in the words of Richard Feynman, "If you think you understand quantum mechanics, you don't understand quantum mechanics"). Maybe this is where we can break the diktat of "we are determined". Indeed, the theory presents some radical indeterminacy, some truly random variations. Could this be at the root of free will? This is very unlikely:

• Quantum physics happens at minuscule scales and collapses at larger scales like the wet and warm environment that is the brain.

• So far, no convincing mechanism has been shown, where the quantic states of particles would eventually, all together, have an influence on a motor neuron.

• Same thing the other way around. We have not shown how our conscious thoughts could have an effect at the quantum level (and this would leave some kind of chicken and egg problem, on how this then generates an action).

• Even if there was a quantum mechanism at the heart of free will, what does that say about it? That free will is fundamentally the result of a random process?

Intelligent design

Maybe we are being too reductionist? Maybe free will is more than just the sum of our hormones? Maybe it is something that emanates at a higher-level?

Indeed, Nature showcases many complex behaviors that are emergent:

• A few ants don't do much. An ant colony builds cathedrals.

• Bees communicate to find where the best flower fields are.

• Slime mold, a uni-cellular organism, solves a maze.

• Our blood system branches like fractals to cover our whole body.

Amazing, but in each case, the overall behavior is still explained, and caused, by simple behaviors. In the case of the blood system for example, there is no central architect gene/hormone/brain region creating the full topology. Instead, one gene codes for the branching factor: when to branch vessels and when to stop. Not only that, but the same gene supports the notion of branching for other parts of our body, like neuron dendrites.

What is causing high-level, sophisticated, behaviors is eventually just a potent mixture of simple parts. There is no need to invoke another organizing principle.

Where to go from there?

Robert Sapolsky is profoundly convinced that we are nothing more than the sum of our biology, which we can't control. This is also totally obvious to me, I see it as Occam's razor in action. No need to invoke "free will", a "soul", some transcendent "self", to explain our behaviors. While this would answer one question, it would raise a lot more: where does it come from? How is it built? How long does it last? etc...

Yet, we are so used to the impression that we decide, that we act, that we take responsibility. Isn't that what we learn from the youngest age? Absolutely. The pre-frontal cortex is the last part of the brain to mature, around the age of 25, because we have to be taught: "what's the hard thing to do, when it is the right thing to do" (see what I did? Still biology at work).

Now, if we start telling people that there is no free will:

1. Are they going to run amok?

2. Are we even capable of changing?

3. Does it still make sense to punish people?

4. Does it still make sense to reward people?

No free will = headless chickens?

This is a valid concern. It is also a concern frequently expressed by religious people when discussing with atheists: "If you don't have anything objective on which to base your ethics, what prevents you from going mad?".

Experimentally, the answer to that question has several layers. Religious people are more prosocial and give more to charity that secular people. But when you control for all factors: age, sex, wealth, then the results are less drastic. Even less so when you inquire about what people say they do and what they really do. You might eventually still find a little more prosociality in the religious group. With a catch, though. It is mostly for the in-group. It is mostly for the US, not THEM. Religious people are more charitable but mostly towards their co-religionists. Ultimately, it cannot be proven that atheists have lower ethical standards than religious individuals.

Similar kind of experiments can be performed with free will believers and non-free will believers. Subjects being told about the absence of free will are more likely to cheat in economic games. Yet, if you test people who have held this position for a long time, they are no less ethical than believers. Even better, the more they think that free will does not exist, that there's no wiggle room for it, the stronger their values will be.

Ultimately, it has been observed that, whatever your credo is, religious/atheist, free will believer/non-believer, what matters most is the time you have spent deeply thinking about it.

How many free wills does it take to change oneself?

Seeing the world as fully determined can be a bit terrifying. We can easily think that given the cards we are dealt, we will never change. This is far from being the case. In the book, our bearded friend, explains in detail, at the neuronal level, how a sea slug, Aplysia, adapts to external aggressions. Progressively, a feedback loop, made of neurons, learns that it should protect the slug gills for longer period of times, until it is possible to come back to normal.

Mind you, we share the same mechanisms for learning and adapting that this sea slug. Even though it is a very, very, distant cousin, sharing a common ancestor with us more than 2 billion years ago!

Another example. Your mum is stressed while pregnant with you. As a result, she feeds you a lot more glucocorticoids than necessary and your amygdala (a part of the brain dealing with stress and fear) grows larger. As a kid, your resting levels of glucocorticoids are higher than average and you tend to be more reactive to stressors. Fortunately, you start a talking therapy at the end of your adolescence. Progressively, your amygdala gets less active. It has been more regulated by other parts of your brain.

The conclusion is that, it is not so much that we change, but we are changed. We are changed by our environment, by our interactions, and by the innate biology which allows for changes to occur.

Bad boy / bad girl

Sapolsky presents several examples where we previously believed people were truly bad or weak before understanding the underlying biology at work.:

• Witches being burned because they were having epileptic seizures, or because villagers thought they were causing diseases.

• Schizophrenia, which was attributed to bad parenting and "double-bind", before we discovered its genetics origins.

• Similarly, autism, attributed to cold, distant mothers ("Refrigerator mothers").

• PTSD, for Gulf War soldiers, who were described as "weak", before it was understood that prophylactic pills triggered it.

When we read about these examples, in the 21 century, we tend to think: "Of course, they were not witches", "Of course, John Nash was not psychotic because his mother was a monster, but probably because his circuitry for dopamine was not well-regulated". Etc... Yet, if we take the example of schizophrenia, it took years of concerted efforts, from family members, to lobby doctors and politicians to change the perception around that disease, even as we started to understand its causes.

This begs the question: what are the behaviors that we consider today as emanating from fully-responsible persons and which will be considered as having fully biological causes in 100 years? (if you've read so far, you should know. All of them 😀).

Still, what should we do when someone does something wrong? If we follow Sapolsky's reasoning, are we going to blame the car because the brakes are faulty? The author proposes a model similar to a medical quarantine:

1. People have diseases, they have bad behaviors.

2. It's not their fault.

3. It is ok to protect others by constraining the freedom of infectious or dangerous people.

4. We should constrain these persons with the absolute minimum necessary to protect others. Nothing more.

Wait, shouldn't we at least use punishment as a deterrent? What do studies say? This does not work. Ok, but maybe, bad persons deserve to be punished?

The need for punishment as the just retribution for crummy behavior is well-tested experimentally. It brings some measurable level of satisfaction. But, here again, there are some subtleties. For example, capital punishment can be more traumatic for families of victims. Furthermore, we have collectively evolved significantly in terms of the severity we expect from punishment. (I will let you read the horrific description of what happened to the assassin of Louis XV in the book).

A notable example is the case of Norway and the methodic crimes of Anders Breivik. Breivik was eventually not recognized as schizophrenic (yet, unsurprisingly, "[his mother] 'sexualised' the young Breivik, hit him, and frequently told him that she wished that he were dead". Surely that didn't help).

More or less, Norway adopted the quarantine approach: they put away the criminal for 21 years (the maximum sentence), in humane detention conditions, and even provided the possibility to study. One survivor said: "If he is not deemed dangerous any more after 21 years then he should be released ... That's how it should work. That's staying true to our principles and the best evidence that he hasn't changed our society". That is impressive. Many other societies would have considered Breivik's execution as a moment to celebrate.

Good boy / good girl

Another consequence of not having free will, is that we cannot be utterly smug for our achievements.

If you've had the right genes, the right emotional support as a kid, parents playing board games with you, a variety of experiences, a healthy body, a well-formed PFC supporting your will to pursue your objectives, and now you have a nice corner office, good for you. But you don't really deserve it, no more than a kid growing up with lead in his tap water deserves to have a low IQ.

Sapolsky says that some of his students get destabilized when they hear they don't get to be entitled for their brilliant future:

- "Hey, I worked hard for it!"

- "Yes, if you are here, you are among the really lucky, lucky ones"

Are we wiser now?

I think we are. First off because, on the road to recognize that we don't have any free will, we haven't deviated from science. We didn't need to invoke any supreme or transcendental principle at the core of our existence.

Secondly, nothing is lost! I still have a very strong sense of myself, and the belief that the actions I take today have significant consequences for my future, the future of my family, and society. (well, that's debatable 😅). In a sense, me, my body, is playing the real Game of Life (™):

• With rules that I haven't decided.

• With handicaps and strengths that have been dealt for me.

• With tangible gains and losses at each turn..

• With an objective that is not clear.

• With the privilege of playing the game and simultaneously observing it being played.

• With the certitude that the game will end!

I have also gained the knowledge that:

• I can be gentle with myself. It is not just a matter of willpower if I cannot remember every fact that would be useful at work.

• People can behave badly around me, and against me, but I don't have to blame them. Protecting myself is enough. Preventing them to do more harm is enough.

• Maybe what I can do, with the remaining illusion of free will that remains, is to put myself in the conditions to be better influenced in the future: get good sleep, eat well, exercise, manage stress, do as much good I can around me, etc...

• I can also position myself in the conditions to be changed for the better: read books challenging my thoughts, meet new people, share my interests,...

In more philosophical terms, Robert Sapolsky's book places us, not as actors, but as acted, in the meaningless and glorious story of the Universe. I am fairly certain that some Greek philosophers would have smiled in approval.

N.B: the summary above is a crude approximation of this wonderful 500+ pages book. All mistakes are mine, I hope you will kindly correct them by reading the book for yourself.

This is particularly true in the world of functional programming with techniques such as:

• "failure" datatypes: Option, Either, Validation

• lenses / optics

• recursion schemes

• generics / type-level programming

• effect libraries: effectful, cats-effect IO, ZIO,...

• the "typed tagless final" approach

Today I want to give a proper, real-life, example of using the so-called "Typed tagless final" approach. Over the years I have become quite frustrated with how this topic was presented. In the eyes of many people this is mostly a way to create interfaces where the result of each operation has an effect abstracted as a type variable:

trait CustomerRepository[F : Monad] {
  def saveCustomer(c: Customer): F[()]
  def getCustomers(): F[List[Customer]]
}

In practice F ends up being a type permitting side-effects like IO. F might also end up being State[RepositoryState, _] in order to write tests purely in memory for example.

I generally argue that:

1. This is merely using interfaces, parametrized with an effect.

2. In that case, this does not deserve a complicated and scary named such as "typed tagless final".

3. The "typed tagless final" approach is much more interesting and covers a different topic than building a system based on modules and interfaces.

What is it really?

You will find the best reference on the topic on Oleg Kiselyov's website:

1. This is a way to create internal Domain Specific Languages (DSL). "Internal" means that terms are embedded directly in a "host" programming language.

2. The DSL terms can be well-typed. The type-checker of the host language guarantees it.

3. The DSL terms can be interpreted in a variety of ways: evaluation, printing, optimization (in a type-preserving way), etc...

4. The DSL is extensible: new term types can be introduced, existing interpreters can be reused.

Why "Typed tagless final" then? In short:

• Typed DSL terms can be typed

• Tagless DSL terms do not require to embed tags to keep track of their type

• Final DSL terms are not constructed as a specific data type but rather via functions

This possibly looks quite interesting, but still very abstract. Moreover, if you look at examples, most of the time they are about creating a DSL for:

• A simplified arithmetic language, or

• A version of the Lambda Calculus.

Those are hardly real-life examples.

Data serialization to JSON

Data serialization is (sadly) an essential part of many software projects, with many pitfalls in terms of correctness, performance, maintenance, and productivity.

For example the question on how to evolve serialization protocols, so that we can reuse most of our serialization code from one version to another, is not entirely trivial.

I have created a library registry-aeson, based on the aeson Haskell library, to propose a solution to this problem. That library is structured around two data types, Decoder a, to decode a value of type a from some JSON text, and Encoder a to encode a value of type a to a JSON value.

Encoding values seems a bit more straightforward than decoding them because there's no need for error management, but this is not the case! For performance reasons the aeson library proposes a ToJSON typeclass with 2 methods:

class ToJSON a where
  toJSON :: a -> Value
  toEncoding :: a -> Encoding

toJSON creates a Value which can be a String, an Object, an Array etc... (all the types that we expect from a JSON data type). However, if we only had this method, we would spend time encoding to an intermediate data structure then transforming this structure to some bytes on wire. That is pretty ineffective.

This is why the toEncoding method exists. To transform the value a directly into bytes, using specific combinators. For example: string "hello" or pairs (pair "name" value).

In the registry-aeson library, the first version of the Encoder data type was:

newtype Encoder a = Encoder { encode :: a -> (Value, Encoding) }

In order to define an Encoder you need to return both a Value and an Encoding, like the ToJSON typeclass does. But this is very tedious, in particular because the API to create values and encodings are very different in the aeson library.

For example if you want to serialize a data type with both field names and values:

• If you want to create a Value: you build an Object with a KeyMap from a list of keys and values.

• if you want to go to ByteString directly: you make pairs with a Series of encoded values built with the pair combinator.

What if we could have one expression and interpret it to either a Value or an Encoding? This is exactly what the Type Tagless Final approach gives us!

A JSON algebra

We are going to define operations that allow us to build simple JSON terms, with only strings, ints and maps:

-- | Operations used to create JsonTerms
data JsonAlgebra a = JsonAlgebra
  { string_ :: Text -> a,
    int_ :: Int -> a,
    object_ :: [(Key, a)] -> a,
  }

-- | Polymorphic JSON term. It can be interpreted later
newtype JsonTerm = JsonTerm {term :: forall a. JsonAlgebra a -> a}

-- | Interpret a JsonTerm via a specific algebra
interpret :: JsonTerm -> JsonAlgebra a -> a
interpret (JsonTerm t) j = t j

-- | Top-level JSON DSL operations
string :: Text -> JsonTerm
string t = JsonTerm $ \ja -> string_ ja t

int :: Int -> JsonTerm
int b = JsonTerm $ \ja -> int_ ja b

object :: [(Key, forall a. JsonAlgebra a -> Pair a)] -> JsonTerm
object vs = JsonTerm $ \ja -> 
  object_ ja ((\(k, v) -> (k, interpret v ja)) <$> vs)

• A JsonAlgebra a defines operations to build a concrete type a. In our case we are eventually interested in a = Value and a = Encoding.

• A JsonTerm is something that uses a concrete JsonAlgebra a and returns any a specified by that algebra.

• The string, int, object functions are the top-level functions of our JSON DSL. They are the common API to build both Values and Encodings.

Let's see an example of a JsonTerm. For example the JSON value:

{ "name": "eric", "credits": 100 }

can be represented with the JsonTerm:

let term :: JsonTerm = 
  object [("name", string "eric"), ("credits", int 100)]

This JsonTerm can be interpreted via concrete JsonAlgebra implementation. We can create such an algebra to build Values:

valueJsonAlgebra :: JsonAlgebra Value
valueJsonAlgebra = JsonAlgebra {..}
  where
    string_ :: Text -> Value
    string_ = String

    int_ :: Int -> Value
    int_ = Number . fromInteger . integerFromInt

    object_ :: [(Key, Value)] -> Value
    object_ = Object . fromList

This algebra replaces each invocation of a function in a JsonTerm with an implementation building a Value. Hence, if we apply it to our term above we get a Value:

let value :: Value = interpret term valueJsonAlgebra

> print value
> Object (fromList [("name",String "eric"), ("credits",Number 100.0)])

We can also define an implementation building an aeson's Encoding:

import Data.Aeson.Encoding as E

encodingJsonAlgebra :: JsonAlgebra Encoding
encodingJsonAlgebra = JsonAlgebra {..}
  where
    string_ :: Text -> Encoding
    string_ = E.text

    int_ :: Int -> Encoding
    int_ = E.scientific . fromInteger . integerFromInt

    object_ :: [(Key, Encoding)] -> Encoding
    object_ = E.pairs . foldMap identity . fmap (\(k, v) -> E.pair k v)

This time we can interpret our JSON term directly as an Encoding (more or less a ByteString):

let encoding :: Encoding = interpret term encodingJsonAlgebra

> print encoding
> "{\"name\":\"eric\",\"credits\":100}"

Two interpretations for the same term! Now, users of the registry-aeson library don't have to produce 2 expressions, with a different API, to generate efficient JSON 🤗.

Putting the "typed" in "typed tagless final"

Our DSL is well-typed. It is not possible to use its API to build terms which cannot be meaningfully interpreted. However, it is not quite optimal because we are missing the point of aeson's Encoding a bit. Our object operation requires building tuples and putting them in a list instead of building a ByteString right away.

On the other hand, the documentation for Encoding shows this example:

toEncoding (Person name age) = pairs ("name" .= name <> "age" .= age)

In the example above:

• "name" .= name creates a Series which directly contains the serialized string "name":"eric"

• It is appended with <> to another Series to directly create the comma-separated string "name":"eric","age":100

We need better operations and better types!

Here is another version of the JsonAlgebra:

data JsonAlgebra r = JsonAlgebra
  { string_ :: Text -> r (),
    int_ :: Int -> r (),
    pair_ :: Key -> r () -> r Key,
    empty_ :: r Key,
    concatenate_ :: r Key -> r Key -> r Key,
    object_ :: r Key -> r (),
  }

This time we introduce 3 new operations, almost as a sub-DSL:

• pairs_ to create a key/value pair, ready to be added to other key/value pairs

• empty_ to denote the empty list of key/value pairs

• concatenate_ to concat 2 lists of key/value pairs

We also use another representation, r, parametrized by a type in order to track the type of term we are constructing:

• r () is for regular terms denoting normal JSON values

• r Key is for lists of key/value pairs being constructed before being passed to the object_ function. We can choose any type that is different from (), I just chose to reuse an existing type.

This new representation still guarantees that our DSL is type-safe, but with no need to introduce types like lists and pairs in the algebra operations.

If we add new top-level functions, we can see the new operations in action:

pair :: Key -> JsonTerm () -> (forall r. JsonAlgebra r -> r Key)
pair k v ja = pair_ ja k (interpret v ja)

(><) :: (forall r. JsonAlgebra r -> r Key) -> (forall r. JsonAlgebra r -> r Key) -> (forall r. JsonAlgebra r -> r Key)
(><) = concatenate_ ja (v1 ja) (v2 ja)

object :: (forall r. JsonAlgebra r -> r A.Key) -> JsonTerm ()
object vs = JsonTerm $ \ja -> object_ ja (vs ja)

Now we can build a term with:

let term :: JsonTerm = 
  object $ (pair "name" (string "eric") >< 
           (pair "credits" (int 100))

In this example, we are really concatenating pairs of key/values, as we go, without having to build an intermediary list of tuples (this is very similar to what happens in the Encoding API of aeson).

Can we still get both Values and Encodings from such a term? Absolutely, we just need to find the right implementation and representation for each concrete algebra.

Our previous algebras were parametrized with Value and Encoding, now we will use Values and Encoded:

data Values k where
  SingleValue :: Value -> Values ()
  ManyValues :: [(A.Key, Value)] -> Values A.Key

valueJsonAlgebra :: JsonAlgebra Values
valueJsonAlgebra = ...

data Encoded k where
  Encoded :: Encoding -> Encoded ()
  CommaSeparated :: E.Series -> Encoded A.Key

encodingJsonAlgebra :: JsonAlgebra Encoded
encodingJsonAlgebra = ...

It is not hard to implement each JsonAlgebra with those data types:

• Values simply accumulates key/value pairs in a list when the pair_ and concatenate_ operations are called.

• Encoded re-uses the Series data type defined in aeson's Encoding to efficiently create comma-separated string as key/value pairs are being added.

Now interpreting a JsonTerm with a JsonAlgebra produces either a Values value or an Encoded value. We need 2 more functions to produce a Value or an Encoding:

toValue :: Values k -> Value
toValue (SingleValue v) = v
toValue (ManyValues vs) = Object . fromList $ vs

toEncoding :: Encoded k -> Encoding
toEncoding (Encoded e) = e
toEncoding (CommaSeparated s) = E.pairs s

Wrapping-up

This whole post will probably look a bit scary if you have never read about the (proper) typed tagless final approach (or if you are new to Haskell and aeson 😄). Let me summarize:

• We have defined a DSL to create simple JSON terms with strings, ints and maps.

• This DSL uses the operations:

  • string

  • int

  • pair

  • object

      let term :: JsonTerm = 
        object $ (pair "name" (string "eric") >< 
                 (pair "credits" (int 100))
    

• We can eventually interpret a DSL term to either:

  • a Value to do JSON manipulations

  • an Encoding to efficiently serialize data to binary

I hope that this blog post will encourage you to read more about this technique for creating DSLs, you never know when you might need it!

Today I want to talk about what makes a big difference for me when developing applications that are sufficiently large, both in terms of components and data model.

I hope you'll share your thoughts on this topic as well!

Data representation

Properly modeling the domain of an application is crucial. Think about it, the data types that we are defining are going to be used almost everywhere in our application!

What can go wrong?

Here are some of the problems that arise when we fail to model our data correctly:

Consistency

If an Order and an InventoryItem reference the same Product but have a product_id field which can be set to disagreeing values.

Meaning

Imagine a field name with an ambiguous meaning: expiry: Long. Is it a Date, a Duration, what is the unit: Minute, Seconds?

Even if the field is well-typed: expiry: Date, what does this mean? Can I still create an Order for a Product with this expiry date? What if that field is also used to include the product or not in marketing campaigns? Now that field might have one value but 2 meanings.

Precision

How many times do we see String fields where restrictions should apply? For example, newlines are rarely allowed in a name. Accepting them at one end of the system might completely break the UI at the other end of the system, or another system for that matter.

The same goes for the use of Int in Scala for example:

case class Person(name: String, age: Int)

Really, can a Person have -20 as its age? One satisfying thing with Rust is that it knows the price of everything, so there are all sorts of unsigned integers. At least we have a way to represent (and calculate with) natural numbers:

struct Person {
  name: String,
  // min value: 0, max value 255
  age: u8,
}

Coupling

It is very easy to model data that encompasses too many concerns:

case class Customer(
  name: Name,
  age: Age,
  address: Address,
  occupation: Occupation,
  currentBalance: Balance,
  account: Account,
  acquiredVia: MarketingCampaign,
  openLitigations: List[Litigation],
)

You get the idea... When data mixes too many concerns it implicitly couples all the components that deal with these concerns. This is the recipe for a lot of code churn.

🧰 What do I want?

Data definition

To be precise with data modeling I expect a few things from my programming language:

• Structs and enums (+ pattern matching on enums).

• Non-verbose data declarations (Scala, Haskell, and Rust do this well), so I don't fear creating a Name data type if I need to.

• Good libraries for common quantities: dates, times, money, memory size.

Data input and parsing

I give bonus points to languages giving me the ability to define well-typed literals at compile-time:

val address = url"http://google.com"

A more elaborate version for defining and parsing correct data is supported by the refined library in Scala:

scala> type ZeroToOne = Not[Less[0.0]] And Not[Greater[1.0]]
defined type alias ZeroToOne

scala> refineMV[ZeroToOne](1.8)
> error: Right predicate of (!(1.8 < 0.0) && !(1.8 > 1.0)) failed

Standard type classes

It should be completely trivial to add derived behavior to a data type for:

• Equality.

• Optionally ordering or hashing.

• Showing, debugging.

Again, Scala / Haskell / Rust, make this very easy.

Data output

One word about using Show / Debug instances. Those instances are fine to display data by default. However, I found it extremely useful to define a specific trait, say Output, dedicated to a domain representation of values. For example, if a Warehouse has a list of loadedDocks which are generally loaded in order, it is nicer to represent:

Warehouse: East-London-1
  loaded docks: 1..7

Rather than:

Warehouse: East-London-1
  loaded docks: 1, 2, 3, 4, 5, 6, 7

The ability to display things concisely pays off in the long run when writing tests and debugging. This is very domain-dependent but some utility functions around text can be useful:

• To pretty print lists.

• To pretty print tables (with aligned columns, and/or wrapped text).

• To create ranges.

• To make a name plural based on a quantity: n.times() == "3 times" .

Serialization

Serialization is the unfortunate consequence of the fact that systems are rarely just isolated islands, they need to communicate with other systems.

Let's start with a 🌶️ take:

Derived instances are an anti-pattern

Now that I've made enemies with 90% of the profession I need to explain my viewpoint 😀. A derived instance for serialization is some code that the compiler generates automatically for a data type to serialize its values. For example:

data Employee = Employee {
  name :: Name,
  age :: Age, 
} deriving (Eq, Show, Encode)

In the example above we simply annotate the Employee data type with Encode then we get the possibility to encode values:

encode (Employee (Name "eric") (Age 100))) == 
  "{ 'name': 'eric', age: 100 }"

I will keep the argument short but the main problem with this facility is that we couple our domain model too much with the serialization concern:

• We end up defining some attributes only so that it helps the serialization.

• Serializing to different formats might place incompatible constraints on some attributes.

• We cannot easily support several serialized versions representing the evolution of a protocol over time.

• We hand over the serialization to a library that uses meta-programming to decide how to serialize data and might not do it most efficiently.

In the end, serialization becomes a burden and slows down the evolution of an application.

🧰 What do I want?

Rather than having to reconcile domain needs to serialization needs all the time I simply prefer to have the ability to write encoders and decoders manually.

Defining one encoder

That sounds horrible but not that much with a good programming language and some library support:

makePersonEncoder :: Encoder Name -> Encoder Age -> Encoder Person
makePersonEncoder name age = \Person { n, a } -> 
  array [encrypt (encode name n), encode age a]

I can decide exactly how I want to encode the 2 fields here, as an array or a map, but I can also decide that I want to encrypt the name, with no impact on my domain model.

And if my data type is not fancy, I should be able to access some macros to do the simple, default, case:

makePersonEncoder = makeEncoder ''Person

Wiring everything together

The other advantage of derived instances is the ability to wire all the instances together for a whole data model. Doing it manually is not much fun:

orderEncoder :: Encoder Order
orderEncoder = 
  makeOrderEncoder 
    (makeCustomerEncoder (makeNameEncoder stringEncoder) 
                         (makeAgeEncoder intEncoder))
    (makeProductEncoder (makeProductIdEncoder stringEncoder) 
                        (makeDescriptionEncoder stringEncoder))

There is however one great advantage! We can now modify this wiring to evolve the serialization independently from the domain model. For example, if there is a new attribute for a Customer, we should still be able to serialize an old customer for the new data model, to communicate with a system that hasn't upgraded yet:

-- old version where the age of the customer was needed, now it's not)
orderEncoderV1 :: Encoder Order
orderEncoderV1 = 
  makeOrderEncoder 
    (makeCustomerEncoderV1 (makeNameEncoder stringEncoder))
    (makeProductEncoder (makeProductIdEncoder stringEncoder) 
                        (makeDescriptionEncoder stringEncoder))

Even that part can be reduced to a minimum via a library like registry-aeson in Haskell:

-- you just declare the change between the 2 versions
-- all the wiring is done automatically for each version
decodersV1 = 
  <: makeCustomerEncoderV1
  <: decoders

Persistence

Persistence presents mostly the same challenges as serialization in terms of data management with the added complexity of being able to represent and navigate relations:

• As pointers in a domain model.

• As table relations in a relational model.

My general inclination here is to use simple SQL libraries, not ORMs, or fancy typed-SQL libraries. This means that I have to write tests just to make sure that I don't have a typo in my SQL query but this is not a bad thing! Those tests are also important to check the semantics of my persistence layer:

• What should be the unique keys?

• What are all the entities that must be deleted when one entity is deleted?

• Should there be a failure if I try to insert the same item with different values?

🧰 What do I want?

I mostly want a database library (in combination with a test library) that lets me easily:

• Create queries, bind parameters, create database transactions

• Manage schema migrations

• Deserialize rows (see the section on Serialization)

• Create an isolated database with the latest schema

• Pinpoint syntax errors

• Interact with actual test data

Data generation

Once we start having a large and somewhat complex data model it is important to be able to easily create data of any shape to test the application features. The problem is that:

• This is tedious if there are many fields.

• This leads to duplication of test code, when assembling large data structures from smaller ones.

The result is that we tend to write less tests than we should.

🧰 What do I want?

One excellent way to avoid these issues is to be able to create data generators for our data model:

personGenerator :: Gen Name -> Gen Age -> Gen Person
personGenerator name age = Person <$> name <*> age

In Haskell, if I have a generator for Name, a generator for Age I can easily have a generator of random data for Person using the wonderful applicative notation.

Then I can go:

ghci> sample personGenerator
Person { name: Name "eric", age: Age 100 }

That's it. I have an example of a Person that I can reuse in many, many tests. If I take the habit of creating generators as I evolve my data model, I allow my coworkers to easily create test cases outside of the feature I was working on.

There are two difficulties with that approach:

• Creating a generator for a Person seems like it could be automated.

• Wiring generators together is not fun

• Changing just one generator for a given test is tedious

Wait, that's the same problem as the serialization problem! And it has a similar solution 😊.

Components

Once we nail our data model we still have to structure the functionalities of our application.

Great news! There's an excellent tool for this task, and it has been well-known for quite some time:

Separate the interface from the implementation, Luke

There are notions of interfaces in many programming languages but with all sorts of twists (I should do a distinct post just on that subject):

• Does it use nominal typing or structural typing?

• Does it have associated types?

• Can you specify exception types separately?

Similarly, on the implementation side, there are many differences:

• Are modules generative or applicative?

• Is the interface declaration part of the implementation type (Java), or separated (Haskell, Rust, Scala)?

• Are modules first-class entities (Scala, not Haskell)?

• Can we have an unlimited amount of implementations for a given interface (not in Haskell when using type classes)?

🧰 What do I want?

The bare minimum is the possibility of having interfaces and a way to check or declare that an implementation conforms to an interface.

Above this, I want a way to do dependency injection. We can think about components in an application as a graph where each component, as an implementation, depends on other components, as interfaces:

For any reasonably complex and deep graph, I want to be able to easily switch implementations anywhere in the graph:

• To change how logging is done.

• To run entirely in memory.

• To wrap a given component and make it return random errors to test the reliability of my system.

• To run my system in different configurations: production, development, and demonstration.

• To test a given sub-system in isolation from the rest (integration testing).

The consequences of not being able to easily do this include:

• Time lost rewiring the system.

• Not running some experiments because it is too tedious to do so.

• Write fewer integration tests and only rely on top-level system tests.

• Have fewer possibilities to test complex scenarios.

• Spend more time adjusting the "wiring code" when refactoring.

Resources

Back-end systems always end up dealing with limited resources:

• Files, sockets, database connections, memory.

• Time, when waiting on IO operations.

• Time, when executing computation-intensive calculations.

There are good ways to deal with all these issues.

🧰 What do I want?

Safe resources closing

Closing files, database connections, etc... should be done as soon as possible and be robust in the face of exceptions or concurrency. This is not as easy as it seems.

I like the work that has been done in Scala for resource management and I am still on the fence on how the best way to deal with this in Rust. The pattern is called RAII ("Resource acquisition is initialization") but I still wonder if we are abusing lifetimes and memory management to support resource management when:

• The scopes can be different.

• The need for IO might require some async functionalities (an async Drop is still being debated).

Async/concurrency

There are different ways to support async programming:

• As a library: Scala

• As a library + a runtime: Haskell

• As a language construct + a runtime: Rust

All those approaches have complexities and pitfalls. It seems to me that one way to keep our sanity when using concurrency is to use structured concurrency. This article, "Go statement considered harmful", is widely recognized as a great resource to learn about it, so go read about it if you haven't!

Scala would also be my favorite choice at this stage, with functional libraries like the Typelevel libraries or the ZIO ones.

Streaming

Good streaming libraries allow us to iterate on infinite amounts of data without blowing up our memory:

• In Haskell, I liked streaming for its simplicity and elegance.

• In Scala, I would be tempted to use fs2 or zio-stream.

Traverse

traverse is such a useful function. If you start learning functional programming and then discover the traverse function, there is no turning back. It makes me a bit sad that traverse in Rust comes in different forms and with a less than perfect type-inference:

// for a vector
let results: Result<Vec<ValidValue>> = 
   values.iter().map(|v| check(v)).collect();

// for an option
let result: Result<Option<ValidValue>> = 
   optionalValue.map(|v| check(v)).transpose()

In Haskell:

results = traverse check values -- or: for values check
result = traverse check optionalValue -- or: for value check

In Haskell, this is the same concept, whatever the container, whatever the effect!

🧰 What do I want?

A good functional programming library gives us an incredible vocabulary to work with data and effects. map, traverse, foldMap, foldLeft, Monoid, Either, Option, etc... are invaluable to write concise and correct code. This goes a bit against the grain of languages encouraging (controlled) mutation like Rust or which don't have great support for functions and type inference (Java).

What about you?

I gave you my laundry list of language features and libraries that I like having at my fingertips to productively develop robust applications. You probably have your own list of features that I did not cover and I'm genuinely curious to know about them. Please share!

The manifesto still made me think. We are faced with inextricable issues, and being pessimistic is not helping. What kind of message am I conveying, especially to my children, "Well, good luck because we're all doomed"? That's not fair to them or to anyone else. Why not be optimistic instead? After all, technology has already brought so many improvements in our lives, from low infant mortality to food in large quantities. There are incredible technological breakthroughs still to be conquered. For example, could there be new sources of carbon-free energy that we can exploit at a minimal cost for the environment? There are so many things we still don't know in the very fabric of our Universe, like how to unify Quantum Mechanics and the Theory of General Relativity. Let's discover them and rock our world!

Delusion of grandeur

Optimism is a much better position to solve problems because you start to postulate that solutions exist. On the other hand, what I don't want is to be delusional. That doesn't help. I cannot bet my future on the idea that anti-gravity devices will, one day, exist. The Techno-optimist Manifesto not only has a "can-do" attitude but also a "want-to" attitude. As if there was no reason for the Universe to not eventually grant all our wishes.

For example, we are very, very lucky, that on this planet, gravity is just low enough that loading a rocket with the best fuels we know of will allow it to go into orbit. Were the gravity slightly more important and the weight of the fuel itself would be too much for the rocket get to escape velocity! Maybe we are not meant to get much farther than our solar system. The closest star after the Sun is already very far away. Maybe we won't ever be able to visit it. There is no reason why we couldn't but there is also no reason why we could.

If we look at the history of science we can see many things that we cannot do:

• There are limits to what we can prove with formal systems (Gödel's theorem)

• There's no engine with perpetual motion (Laws of thermodynamics)

• We cannot know the speed and position of a particle with equal precision (The Uncertainty Principle)

• Nothing can travel faster than the speed of light

Those are some limits for how far we can go. This could still be a long way! Yet we first need to apply a critical eye to where we are now. This is where the word delusion comes to mind.

The Techno-optimist Manifesto makes a huge mistake, it forgets the materiality of technology. It sees technology as a final product, as a pure gain, devoid of any costs.

Smartphone, really?

The object representing the biggest technological prowess of our times is probably the Smartphone. It is indeed a smart combination of materials research, hardware design, and manufacturing processes.

I remember sincerely dreaming about such a product as a kid. Something that I could use to call my friends, read, listen to music, watch videos, all in one object.

But let's come back to the physical object. What is it made of? What did it take to produce this marvel of technology? Short answer:

1. Making this object was incredibly destructive to our planet and some fellow humans

2. It is most likely destined to go to landfill and be wasted forever

3. Some resources it consumed can never be reclaimed

We need to enjoy those phones now because there's no guarantee that our successors will be able to do the same. Not very smart.

Minerals and metals

In this post, I want to highlight how much our technology relies on some very concrete reality. Reality is messy. Messy and worrying since we are planning on increasing technology in our lives.

Let's just focus on minerals and metals. Without metals, there is no technology. We cannot make our beloved smartphones or computers to run ChatGPT. We cannot even produce the energy to power those devices!

What about metals then? Where do they come from? Let's enter the wonderful world of mines.

Note: for what goes below I am relying on the various presentations and sources given by Aurore Stéphant, a French mining engineer and geologist.

What's in a mine?

The gold needle in the haystack

The first thing to understand is that there is nothing like a gold bar, or even nowadays a gold nugget, in the wild. If we want to collect gold, an amazing electrical conductor, we need to dig an enormous amount of land. There is only one gram of gold per 1 ton of ore. And when we go after that gram of gold we dig out many other metals:

• Iron (30 to 66%)

• Aluminium (25 to 30%)

• Zinc (4 to 20%)

• Uranium (1 to 3%)

• Indium (100 g / t)

• and many more

Some of those metals are harmful to our health. They end up disseminated in the environment when we mine for gold.

We don't have a gold bar yet, mining is just the first step.

Steps to purity

Three more steps are necessary, depicted here for copper:

• concentration, mostly a physical operation to make a thin powder

• extraction, a chemical or pyrometallurgy operation

• refinement, via fire and electrolysis

All these operations require large amounts of energy, chemical products, and water.

This explains why the footprint necessary for mining operations is very large. We need to move heaven and earth to get reasonable amounts of purity! Let's have a look at some consequences.

The dirty secrets of mining

Mining sites are human disasters

In many places in the World, mining sites have been created and have expanded, to the detriment of the local population. In Romania, a large copper has used a small nearby valley as its dumping site. See, that was a village there in the 80's:

(photo taken in 2015, we can't almost see anything nowadays with 14000 tons dumped every year)

300 families have been moved out of the zone, with no compensation. Sadly, the mining and oil industries are responsible for the most number of murders, human violations and social/environmental conflicts in the World.

A mining site is irreversibly damaged

Even when there are attempts to "rehabilitate" a mining site, soil and water sources stay polluted for years. Worse, in some cases like uranium mines in France, the site has been made "invisible", so that everyone forgets there was a mine but the source of pollution stays.

The UK Environment Agency writes (in 2023):

Mining played a major part in Britain’s rich industrial history, but this also left thousands of abandoned mines scattered across our landscape. Almost all these mines had closed by the early 1900s but they are still releasing harmful metals including lead, cadmium and copper. This is one of the top 10 issues for water quality in England as it harms fish and river insects. […]. The worst river pollution by metals is caused by water flowing out of tunnels dug by miners. Rainfall also washes metals out of the millions of tonnes of highly contaminated wastes the miners left at the surface.

Not only those mines do not provide any more value today, but they are actively, and for a long time, harmful.

A mining site is dangerous

When a mine is active, all the residue goes to a "tailing dam":

In the last 10 years, there were from 3 to 7 tailing dam failures per year. The two largest ones were:

• The Mariana Dam disaster, in 2015. It has been recognized as "the worst environmental disaster in Brazil's history". Entire fish populations were killed almost instantly, and the contamination went through the Rio Doce up to the Atlantic Ocean

• The Brumadihno Dam disaster, 3 years later. It killed 270 persons, with a mud wave going at 120 km/h. Twelve million metric cubes of tailings were released and cadmium was found up to 302 km downstream of the mine site

It is only getting worse

It is getting worse for 2 reasons:

1. There is less

2. We want more

There is less

The good old mining days are over. The concentrations of all minerals are noticeably going down:

This means that, if we want to dig up the same quantities we need to move out a lot more soil, with a lot more energy, and environmental damage. This graph shows the correlation between the emitted CO2 and gold concentration for various mining sites around the world:

We have similar graphs for energy, water and cubic meters of moved land.

We want more

In our quest to fight climate change, we aim to transition to electric cars, electric trucks, electric foundries, and so on.

More quantities

The copper demand is expected to grow from 25 tons/year to 36 tons/year by 2031. We need around 20 kgs of copper in a conventional, and 80 kgs in an electric car. Some of that copper comes from recycling (8.7 million tons/year) but there are limits to what we can recycle:

• Many products using copper are still in use

• The complexity of products using copper can make them difficult to recycle, and much more energy-consuming

The last point is interesting, we need lots of energy to produce and distribute energy, which itself is needed for mining and recycling. What makes us think that we can eventually get even?

More qualities

Let's take an example where technology is improving things: LED lights. A LED lightbulb consumes 75% less energy than an incandescent lightbulb and lasts up to 5 times longer. That looks like a great technological win. But the downside is in the recycling. LED lightbulbs are more complex than incandescent lightbulbs. They involve more materials:

They are bonded together, often with glues and foams that make separation of them using mechanical processes very difficult. You’ve got all types of materials in there from plastics, glass, ceramics, aluminum, copper. You have PCBs. It’s a complete mixture. We have a problem that’s going to come back and bite us

(Nigel Harvey, CEO of UK Lamp recycler, in ledmagazine.com. Yes, there is a magazine for everything 😄).

At least LED lamps are useful.

Still optimistic, but realism won't hurt

We can still be optimistic. But we have to seriously revise our goals. The direction we are taking is simply not sustainable. Technological problems are multi-dimensional and we have become quite good at improving in some dimensions at the expense of other dimensions: our environment, our resources and our human population.

In many ways, we are acting like a 20-year-old who has inherited a large fortune and is squandering it. In 200 years we have burned a treasury that took millions of years to accumulate, without thinking about tomorrow.

It's a difficult multi-criteria optimization problem

That's why I'm opposed to the Techno-optimist manifesto. It is very one-sided. It implicitly promotes going faster in the same direction without looking at all the problems that technology is creating at the same time.

This way of thinking is reflected in the Manifesto section about markets:

We believe free markets are the most effective way to organize a technological economy. Willing buyer meets willing seller, a price is struck, both sides benefit from the exchange or it doesn’t happen. Profits are the incentive for producing supply that fulfills demand. Prices encode information about supply and demand

As if prices, a one-dimensional quantity, could encode everything there is to know in an exchange. This is very naive and blatantly false. When you buy a TV, a car, or a phone, are you only looking at the price? No, you are generally agonizing over a zillion of other criteria.

As a society, we need to start considering our technology in all its dimensions. Maybe that means not having a flashlight on our phone, but hey water is drinkable!

I still want to play with my toys too

What I am writing is not necessarily very popular amongst my fellow software engineers. I understand that. I love programming. Each year, we are coming up with new programming languages, new models of computations, and new ways to dice and slice data. But maybe it is time to rethink my toys, to rethink our toys. As much as I appreciate my smartphone, I did not have one for the first 10 years of my adult life. I still had a good life.

ChatGPT can summarize a piece of text in seconds. Fantastic. How much is it worth in terms of irreversibly polluted land? We need to start thinking about our technological products from start to finish. How many times did you hear in a conversation between software engineers "Data is cheap"? Or "I can easily spin off 100 machines to do this if I want to"? Are they wondering what that means at the end of the line?

Actual recommendations

What can we do then? Here are some recommendations from experts in the field:

1. Massively limit the amounts of metals used in products (favor recycled metal) and overall quantity (which means making fewer products).

2. De-digitalize society. Remove unnecessary screens, stop making gizmos (Alexa etc...), and have an equivalent non-digital usage for every digital usage. Yes, that means that eventually fewer people like me are needed 😔.

3. Educate people about the resource consumption of our products.

4. Design for recycling.

5. Plan and collect the requirements in terms of resources based on human fundamental needs: water, food, heat, health, and education.

This is where we need to be optimistic and innovative as humans. We need to believe that we can create a good life for ourselves, and the future generations, without burning everything to the ground.

However, there is a dimension in which actor systems fall short in my experience. They don't scale in terms of complexity. Each time I've had to look at applications built with actors I found the overall behavior of the system pretty hard to reason about. Why?

The original sin

The reason is quite simple. As Paul Chiusano describes in "Actors are not a Good Concurrency Model" the fundamental signature of an Actor is A => Unit. You send it a message and ... something happens. This presents 2 major drawbacks:

• You need to look inside the implementation of an actor to have the faintest idea of what it is effectively doing

• Since its behavior is a side-effect, any refactoring can have unintended consequences

Despite these issues, proponents of the Actor model still claim that their approach is a great way to build concurrent and reliable systems. This is not an entirely baseless claim since a company like WhatsApp, using Erlang, was supporting 900 million users with 50 engineers in 2015! Surely I must be very wrong. Or,... is it a question of context?

In this blog post, I want to examine:

• What are the properties that make actor systems attractive?

• Are there ways to keep those desirable properties while still making the system as a whole a lot more amenable to navigating and reasoning?

• What kind of systems are well-suited to the Actor model?

What is so good then?

For this post, I am going to ignore the use of actors for distributed systems and focus on actors used in local, concurrent systems.

There are 4 main advantages to actors:

1. The sequential access to in-memory data to avoid data races

2. An inherently asynchronous programming model

3. The modeling of actors as state machines mapping 1-1 to some conceptual entity

4. The use of supervisors for error management

Taming concurrency with actors

One major difficulty with concurrent programming is the necessity to keep our data consistent. If I keep a list of bank accounts and want to model a transfer of money between 2 accounts, I'd better make sure that the transfer happens atomically. It should not be possible to observe that money has left Alice's account without being credited to Bob's account. This kind of problem is compounded when multi-threading is involved and when the compiler can freely re-arrange your code.

In that situation, an object like a Bank does not have a concurrency-safe interface

trait Bank {
  fn withdraw(amount: Amount, from: Account, to: Account) 
     -> Result<(), WithdrawError>;
  fn credit(amount: Amount, from: Account, to: Account);
  fn balance(account: Account) -> Result<Amount>;
}

Even if you combine withdraw and credit into one function, the implementation might not be thread-safe if we implement things naively:

trait Bank {
  fn transfer(amount: Amount, from: Account, to: Account)
     -> Result<(), WithdrawError>;
  fn balance(account: Account) -> Result<Amount>;
}

The solution that actors propose is to "lift" the methods into data, as messages:

enum Message {
  Transfer { 
    amount: Amount,
    from: Account,
    to: Account 
  },
  Balance(),
}

trait Bank: Actor {
  fn handle_message(message: Message);
}

Those messages can be sent to the message queue of an actor and become effectively serialized. The actor system of your choice then makes sure that the execution of each actor is single-threaded: problem solved!

Problem solved, at a massive cost

All the problems in computer science can be solved by another level of indirection

https://www2.dmst.aueb.gr/dds/pubs/inbook/beautiful_code/html/Spi07g.html

We solved this local, tactical, problem at the expense of a massive indirection. Now our program turns from:

if let Ok(_) = bank.transfer(Amount(100), alice, bob) {
  sms_system.send_message(bob, "transfer done!")
}

to:

bank.send_message(Transfer::new(Amount(100), alice, bob));

This has many implications in terms of practical concerns:

• We cannot anymore click on the transfer call and have a look at the implementation. Instead, we need to go through the entire pattern match inside handle_message to see where the case for Transfer is handled. If there are several message variants, the actual code dealing with transfers is probably tucked away in an internal function somewhere else

• How do we get back a result telling us that the transfer was successful? Now the Bank actor needs to get a reference to the sender and send a result back

In general, specifying what happens next is not obvious. In the first example, with functions, we notify the SMS system that Bob's account has been credited. With actors, we would probably start the Bank actor with a reference to the Sms actor and send a Credited message from inside the actor implementation.

With actors, we have to read the code to understand what is the flow of data in our system. When reading the code is not enough we have to instrument the actors at runtime to get some insight about what's going on.

It's not a magic wand

Each actor has its own internal state, free of race conditions, great. Yet this does not solve all state-related issues. What if we try to model each Account as an actor? How can we implement a transfer scenario so that the transfer between two accounts becomes atomic?

We have to come up with other patterns and pieces of infrastructure to solve these problems. For example:

• "Tanks, multiple readers, single writer actors"

• "Speculative Concurrent Processing with Transactional Memory in the Actor Model"

Don't (a)wait for me!

A system like Akka became quite popular at a time when async programming was becoming an absolute requirement. A web server dealing with thousands of requests could not allow its threads to be idly waiting for responses from other services or a database. On the contrary, an actor system can spin off millions of actors quietly waiting for an IO request to complete:

• The caller of the actor posts a message and doesn't have to block until that message is processed

• It can be notified, via a message, when some data has arrived

This is a great recipe for scalability: a few cores handling millions of requests!

But this is not the only solution to that problem, or, let's say, not the only way to package it. The heart of the solution is to have some sort of "continuation": what should I do when some data finally arrives?

Nowadays there are many other alternatives than actors for dealing with such continuations:

• Futures in Scala

• async/await in Rust

• async and monads in Haskell

• async runtimes in Scala: cats effect and ZIO

The major difference between these approaches and actors is the fact that they don't expose a programming model made of A => Unit functions. With a Future you make as if you already had the value you're waiting on and you map it to describe what to do next. Now the flow of data between computations is obvious and computing resources are used wisely. We will come back to that later.

Actors as top-models

According to Carl Hewitt, unlike previous models of computation, the actor model was inspired by physics, including general relativity and quantum mechanics.

https://en.wikipedia.org/wiki/Actor_model

Actors are a tool of choice to represent independent entities when they have their own internal state and interfaces. For example, it seems quite natural to model a game like Halo with an actor system (using Microsoft's Orleans platform).

Moreover, we can use state machines to represent:

• The internal state of an actor as some state variables

• The received messages as state events

• The processing of messages as transitions in the state machine

This is wonderful because there exist a large number of tools to:

• Represent state machines

• Reason about them: are there unreachable states? Will we always arrive at an end state? Are we missing some events?

• Test states machines: what is the minimal number of tests covering each state?

However, any time we have several independent systems collaborating, we also get a combinatorial explosion in complexity. Each local state might be well specified, but the overall combination of all states might exhibit some emergent behavior that we did not expect. Think about how the Game of Life generates amazing behaviors out of very simple cells.

Not every system is a physics simulation

The thing is, many of our systems do not need to be represented as small individual processes. And the fewer states we need to maintain, the better off we are.

The least amount of state is a pure function. Look ma', no state:

fn compute_taxes(income: Amount) -> Amount

Yet it is not always practical, or even possible, to compute only with non-stateful functions. It would be quite repetitive to pass around all the state required for computations:

fn compute_taxes(
   income: Amount, 
   tax_rules: TaxRules,
   previous_tax_paid: Vec<Amount>) -> Amount

Worse, it is not even desirable. There are implementation details that we wish to hide, like the fact that the tax algorithm is parameterized by rules or that it uses the amount of taxes paid in the previous year to calculate this year's taxes.

In any case, even if we end up with a function having some side effects, by enclosing some state, we are still in a better position than when using actors. Because functions give us a flow of data. "Something in, something out". And the "something out" is ready to become "something in" for another function.

It is not entirely by accident if an Actor system like Akka ended up proposing a Stream abstraction:

We have found it tedious and error-prone to implement all the proper measures in order to achieve stable streaming between actors, since in addition to sending and receiving we also need to take care to not overflow any buffers or mailboxes in the process. Another pitfall is that Actor messages can be lost and must be retransmitted in that case. Failure to do so would lead to holes at the receiving side

For me, this is thinking backward:

1. "Let's start with a general system where we can do everything"

2. "Let's constrain our system by adding another layer"

In some ways you can see a similar issue with dynamic vs. static typing in programming languages:

1. "Haha, no pesky compiler to prevent me from treating this variable as an int here and a bool there. It just works. Why would I care?"

2. "Oops my system is really hard to understand, give me types please":

   1. for Python: https://mypy-lang.org

   2. for Javascript: https://www.typescriptlang.org

   3. for Ruby: https://sorbet.org

In the words of Runàr Bjarnason

Constraints liberate, liberties constraint

very relevant talk excerpt: https://youtu.be/GqmsQeSzMdw?t=1452

I'm tolerant. To a fault.

One often-cited advantage of actor systems is the idea that those systems can be made fault-tolerant. How does that work?

No really, that's it. If some state ends up being corrupted in an actor, a sensible strategy is to start afresh. And if several actors are cooperating to accomplish any task it makes sense to restart all of them to ensure that their global state is correct.

This is the role of Supervisors in a system like Erlang/OTP or Akka. Since actors can spawn other actors, an actor system defines a tree of actors in a parent/child relationship. At each level, we can associate a supervisor. In case of a failure of an actor at that level it can decide to:

• Restart that actor

• Restart all the actors on that level

• Propagate the failure one level up

This way of dealing with faults is efficient for two reasons:

1. It addresses some common reasons for failures: incorrect state, maxed-out internal queue, or unreachable resources.

2. It allows the definition of independent processes or sub-processes that can be restarted individually thus containing errors to a limited part of the system

Magic wand again?

I think we must not conflate the problem with the solution. Ideally, we want to

1. Avoid inconsistent state

2. Isolate failures

The first point should foremost be addressed by having a minimal amount of state and being able to reason about it. We don't want to end up with a database like Oracle where the fix to some combinatorial state issue is to add even more states!

If an actor fails deterministically with some corrupted state, you might restart it 100 times, you will still get the same result. The "Let it crash!" motto seems to me to be a way of saying "Let us acknowledge that our system is so complex that we will enter some undefined states. Hopefully turning it off/on will work 🙏".

It is easy to understand that this cannot be the only strategy to tame the complexity related to state management. Yet, actors, as a network of interacting state machines, encourage a combinatorial explosion of state!

The second condition, "isolate failures", also does not come out magically from supervisors. Maybe a hundred actors represent individuals in a chat room but if one of them can make the whole chat room fail, the whole system fails. We need to carefully understand the functions of our system and their dependencies to be able to isolate them. Yet, actors, by being able to start other actors and communicate with them, hide the functional dependencies of our systems!

Eventually, it seems to me that the main benefit of supervisors is to force us to think about error modes and how to address them.

Can we do better?

I think so. We don't have to reinvent the wheel. We have ways to program differently for a vast category of systems. I would describe those systems as "linear".

The communication graph is not always complete

A "Linear" system is a system where data flows almost exclusively in one direction (think "activity diagram" in UML). Such a system:

• Accepts a request, possibly after a round of negotiation, authentication, and authorization. Alternatively, they pull out some event from a queue

• Process the request or event data in several steps, possibly incorporating some local persisted state

• Update their local state

• Publish events for other systems to consume

• Send back a response

In a linear system:

• There is a clear direction of data, which makes progress mostly in one direction

• Data comes front and center, the identity of its processor is less important

• There is some level of independence between each request and how they are processed

• Concurrency or asynchronism is desirable, especially if IO is involved

• Parallelism is desirable if some processes are CPU intensive (cryptographic operations, numerical computations)

Examples of linear systems include many forms of web services, APIs, or even point-to-point communications. Non-linear systems are typically multi-player games like Halo4 or group chat applications like WhatsApp and Discord.

The Future is already there

I hinted earlier that actors have been successful at a moment where asynchronous computing was sorely needed. Yet, actors are not the only solution to that problem. Case in point, the Actix web framework in Rust. It used to be built on an actor library, but:

its usefulness as a general tool is diminishing as the futures and async/await ecosystem matures

https://actix.rs/docs/whatis

Indeed futures and async support in our programming languages and libraries give us all the support we need. We actually get a lot more:

• We get types. A computation Future<T> produces a value of type T

• We get combinators to process the value future.map(f). We know what is the type of the resulting value!

• We get combinators to run processes concurrently and, for example, take the first value that succeeds in being computed give_me_first_available_quote

• We get a lot closer to structured concurrency which allows us to reason about errors and resources in a concurrent setting. You can read more about this in the fabulous blog post "go statement considered harmful".

There's blocking and blocking

Great, it seems that we solve the question of blocking while still being able to read our code as a series of typed transformations of data. What solving the issues with inconsistent state that actors solve with their message queue?

One obvious solution is to introduce locks to protect resources and guarantee their atomic update:

struct Bank {
  accounts: RwLock<Vec<Account>>
}

impl Bank {
  pub async fn transfer(
    amount: Amount,
    from: Account,
    to: Account) -> Result<(), TransferError> {
    let accounts = accounts.unlock();
    ...   
  }
}

Compared to the actor example:

• Calls to transfer are serialized so the data will be consistent

• We don't have to reify the transfer function into a full data type

• A caller waiting for its transfer action to be processed will not consume any major resource system, like a thread. The async runtime will park that computation until it is ready to proceed and continue

• We lose the full asynchronicity. Maybe the caller was truly not interested in the result of the transfer.

The last point seems to be a problem. Previously the caller of an actor was able to just leave a message and then could go away and process its own messages. Now, the caller of the transfer function has to block until the underlying resource is free to be updated. This might not block a thread but this will still prevent the function caller from doing anything else useful. I'll come back to that soon.

Note: I am aware that locks come with their own set of pitfalls!

Stateful components

A set of async functions operating on some shared data can be regrouped in a component:

trait ReviewComittee {
   async fn propose_talk(name: Name, talk: Talk) -> Result<Acceptance>;
   async fn withdraw_talk(name: Name, talk: Talk) -> Result<()>;
   async fn get_final_talks() -> Result<Vec<Talk>>;
}

That component might be the source of data for another component:

if let Accepted(talk) = committee.propose_talk(
    eric, 
    turning_actors_inside_out).await?) {
    scheduler.schedule(talk).await?   
}

If we lock the internal state of the ReviewCommitee and use async functions we don't need actors. Actually, this is not different from what GenServer is doing, on top of actors, in Elixir!

defmodule ReviewCommittee do
  use GenServer

  def handle_call({:propose_talk, name, talk}, _from, talks) do
    {:reply, :accepted, talk | talks}
  end

  def handle_call(:get_final_talks}, _from, talks) do
    {:reply, talks, talks}
  end

  def handle_cast({:withdraw_talk, name, talk}, state) do
    {:noreply, ...}
  end
end

The documentation says:

We can primarily interact with the server by sending two types of messages. call messages expect a reply from the server (and are therefore synchronous) while cast messages do not.

With GenServer we get the same benefits as a stateful component in async languages and the same constraints. But we lose types and have to consider the fact that the implementation can spawn other independent processes that we won't know about.

Turning actors inside-out

One other interesting viewpoint for linear systems is to see them as stream-processing systems. I wrote earlier that actors have this non-blocking mode of interaction where an actor can just leave a message for another actor and go on with his day. This is a way of saying: "Here is a bit of information you might be interested in, do whatever you want to do with it, I don't care".

We can invert that pattern and have components that say: "I am producing a piece of information, take it if you want". Essentially have a producer-consumer pattern.

This pattern introduces a level of indirection, like actors do. We now need to create data types to encapsulate the kind of information we want to communicate between computations. But the intent is very different! Instead of creating a message that says "schedule this talk" we create a fact saying "this talk was approved".

We can now have streams of facts that we can transform, join, store, reuse etc... This idea is very well presented by the wonderful talk from Martin Kleppmann, "Turning the database inside-out".

By turning actors inside out as publishers and subscribers we get amazing powers:

• We get back types: A Subscriber<T> can only subscribe to a Producer<T>. Our software components now come with a manual on how to assemble them!

• We get combinators: I can map a Producer<T> with a function T -> S to get a Producer<S> (and contramap a Subscriber<T> with a function S -> T to get a Subscriber<S>)

• We decouple our software: a Producer truly doesn't have to know about its Subscribers. Whereas actors have to know about each other

• We get a full specification on how to deal with gnarly problems like cancellation and backpressure

Final scene

I don't want to dismiss all the great work that has been done by Erlang/Elixir, and Akka users around the world. People have built large and successful systems with these technologies. Besides, the Erlang VM has some impressive features for distribution and hot code replacement, which are worth considering.

I believe however that the actor model is way too dynamic and untyped for many of the data-oriented systems that we are building every day. The same can be said, in my opinion, about dynamic programming languages. We can do amazing things with a language like Racket, but the safety net and discoverability of Haskell (cf. Hoogle) is preferable in many cases. In the words of John Ky:

Static typing is Lego, dynamic typing is playdough

Which I would steal as

Reactive streams are Lego, actors are playdough

As far as I'm concerned, I prefer building with Legos 😊.

This sentence can be quite puzzling for someone coming from a language like Scala, or for a Rust programmer wondering what the hell variance annotations are.

The thing that immediately came to my mind was "interesting, variance annotations in Scala are there to protect you from performing incorrect assignments when mutating values. On the other hand, Rust has a lifetime system to prevent you from making mistakes with mutations. Certainly, the variance annotations in Scala manifest as lifetimes in Rust then".

The actual situation is that the two situations present some similarities but are, in fact, different.

Why do we need variance annotations in Scala?

Variance in Scala is introduced here. I will summarize the crux of it with the following code

trait Animal
class Cat extends Animal
class Dog extends Animal

val cat: Cat = Cat()
val animal: Animal = cat

class Box[T](t: T)

val boxedCat: Box[Cat] = Box(cat)
val boxedAnimal: Box[Animal] = boxedCat

In the code above we are very tempted to say that a Box[Cat] is a Box[Animal] because a Cat is an Animal. But Scala, by default, will not allow it. If we want to let a Box[Cat] be a Box[Animal] we have to declare Box[T] with a + annotation

class Box[+T](t: T)

+ means that Box is now "covariant" in T:

• if S <: T, "S is a subtype of T"

• then Box[S] < Box[T], "Box[S] is a subtype of Box[T]" or "everywhere a Box[T] is accepted, a Box[S] can be provided"

But now, there is something else that we cannot do. We cannot mutate the content of Box. We cannot declare the following

class Box[+T](var t: T)

This would break type soundness as shown in this example:

val boxedCat: Box[Cat] = Box(cat)
val boxedAnimal: Box[Animal] = boxedCat

// why not, since a Dog is an Animal?
boxedAnimal.t = Dog()

// Oh no the cat became a dog!
val cat: Cat = boxedCat.t

So the point of variance annotations is to be able to declare the developer's intention concerning subtyping and rule out some possibilities that would not be typesafe.

Maybe as a Rust developer, you might have noticed that :

• the "bad" example involves mutation

• it also involves maintaining a reference to a structure mutated "by someone else"

Isn't there a whole type system in Rust devoted to making mutations safe? Is it what this is about here? Yes and no :-).

What does variance mean in Rust?

It is not entirely obvious to talk about variance in Rust when trying to come up with a similar example. For a simple reason: Rust does not have "a subtyping relationship for types". There is no way to declare a type Animal, a type Cat and declare that Cat is a subtype of Animal, allowing a Cat to be used anywhere an Animal is expected.

You can declare an Animal trait, a Cat struct, and have Cat implements Animal. But this is not a subtyping relationship.

In that sense it is meaningless to think that there could be variance annotations for collections in Rust because there is simply no subtyping relationship for types!

Why do I insist on "for types"? Because there is a subtyping relationship for lifetimes in Rust. If you consider a lifetime as "the section of the code for which a given value exists" it is easy to picture that some sections can be included in others.

The subtyping relationship, 'a <: 'b means "everywhere you accept values with a lifetime 'b then you should accept values with lifetime 'a. For this to work it is not hard to see that the lifetime 'a must be a code section containing the code section for the lifetime 'b. If you think about types as being "sets of values" this is a similar but inverted situation:

• A type A is a subtype of a type B if its set of values is contained in the set of values for be => the subtype is the smaller set

• A lifetime 'a is a subtype of a lifetime 'b if the active code section of 'b is contained in the one for 'a => the subtype is the greater set

We can now use this notion of subtyping to reason about some of the possible substitutions in Rust. For example, if a parameter is of the form &'a T then you can always pass a &'static T. That's because:

• the Rust compiler knows that the declaration &'a T is covariant in the lifetime 'a. Any &'b T can be accepted as long as 'b <: 'a

• 'static <: 'a "the 'static lifetime is the largest one"

It is easy to see what would happen if the compiler did not check those rules:

• you could pass a value with a more restricted lifetime than 'a

• then free the value while it is still needed in the scope delimited by 'a

There is a table in the Rustonomicon describing all those rules

That table is quite confusing though. It shows situations where T can be considered "covariant" or "contravariant", or "invariant". Didn't we say that variance is related to subtyping and that there's no subtyping relationship for types in Rust?

If you are confused, and I am too, this is normal, you are not the first one :-). What is not particularly well explained is the fact that types can also be generic in terms of lifetimes!

struct MyBox<'a, T> { t: &'a T }
struct MyHyperBox<'b, T> { t: &'b MyBox<'b, T> }

let my_box = MyBox { t: &1 }; 

{
    let my_hyperbox: MyHyperBox<u32> = MyHyperBox { t: &my_box };
}

In this example, my_hyperbox has a short lifetime but can still contain a value with a type annotated by a larger lifetime and the substitution works.

In conclusion

What we are seeing in Scala and Rust is not the exact same situation just translated from one language to another. We are observing:

• the possibility of subtyping relationships which make substituting expressions easier in our programs

• the type-checking rules that have to be enforced by the compiler to make sure that types in our programs stay consistent

How I avoided nix for so long

I never had a strong desire to completely control the software running on my machine. I was more focused on setting up an environment quickly and then dedicating all my time to developing software. However, this approach came at a cost. Every time I switched companies, I had to set up a brand-new computer and reinstall all my software. Typically, this meant a few days of frustration, but it also allowed me to clear out all the accumulated clutter from my previous job.

I was envious though of those people who were re-installing their computer in a matter of minutes, dot files, system libraries, development environments, etc...

Some of them had a secret trick for this: Nix.

Nix should have been appealing to me as a functional programmer, given its features like immutable deployments, isolation, easy rollbacks, and more. However, Nix had a reputation for being difficult to understand, challenging to use, and constantly evolving.

Ian Henry's "How to Learn Nix" is an excellent rendition of some of those difficulties. I could feel in my bones the kind of rabbit hole that learning Nix would be. Is it worth the loss of a few days every few years?

If I'm being honest, it was more than that. In my previous job, we had a mixture of technologies: Haskell, Go, Python, Postgres, etc. Even using some cryptographic libraries in Python meant building Rust code! As a result, my development environment started breaking much more frequently. Every month or so, some system library would be missing, python wouldn't be the right version anymore, and my PATH would become a mess. Nix was becoming increasingly compelling...

It doesn't have to be hard

With flox I can create several environments:

• dotfiles for my zsh configuration

• default for my common day-to-day tools

• scala for my open-source Scala projects

• haskell for my open-source Haskell projects

• rust for my open-source Rust projects

• ockam for my project at work

My .zshrc configuration file now is simply:

eval "$(flox activate -e flox/default)"
eval "$(flox activate -e dotfiles)"

This starts the flox/default environment giving me access to the latest version of flox, then my dotfiles environment.

The activate command:

• grabs the packages defined in the environment from a nix packages repository, builds them, and caches them locally (so that it is only slow the first time)

• puts the binaries included in those packages on the PATH

Dot files

What is in my dotfiles environment? We can have a look at it with the edit command:

> flox edit -e dotfiles
{
  shell.hook = ''
    export ZDOTDIR=$HOME/.dotfiles
    exec zsh --no-globalrcs
  '';
  packages.nixpkgs-flox.zsh = {};
  packages.nixpkgs-flox.starship = {};
}

The dotfiles environment exports the ZDOTDIR variable and starts zsh.

The ZDOTDIR variable points to $HOME/.dotfiles directory, which is versioned with Github. That directory contains all the files used in my .zsh configuration.

I am also fetching the fabulous starship prompt, which, with a bit of configuration, allows me to display the currently activated flox environments

I now have:

• versioned dot files,

• which can be easily reinstalled if I use a new computer

The many tools of the trade

Wait! Where does the additional default environment come from? This environment is activated by the $HOME/.dotfiles/.zshrc configuration file. It contains all the tools I rely on to be effective at my job. For example the ultra-fast versions of grep and find (rg and fd, implemented in Rust).

flox list -e default provides the whole list:

Several things to mention about this list:

• this is the 101st generation! I have frequently modified this list. flox can actually list all the modifications since it was created. I can also revert to any previous version if I want to

• all the usual suspects can be found in that list: git, rg, tree, etc... There is a very high chance that if you need an executable, you will find it by searching the nix packages

• some packages come from my own repositories. I published what was missing, using, ... flox

Publishing the rest

For example, the excellent cmt tool allows you to use a template to format your commit messages (respecting the conventionalcommits standard if you want to)

This is a tool that I use every day but it does not exist as a nix package. So I published it myself!

I forked the original repository and ran flox init to make it a flox project:

There is no pre-packaged project template for Haskell (which is how cmt is implemented), so I used package-simple.

This is where I had to learn more about Nix, so I could understand how to build the project. cmt is a small Haskell project so building it is not particularly involved

❯ cat pkgs/commit-tool/default.nix                                                                                                                                                                                                                                    dotfiles flox/default default
{ self, pkgs, stdenv, lib, haskellPackages }:
with haskellPackages;
  mkDerivation rec {
    pname = "cmt";
    version = "0.7.1.1";
    src = ../../.;
    isExecutable = true;
    libraryHaskellDepends = [
      ansi-terminal attoparsec base classy-prelude containers directory
      file-embed filepath process terminal-size text
    ];
    executableHaskellDepends = [ base classy-prelude ];

    doHaddock = false;
    doCheck = false;

    homepage = "https://github.com/smallhadroncollider/cmt#readme";
    description = "Write consistent git commit messages";
    license = lib.licenses.bsd3.spdxId;
    mainProgram = "cmt";
  }

The definition above declares that:

• we want to make an executable named cmt

• sources can be found at ../../.

• the package depends on other Haskell libraries

The next step is to use flox publish to make the package available to everyone. My teammates can subscribe to the repository containing the package and install it in their environment.

But they don't even have to do that!

Sharing is caring

One great benefit of creating a flox environment is the ability to save it to a Github repository with the flox push command.

This is useful for yourself because, the day you switch to another laptop, you can simply download the environment again with flox pull and be ready in minutes.

This is also particularly useful for teams working on the same project because you can make sure that everyone is always working with the same version of the same tools: postgres, python, jq, etc... thus reducing the risk of "But it works on my machine!".

Another significant benefit of using environments is their complete isolation. Activating an environment only adds the executables for that specific environment to the PATH. When you exit the environment, everything is removed. You have complete control over what is in scope.

Note: I have been using flox mostly as a package manager to handle "managed environments". There is also a concept of "project environments" where the flox configuration contains everything: how to build, test, release. The command used to enter a project environment is just flox develop in the project directory.

Less typing

One last tip. Having to type flox activate -e scala every time you want to work on a Scala project can become pretty tiresome. The solution to this problem is to use direnv. With direnv you add a .envrc file to your project directory:

eval "$(flox activate -e scala)"

Every time you cd into the project directory, direnv runs the .envrc file and that activates the right environment. Neat!

Getting some help

I encourage you to explore Flox and see how it can assist you in managing all your environments effortlessly. However, when you venture into building and publishing packages you might have to better understand flox's notion of catalog/channels and know your way around nix. Don't hesitate to leave a message on the flox Discourse site, the team is very responsive and friendly!

The pros

• The summaries are only 15 minutes long so you know that you can fit one or two book summaries in a short morning walk (which is also something I decided to do, to limit the risks of working remotely)

• You get to know quite quickly if a book is worth it or not. Some books, when summarized to their main points, feel absolutely trivial. For example "A Spy's Guide to Thinking" gives you a "brilliant" method: collect data, analyze it, decide, and act. This is not the revelation I was hoping for

• You can "read" numerous books on the same topic, which often serves to reinforce a particular point for you. For instance, there are several books centred around the idea that focusing intensely on one thing at a time can be advantageous: Focus, The One Thing, Essentialism, etc. Similarly, there are many books about habits: Atomic Habits, Eat That Frog, The Power of Habit, and so on.

• You can finally get an idea about that "famous book that everyone is talking about": The 4-hour Week, 7 Habits of Highly Effective People, Measure What Matters

The cons

• The voice reading the books can be a bit monochord

• The worth of certain books lies in the anecdotes they share. Skipping these to reach the main points robs you of the potent emotions that an anecdote can evoke.

• Some books are just so dense that trying to summarize them is ridiculous. For example the summary of Behave, by Robert Sapolsky, which I have otherwise read entirely, is laughable. Not only Robert Sapolsky includes tons of insightful study results in his book but the way he confronts them is possibly the most important message of the book. This is what it means to use science to understand the world (If you want to get a glimpse of the process, go and watch his lectures on "Introduction to human behaviour")

• The quality of the summaries can vary. I wish I could recall the precise example, but one summary stated, "Did you know that only 10,000 hydrogen cars are produced each year?" I'm fabricating this, as it was some not-so-interesting fact. However, what was truly intriguing was the reason behind it: "There isn't enough palladium, and there never will be" (again, making this up).

• I tried to "read" a book like 1984. I know, I should have read it entirely before and I'm not proud. Reading the summary is not worth it. It's a bit like reading the plot of a movie on Wikipedia

• Even summaries feel like they could be sometimes summarized. Ultralearning spends 90% of the time telling how great it is to be an ultra-learner, how some people are ultra-learners, oh and wait, did you know that there are benefits to ultra-learning? And then there is one chapter with some real tips on how to do it

In summary (ha! 😀), I believe that book summaries can serve as a helpful method for navigating the landscape of essays. However, they will never replace the time spent reading entire books, nor will they substitute the time dedicated to studying them thoroughly (taking notes, formulating your own questions or summaries, delving deeper into certain sections, etc.).