One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much.

Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client.

And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but they are extremely solid choices to move fast, well, and get excellent performance and tooling out of the box.

▲

infamia 7 hours ago | parent | next [-]

Great point! I'd also add that Django's another solid choice for boring tech that LLM agents will know very well and will very likely continue to do so. A fair bit of SWE Bench and other Python benchmarks are Django related tests, which the LLM vendors care very deeply about keeping their scores up. Also, Django's docs are excellent, so strategically pointing an LLM to them in a prompt can often produce great results.

	▲	ipsod 6 hours ago \| parent [-]
		Django is the only thing I've used where I've vibe-coded an app, then looked at the code and not been appalled.

▲

michaelchisari 6 hours ago | parent | prev | next [-]

PHP has had a lot of conventions so the training data is all over the place. Ruby is a nightmare in that regard. Can't speak to Elixir but I'm surprised to hear someone say LLMs producing good code in either language.

On the other hand, Go code from 2012 and Go code from 2026 looks virtually the same. Conventions are respected, go fmt is the one single formatter, "use the stdlib" is a popular mantra and the code is readable by design.

If I were to codegen a project I wouldn't use anything but Go at this point.

▲

bluehatbrit 3 hours ago | parent [-]

I've been using elixir professionally and for hobby work for the past 7 years now. Language models are damn good at it, and have been for some time.

The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.

I can't speak for Ruby or PHP.

	▲	epolanski 3 hours ago \| parent [-]
		I also like Elixir, and I've used it for a handful of projects, the language may not be huge, but is conversely bloated by macros. I dislike macros and languages allowing developers to get creative with their own DSLs.

▲

10000truths 4 hours ago | parent | prev | next [-]

> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo

Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I've always disabled those and haven't yet run into issues. The JS-written bundlers can also be slow, but I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care. The main build bottleneck I can think of for a modern TypeScript project would be build plugins, since those are still written in JS/TS.

▲

stickfigure 3 hours ago | parent | prev | next [-]

Alternatively, if AI is doing most of the work, why not pick a platform that performs? If the cost of the code (and preferences of the developers) are factored out of the equation, pick based on operational cost.

Serving traffic with Ruby and Python is significantly more expensive than serving traffic with Java or Go.

▲

add-sub-mul-div 7 hours ago | parent | prev [-]

The willingness to reshape society for the benefit of AI rather than shaping AI around humanity paints a very dire picture of the coming decade.

▲

Gormo 6 hours ago | parent | next [-]

Is that what's happening in this example, though? Ditching TypeScript in favor of PHP seems to be a net positive in favor of having a reliable, performant tech stack. From certain perspectives, TypeScript is itself a form of technical debt: writing code in one language just to transpile it into another interpreted language just to add type safety to correct for human error seems like a heavy layer of complexity just to make development teams work faster.

If we get to the point where AI tools are able to consistently able to produce desired results within strict performance and security constraints, without having to make the same tradeoff between delivery velocity and final quality, why would we not have them target the lowest level feasible for implementation, and cut out all of the middleware cruft that makes everything slow and take up ten times the RAM it actually needs to?

▲

dwedge 7 hours ago | parent | prev | next [-]

I disagree. We've been doing this for two decades already. A lot of monoliths were rewritten in a way that best fit the AWS pricing model of the time with the software itself seemingly being an after afterthought. (I'm not here to discuss whether monoliths or micro services are better, I'm just saying the choice of how they were rewritten was too often mostly for AWS pricing)

▲

epolanski 7 hours ago | parent | prev [-]

I think you're completely misreading what I wrote.

PHP (lets use this as an example) brings already many benefits over a common solution like a TypeScript monorepo mostly operational simplicity. That was already true before AI.

It's boring, very fast and easy to deploy, offers straightforward horizontal scaling, no need to orchestrate containers and/or multiple runtime processes, has excellent html rendering (nothing in JS-land really does), and has very solid framework solutions like Laravel where everything works out of the box.

Those merits existed before AI already.

The issue was that you had to buy into PHP as a language, which was a horrible experience.

But if AI writes most of the code? Suddenly PHP becomes an excellent candidate to choose for many use cases.

If anything, AI makes the choice of programming and languages and software about finding the right tool for the job. Somehow the industry instead keeps vomiting React/Tailwind slop which are the right tool for 1% of the jobs.

I hope to have cleared the concept.

	▲	6 hours ago \| parent \| next [-]
		[deleted]
	▲	Gormo 6 hours ago \| parent \| prev [-]
		[dead]