> 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.

No. They’re only installed if you git clone react and npm install inside your clone.

They are only installed for the topmost package (the one you are working on), npm does not recurse through all your dependencies and install their devDependencies.

The use case is making them work on distinct tasks in parallel — just like an organisations developers each have (traditionally) their own laptop with its own isolated environment. So that I can say to agent 1 “clean up the unit tests in the payments module” and I can say to agent 2 “implement a simple client for Mailchip so that we can migrate off Sendgrid” and the two can work independently.

Note that I don’t work like this personally — I quickly get overwhelmed by the volume of context switching — but I can absolutely see the appeal; particularly for smaller shops.

Yeah, this is something I'd like more of outside of Agentic environments; in particular for working in parallel on multiple topics when there are long-running tasks to deal with (eg. running slow tests or a bisect against a checked out branch -- leaving that in worktree 1 while writing new code in worktree 2).

I use devenv.sh to give me quick setup of individual environments, but I'm spending a bit of my break trying to extend that (and its processes) to easily run inside containers that I can attach Zed/VSCode remoting to.

It strikes me that (as the article points out) this would also be useful for using Agents a bit more safely, but as a regular old human it'd also be useful.

A TypeScript test suite that offers 100% coverage of "hundreds of thousands" of lines of code in under 1 second doesn't pass the sniff test.

We're at 100k LOC between the tests and code so far, running in about 500-600ms. We have a few CPU intensive tests (e.g. cryptography) which I recently moved over to the integration test suite.

With no contention for shared resources and no async/IO, it just function calls running on Bun (JavaScriptCore) which measures function calling latency in nanoseconds. I haven't measured this myself, but the internet seems to suggest JavaScriptCore function calls can run in 2 to 5 nanoseconds.

On a computer with 10 cores, fully concurrent, that would imply 10 billion nanoseconds of CPU time in one wall clock second. At 5 nanoseconds per function call, that would imply a theoretical maximum of 2 billion function calls per second.

Real world is not going to be anywhere close to that performance, but where is the time going otherwise?

Hey now he said 1,000ms, not 1 second

You don't need to get too far down the page to see "VPN", which is what it is. But on top of that primitive, it's also a bunch of software and networking niceties.