I kinda feel the same way. I loved slowly going through the main story and probably put 50hr into the game, but the sandbox alone (amazing as it is) just doesn't do it for me.

The issue I have with stacked PRs isn't merging, but rather, when I change branch A, and I'm working on branch C, I then need to merge A into B and then B into C just to continue working. Collapsing/merging them at the end is the easy part.

There's a lot to love about Elm, and I've written quite a bit of production code with it starting around 0.18.0. But in 2026 I'm not sure why a company would newly choose a language that hasn't otherwise been updated in nearly 7 years.

Does it though? They are many longstanding bugs reported in their compiler repository, and this release doesn't seem to address any of them.

Longstanding issues that prevent usage? Not for me and the projects I’ve been apart of. No doubt there are plenty of reported issues, and no doubt they truly negatively impact some users, but I would still much rather choose the usability and stability of Elm 0.19.1-2 than anything in the typescript ecosystem today

When I worked on an Elm app in 2020, my users reported compatibility issues with various browser extensions (e.g. Grammarly, 1Password). I personally would prioritize making my apps usable for my users over making the DX usable for myself, so I stopped using Elm for future projects.

Oh yeah those are a bear: grammarly, 1password, and darkreader were the big ones, but translation was too. Elm assumes it's the only thing modifying the DOM underneath its root element; the extensions assume the DOM is free to be manipulated. NRI did a writeup on how they fixed it. https://blog.noredink.com/post/800011916366020608/adopting-e... The TLDR is to use https://github.com/lydell/elm-safe-virtual-dom/

You don't have to choose between Elm and TypeScript though, there are so many other options now - Haskell, F#, Rust, OCaml, just to name a few.

Weird not to mention Elm's massive breaking change that killed the project?

How does that bear on my comment?

Well, you're suggesting a reason to choose Elm is stability - a lack of breaking changes. But Elm is actually notorious for its wildly unpopular, dramatic, community-fracturing breaking changes. Backwards compatibility is not a concern for them.

It's a little tricky though, because the comment you were replying to was talking about the lack of updates. And in that sense, Elm is now very stable - no breaking changes (or any changes at all!) in seven years and counting.

(Although, for all the complaints about the React ecosystem: you can still write class-style React components, even though they were effectively deprecated when hooks were introduced just over seven years ago.)

OTOH, we have this blog post suggesting development on Elm is kicking up again. Which means more breaking changes might be incoming.

Dont worry, if breaking changes start happening, people will magically have always been saying it's good, actually.

I agree that the stability is quite nice. But there are plenty of areas where the language could use some improvement - for instance, the ergonomics around writing nested Single Page Apps is pretty cumbersome.

Bugs not being fixed is not a feature, it's a bug, and it's certainly not stability, it's just cope.

Honestly the feedback loop of "do math to roll more" would make this an excellent game for kids IMO

Yeah I agree. I grew up in a very blue-collar town, and anything I wanted to learn (outside of public schooling) either came from emaciated websites or whatever books I could find at the library. Having YouTube and Khan Academy and everything else would have made such a huge difference for me.

Now I’m wondering how a website is emaciated

One simply forgets to hydrate.

Not enough bytes?

Not even a nibble!

The nice thing with the Elixir example is that you can easily `tap()` to inspect how the data looks at any point in the pipeline. You can also easily insert steps into the pipeline, or reuse pipeline steps. And due to the way modules are usually organized, it would more realistically read like this, if we were in a BulkEmails module:

  Users.all()
  |> Enum.filter(&Users.is_expired?(&1, Date.utc_today()))
  |> Enum.map(&generate_expiry_email/1)
  |> tap(&IO.inspect(label: "Expiry Email"))
  |> Enum.reject(&is_nil/1)
  |> bulk_send()

The nice thing here is that we can easily log to the console, and also filter out nil expiry emails. In production code, `generate_expiry_email/1` would likely return a Result (a tuple of `{:ok, email}` or `{:error, reason}`), so we could complicate this a bit further and collect the errors to send to a logger, or to update some flag in the db.

It just becomes so easy to incrementally add functionality here.

---

Quick syntax reference for anyone reading:

- Pipelines apply the previous result as the first argument of the next function

- The `/1` after a function name indicates the arity, since Elixir supports multiple dispatch

- `&fun/1` expands to `fn arg -> fun(arg) end`

- `&fun(&1, "something")` expands to `fn arg -> fun(arg, "something") end`

I wonder if the thinner profile will make it more comfortable in smaller hands (both in terms of reach and center-of-gravity), but I'm skeptical.

It's actually not that thinner (1.9mm compared to 12 mini) so I doubt it will. And it definitely can't make for the huge size difference (134mm of extra width).

Oh, don't forget, if you click "Allow (current location)" it will also reload the page.

Elm works a lot like this and it's quite nice.

Totally agree; I started replaying 13 somewhat recently, and just felt worn down after playing for a few hours. The nonstop battles with no real break between them just isn't fun, despite the game having amazing aesthetics.