Remix.run Logo
▲ shikck200 5 hours ago

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 (https://lisette.run/).

Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.

▲pjmlp 3 hours ago | parent | next [-]

Dynamic languages without direct support for machine code generation are obsolete.

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.

▲Lio 4 hours ago | parent | prev | next [-]

I would have been more interested if he'd spoken about improvements actually in the Ruby world.

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.

▲vdfs 5 hours ago | parent | prev | next [-]

Well that's not something you say in a Rails conference, best language or framework for a project has been debated before I was born and will continue to be

▲poncho_romero 2 hours ago | parent | prev | next [-]

PHP is significantly faster than Ruby.

▲shikck200 2 hours ago | parent [-]

No... no its not. PHP is bound by IO in 99,9% of cases. This means im pretty much fucked the moment i need to do something even a little more complex. Say one request need 5-10 separate sql queries, and some http call and possibly some task like sending a mail. PHP need to run these all sync. I have to hack around and use a shit-tonne of deps like message queues and all sorts of plugins to get something like this working performantly.

Before you go on that apologist route, no, im not installing any random shit just to do simple stuff like this..

▲e12e 3 hours ago | parent | prev | next [-]

> as slow as PHP is.

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?

▲shikck200 2 hours ago | parent [-]

PHP is sync. This means every IO operation i do runs sync. This is why PHP will always be the slowest ones out there. Open a file, SQL queries, sending emails etc. Its all sync. Its all slow.

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.

▲sevenzero 4 hours ago | parent | prev [-]

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.

▲shikck200 2 hours ago | parent [-]

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.

▲voidUpdate 13 minutes ago | parent | next [-]

If the language doesn't matter, why aren't all LLMs outputting assembly code directly for maximum performance?

▲laszlokorte 22 minutes ago | parent | prev | next [-]

What I do not understand with the "languages do not matter"/"frameworks do not matter" is ultimately the following:

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?

▲sevenzero an hour ago | parent | prev [-]

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