Rails, or even more so php have VERY little to bring to the table in 2026 going forward. Rails (ruby) is still a saner language than PHP, but as slow as php is. (granted ruby is not idiotic like PHP and runs rather than start/die).
If you go the LLM route something like Go is probably the goto default for MOST networking/web-first apps. You get static types, and a fast compile cycle (rust is still very slow here), and IF you want more from the language you can use something like Lisette (<a href="https://lisette.run/" rel="nofollow">https://lisette.run/).
Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.
Why would I bother with anything but Laravel for small CRUD apps? Not having to think about concurrency is neat, having tons of abstractions built by people with 50x my experience is neat, just being able to get going is neat.
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.
With LLMs the language DOES NOT MATTER. The framework DOES NOT MATTER. This is the thing we are talking about here. Laravel is 100% useless for a LLM first project. I can pretty much do anything in vanilla Go i can in Laravel and be 100x more performant, 100x more typesafe, and produce 100x more maintainable systems.
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.
LLMs would need way more tokens using langs/frameworks that dont have native features already built in? Even with LLMs I would take 10x the amount of time/tokens until I have something I could've just done with Laravel in the first place.
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...
I never had issues with token use at this scale. More so i would say a huge bloated framework uses more tokens as the LLM might read the source to understand why something works as it does. With stdlib only most LLM already knows it.
Also a laravel "rate limiter" sound suss. Its probably needs some extra dependency like redis + a supporting php library to work. On the contrary i can mock up a reasonably efficient in memory rate limiter in pure Go, and only go to redis when i need the scale.
shikck200 · · focus · HN ↗
If you go the LLM route something like Go is probably the goto default for MOST networking/web-first apps. You get static types, and a fast compile cycle (rust is still very slow here), and IF you want more from the language you can use something like Lisette (<a href="https://lisette.run/" rel="nofollow">https://lisette.run/).
Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.
sevenzero · · focus · HN ↗
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.
shikck200 · · focus · HN ↗
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.
sevenzero · · focus · HN ↗
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...
shikck200 · · focus · HN ↗
Also a laravel "rate limiter" sound suss. Its probably needs some extra dependency like redis + a supporting php library to work. On the contrary i can mock up a reasonably efficient in memory rate limiter in pure Go, and only go to redis when i need the scale.