I've always thought of it as lightweight, but checking it now, wow.

I also disliked that and discovered you can toggle it with config now :).

I use the television task described here (https://zed.dev/blog/hidden-gems-part-2) for that experience :)

If you want an e-ink type screen, the Supernotes (or Remarkables, or Viwoods) are all very good at this. Personally I hate trying to read things on iPads.

> A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new.

This always made me feel uncomfy using `jj`. Something that I didn't realise for a while is that `jj` automatically cleans up/garbage collects empty commits. I don't write as much code as I used to, but I still have to interact with, debug and test our product a _lot_ in order to support other engineers, so my workflow was effectively:

    git checkout master
    git fetch
    git rebase # can be just git pull but I've always preferred doing this independently
    _work_/investigate
    git checkout HEAD ./the-project # cleanup the things I changed while investigating

```

Running `jj new master@origin` felt odd because I was creating a commit, but... when I realised that those commits don't last, things felt better. When I then realised that if I made a change or two while investigating, that these were basically stashed for free, it actually improved my workflow. I don't often have to go back to them, but knowing that they're there has been nice!

I think calling them "commits" is doing it a disservice because it's not the same as git commits, and the differences confuse people coming from git. I'd say "jj changes are like git commits, except they're mutable, so you can freely move edits between them. They only become immutable when you push/share them with people"..

It's a mouthful, but it's more accurate and may be less confusing.

> All of our expectations for control over our phones are completely out of whack compared to other computers.

I would, sadly, challenge this. If anything, our desktops and laptops are the exception now. Phones, TVs, game consoles, set top boxes, cars, Amazon echos, ebook readers, tablets, security cameras, autonomous devices like vacuum cleaners — when I think of the myriad devices we interact with that have a computer in them, they are all as stringently locked down as possible.

Nuclear fusion?

“PHP was so easy and fast that they’ve built such a successful startup they now have scaling problems” is, as far as I can tell, an endorsement of PHP and not a criticism of it.

I think the point here is that the scaling problem is hard because of PHP.

Scaling can be hard in PHP at the same time GGP comment's about PHP being in productive hands and thus being one of the reasons why PHP worked for them. Both of these can be true at the same time.

And for what its worth, Typescript scaling, although better than PHP is still somewhat of an issue and If you want to have massive scaling, Elixir/ (to-an-extent gleam) are developed for solving the scalability problem especially with Phoenix framework in Elixir-land.

So I guess, jack_pp comment's about PHP can also be applied to an degree towards Typescript as well so we should all use elixir, and also within the TS framework the question can be asked for (sveltekit/solid vs next-js/react)

I am more on the svelte side of things but I see people who love react and same for those who love PHP. So my opinion is sort of that everyone can run in their own languages.

Golang is another language to be taken into consideration especially with Htmx/datastar-go/alpine.

Scaling in PHP is easy. Has never actually been an issue in my entire career unless it was a badly designed database.

Yes, startup success has a direct correlation to the language chosen for your CRUD api…

I do wonder if LLMs will see tools like immudb (https://immudb.io/) or Datomic (https://www.datomic.com/) receive a bit more attention. The capacity to easily rollback the state to a previous immutably preserved state has always seemed like a fantastic addition to databases to me, but in the era of LLMs, even more important.

It would be pretty magical if this simplifies bundling static assets in Python applications, letting us avoid independently installing and running the Node toolchain.

It does.