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

The LLM still benefits from the abstraction provided by Python (fewer tokens and less cognitive load). I could see a pipeline working where one model writes in Python or so, then another model is tasked to compile it into a more performant language

>>bogtog+uN
It's very good (in our experience, YMMV of course) when/llm write prototype with python and then port automatically 1-1 to Rust for perf. We write prototypes in JS and Python and then it gets auto ported to Rust and we have been doing this for about 1 year for all our projects where it makes sense; in the past months it has been incredibly good with claude code; it is absolutely automatic; we run it in a loop until all (many handwritten in the original language) tests succeed.

>>anonzz+YQ
IDK what's going on in your shop but that sounds like a terrible idea!

- Libraries don't necessarily map one-to-one from Python to Rust/etc.

- Paradigms don't map neatly; Python is OO, Rust leans more towards FP.

- Even if the code be re-written in Rust, it's probably not the most Rustic (?) approach or the most performant.