It is a stylistic convention to always add this number to any reference to a function, even if there is only one definition.

> All this would be inexplicable enough if, indeed, AVCOAT was the only known material from which heat shields could be built. But while Lockheed continues to soak the US taxpayer and play chicken with the lives of NASA’s astronauts with this “flight proven” (but completely different) design, Lockheed happily built a PICA heat shield for JPL’s large Mars rovers Curiosity and Perseverance, and SpaceX’s Dragon capsule also uses PICA-3.

> If a crate doesn’t implement serde’s traits for its types then those types can’t be used with serde as downstream crates cannot implement serde’s traits for another crate’s types.

You are allowed to do this in Scala.

> Worse yet, if someone publishes an alternative to serde (say, nextserde) then all crates which have added support for serde also need to add support for nextserde. Adding support for every new serialization library in existence is unrealistic and a lot of work for crate authors.

You can easily autoderive a new typeclass instance. With Scala 3, that would be:

  trait Hash[A]:
    extension (a: A) def hash: Int

  trait PrettyPrint[A]:
    extension (a: A) def pretty: String

  // If you have Hash for A, you automatically get PrettyPrint for A
  given autoDerive[A](using h: Hash[A]): PrettyPrint[A] with
    extension (a: A) def pretty: String = s"<#${a.hash.toHexString}>"

  trait Trait[A]:
    type Assoc

  object A:
    given instance: Trait[Unit] with
      type Assoc = Long

    def makeAssoc: instance.Assoc = 0L

  object B:
    given instance: Trait[Unit] with
      type Assoc = String

    def dropAssoc(a: instance.Assoc): Unit =
      val s: String = a
      println(s.length)

  @main def entry(): Unit =
    B.dropAssoc(A.makeAssoc) // Found: Playground.A.instance.Assoc Required: Playground.B.instance².Assoc²

But fonts with good CJK support have wider Latin letter-forms, even when not in `font-variant-east-asian: 'full-width'` mode. I write about this here: https://maxbo.me/subordinate-latin.html (and cite "the peculiar case of Japanese web design")

I recently caught a glimpse of her Facebook and I was shocked to discover a version of the website that seemed to be the platonic ideal of exactly what all the Facebook PMs intended. Her feed was filled with the photos of her friends and coworkers international trips and holidays, posts in groups for planning activities in her most frequented cities. But I discovered that my mum was also a frequent "poster" of the photos of her various trips around the world, and the comments sections were filled with with some beautiful messages from her many many friends and family.

From this I learned that there is a subset of the population that Facebook works perfectly for and meaningfully improves their real-world social relationships. And perhaps Facebook has been hyper-optimized for that kind of use case through relentless A/B testing. But I fear my mum is quite privileged to have this kind of experience.

> A deploy pipeline that queries your orchestrator for running image tags, checks your migration history against the schema registry, diffs your GraphQL schema against collected client operations, and runs Buf’s compatibility checks: this is buildable today, with off-the-shelf parts.

that was largely successful at eliminating interservice compatibility errors, but it felt like we were scrambling around in a dark and dusty corner of software engineering that not many people really cared about. Good to see that there's a body of academic work that I was not entirely aware about that is looking into this.

The article successfully identifies that, yes, there are ways, with sufficient effort, to statically verify that a schema change is (mostly) safe or unsafe before deployment. But even with that determination, a lot of IDLs make it still very hard to evolve types! The compatibility checker will successfully identify that strengthening a type from `optional` to `required` isn't backwards compatible: _now what_. There isn't a safe pathway for schema evolution, and you need to reach for something like Cambria (https://www.inkandswitch.com/cambria/, cited in the article) to handle the evolution.

I've only seen one IDL try to do this properly by baking evolution semantics directly into its type model, typical (https://github.com/stepchowfun/typical) with it's `asymmetric` type label: it makes a field required in the constructor but not the deserialiser. I would like to see these "asymmetric" types find their ways into IDLs like Protocol Buffers such that their compatibility checkers, like Buf's `buf breaking` (https://buf.build/docs/reference/cli/buf/breaking/), can formally reason about them. I feel like there is a rich design space of asymmetric types that are poorly described (enum values that can only be compared against but never constructed, paired validations, fallback values sent over the wire, etc.)

Another one that I think makes a pretty good attempt is the config language CUE and its type system (https://cuelang.org/docs/concept/the-logic-of-cue/), which allows you to do first-class version compatibility modelling. But I have yet to investigate whether CUE is fit for purpose for modelling compatibility over the wire / between service deploys.