BASIC and Lisp were invented with machine code generation as part of the REPL workflow, interpreters have always been the exception.
In BASIC's case for a brief moment interpreters were favoured only due to 8 bit home computer's hardware limitations.
If we are going the way of 5 GL (as LLMs being the 4GL revenge), natural language is quite dynamic to start with.
There fast JITS like YJIT, ZJIT, JRuby and TruffleRuby.
We also have static typing with RBS and an AOT compiler in Spinel and we have embeddable Crystal.
The speed of TruflleRuby or Spinal with RBS isn't that far behind Go.
And here's a Ruby advantage for you, Ruby even with static typing needs fewer tokens from your context window to represent the same solution as verbose Go.
DHH's own pitch for HotWire was that it allowed a native like experience without having to bow to Apple app store review process. Where's that gone?
There's lots of positive things that DHH could have spoken of but didn't.
Before you go on that apologist route, no, im not installing any random shit just to do simple stuff like this..
Citation needed? I love hating PHP, but of the reasons I would chose something other than PHP, speed and resource consumption is pretty far down the list?
PS. I fully aware of hacks around this like reactphp and the other related async things, but those are all just heavy dependencies and for most sane devs non starters.
I must admit I haven't run the numbers, but if this can be trusted, sync PHP isn't far off from golang - while async does rather well?
I probably would only reach for PHP if I needed to run on shared hosting (or rather, my customers did) - in which case few other technologies would compete, obviously.
https://phpbenchlab.com/php-vs-nodejs-vs-go-vs-python-io-ben...
> PHP 8.5 vs Node.js vs Go vs Python: I/O Performance Under Real Database Load (2026)
Thought it could warrant some discussion - maybe someone will spot obvious errors?
https://news.ycombinator.com/item?id=49845870
PS: golang is much faster at cpu - in this case one might argue a fairer comparison would use a compiled extension on the php side IMNHO - as that seems a likely path if a real project was cpu bound on a few small functions.
https://phpbenchlab.com/php-8-5-vs-nodejs-vs-go-vs-python-cp...
Building the things I've built using Laravel with Golang would probably take 10x the development time as I have to handcraft everything Laravel already natively provides. Or I have to trust 100 packages from 100 different random devs to simulate the Laravel experience in Golang.
This is why dynamic languages, and even more so BAD ones like PHP are just useless going into 2027 and the future. Its simple, the language gives you what it gives in perf, builtin RUNTIME features, and COMPILETIME features.
From that you pick the best for whatever you are building, be it Go, Rust, Ocaml etc. The language does not matter.
Go has 90% of stuff builtin, you rarely need any dependencies. Look at Laravel ITS A HUGE CODEBASE and a high risk for any real software project. I would stay FAR away from it.
What a good language or a good library (and to a lesser degree also a good framework) does is to pre-compress ideas into well understandable and composable chunks.
Examples:
`printf("foo %d, %3.2f %s", ...)` abstracts/compresses a general strategy of shuffling bytes into the correct ascii/utf-8... format. An LLM could also write the raw assembly or bytecode for doing the same thing, but for one it would take much more tokens and to apply this pre-invented concept, and second without the concept already invented there would be no "information pattern" in existence that the LLM could have learned or refer to.
`list.map(...).filter(...)...` are patterns that (when applied strictly in a functional sense) go hand in hand with laws like `map` not affecting the number of elements, and filter producing no new elements etc... These are also patterns that are already invented and depending on the language these restrictions are checked. Just reading `map` somewhere can tell you (and the LLM) a lot, and writing `map` instead of while, for or jmp will capture and express much more information. LLMs would not have been able to learn these concepts if they did not already exist. And even if such a general pattern would be discovered by an LLM somewhere inside its learnt parameters, it would not haven given this pattern a name that it could/would tell you. And if you do not know the name for such a concept how have a much harder time prompting the LLM.
Expressing computations in a well understood algebra allows for symbolic manipulation and simplification. like `5 + 3 == 3 * 5 == (1+1+1) * 5 == (5+5+5)...`. But algebraic manipulation requires a symbolic language with precise rules to describe what manipulation is allowed. In AI-speak you could say the language itself is a harness or a sandbox to guide and restrict whats possible. Doing advanced math proofs is only possible for LLMs because languages like LEAN provide a strict guideline to build upon.
In short, two extremes: If LEAN is so great at proofing correctness and LLMs are so good at LEAN, why is not from today on everything (windows, linux, basecamp, hey, gcc, rustc, blender...) translated into LEAN? Why bother with rust at all? On the other hand if languages do not matter anyway and LLMs are able to recognize all the pattern on their own, why not let the LLM output and iterate on the binary bytecode to generate a self contained binary directly?
A more concrete example: Laravel has a built in rate limiter, with Go I'd either have to tell Claude to install some rate limiter package from some random ass dev or implement its own which would consume tokens/time...
Also your argument about PHP/Laravel being risky is pretty funny as everything is risky and most of the internet runs on PHP...