zlacker

>>simonw+(OP)
I wonder if the era of dynamic programming languages is over. Python/JS/Ruby/etc. were good tradeoffs when developer time mattered. But now that most code is written by LLMs, it's as "hard" for the LLM to write Python as it is to write Rust/Go (assuming enough training data on the language ofc; LLMs still can't write Gleam/Janet/CommonLisp/etc.).

Esp. with Go's quick compile time, I can see myself using it more and more even in my one-off scripts that would have used Python/Bash otherwise. Plus, I get a binary that I can port to other systems w/o problem.

Compiled is back?

>>behnam+sj
100% of my LLM projects are written in Rust - and I have never personally written a single line of Rust. Compilation alone eliminates a number of 'category errors' with software - syntax, variable declaration, types, etc. It's why I've used Go for the majority of projects I've started the past ten years. But with Rust there is a second layer of guarantees that come from its design, around things like concurrency, nil pointers, data races, memory safety, and more.

The fewer category errors a language or framework introduces, the more successful LLMs will be at interacting with it. Developers enjoy freedom and many ways to solve problems, but LLMs thrive in the presence of constraints. Frontiers here will be extensions of Rust or C-compatible languages that solve whole categories of issue through tedious language features, and especially build/deploy software that yields verifiable output and eliminates choice from the LLMs.

>>condim+q01

  > ... and eliminates choice from the LLMs.

Perl is right out! Maybe the LLMs could help us decipher extent Perl "write once, maintain never" code.

>>dotanc+S01
it's very good at this BTW

>>nl+M91
I've found it's terrible at digesting a few codebases I've needed to deal with (to wit, 2007-era C# which used lots of libraries which were popular then, and 1993-era Visual Basic which also used from third party library that no LLM seems to understand the first thing about).

>>trollb+6h1
I had great results recently with ~22 year old PHP: https://simonwillison.net/2025/Jul/1/mid-2000s/

It even guessed the vintage correctly!

> This appears to be a custom template system from the mid-2000s era, designed to separate presentation logic from PHP code while maintaining database connectivity for dynamic content generation.

>>simonw+Ch1
That's great. Just yesterday I spoke with a developer who refutes Rector on old codebases, instead having an LLM simply refactor his PHP 5.6 to 8.(3 I think). He doesn't even check in Rector anymore. These are all bespoke business scripts that his team have been nursing for two decades. He even updated the Codeigniter framework it's all running on.