1. 1

    I see people writing out their types quite often when they don’t need to. Is there any particular reason not to do this:

    let state = {
      dirty: false,
      status: "foo",
      // Need the cast only if you want to
      // restrict the type of an empty generic collection
      data: <Array<string>> [],
    type State = typeof state;

    rather than this:

    type State = {
      dirty: boolean;
      status: string;
      data: string[];
    let state: State = {
      dirty: false,
      status: "",
      data: []


    1. 1

      I quite like this pattern, definitely great for incremental adoption.

      But I just find the casts for anything that isn’t inferable clunky, and while this is a fairly simple example, if the type of the collection is a more complex type (as opposed to just a string), doing all that inline can be a bit much. It’s just preference, but having them separate can be simpler for me. So usually if I have to annotate anything, I annotate everything.

      1. 1

        The reason I’ve seen is so you can add doc strings to the type itself and reference the type elsewhere. For example, what do you write for a function that accepts your State object?

        1. 1

          You could add a docstring above the type State = type of state; line, right?

          And you can import or reference or use the type the same as in the second example, as far as I know.

      1. 3

        This stuff is fantastic. Does anybody know of any resources to learn more about this history, that is, the history of all the different flavors of operating systems before everything coalesced behind unix and ms-dos? Any books/articles/additional talks would be wonderful to dive into.

        1. 5

          I built a private website that hosts pictures of my ~2mo old son. It’s been really useful to disperse pictures to family and close friends. We add photos every week.

          It’s one of my favourite side projects I’m working on at the moment. I know that my parents visit it often. This weekend I’m going to add video support.

          Otherwise, I’m seven chapters into Crafting Interpreters (I recommend it as a resource). I also got my work to buy me Writing An Interpreter In Go.

          1. 2

            Private website as a read-only website? Or with comments, etc?

            I’ve naturally stopped sharing photos, etc on Facebook as I used to (laziness mostly), but I miss sharing them with friends & family. Keep kicking round the idea of how to best share them, I did try an iCloud Shared Album for an event last year but it’s even clunkier than Facebook on both sides. Not sure I want something else to maintain though.

            1. 3

              It’s just an unlisted (via robots.txt) Next.js app. The albums are folders in git and it deploys to Netlify on commit so uploading is dragging a file or two. It resizes photos, converts formats like HEIC to PNG, and builds a pretty album with React Photo Gallery.

              We found it easy to share with people as it’s a just link and we can say on the phone “oh check the baby website for the new photos”.

            2. 1

              I’m to the garbage collection chapter in Nystrom’s Crafting Interpreters. Really an excellent book, even if I’m mainly just following along past my skill level at this point. Writing An Interpreter In Go (and the Compiler variant) might be next for me!

              1. 1

                It’s very much on a backburner for me now, but I’ve been trying to construct an easy way to host photos on IPFS. Recently I’ve switched to working on a complementary app for managing my old photo (non-)backups. Eventually I’d love to try and merge those two apps and publish the result under AGPL.