Live data from Hacker News

ChatGPT Containers can now run bash, pip/npm install packages and download files

simonwillison.net

101–110 of 336 posts

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#101
post #86
post #5

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

LLM should generate to terse and easy to read language for human to review. Beside Python, F# can be a perfect fit.

[dead]

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#102
post #5

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

My intuition from using the tools broadly is that pre-baked design decisions/“architectures” are going to be very competitive on the LLM coding front. If this is accurate, language matters less than abstraction.

Instructions files are just pre-made decisions that steer the agent. We try to reduce the surface area for nondeterminism using these specs, and while the models will get better at synthesizing instructions and code understanding, every decision we remove pays dividends in reduced token usage/time/incorrectness.

I think this is what orgs like Supabase see, and are trying to position themselves as solutions to data storage, auth, events etc within the LLM coding space, and are very successful albeit in the vibe coder area mostly. And look at AWS Bedrock, they’ve abstracted every dimension of the space into some acronym.

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#103
post #97
post #78

Earlier quoted context omitted.

> 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

I think that's not as beneficial as having proper type errors and feeding that into itself as it writes

Expressive linting seems more useful for that than lax typing without null safety.

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#104
post #5

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

> assuming enough training data

This is a big assumption. I write a lot of Ansible, and it can’t even format the code properly, which is a pretty big deal in yaml. It’s totally brain dead.

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#105
post #5

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

> But now that most code is written by LLMs

Got anything to back up this wild statement?

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#107
post #5

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

If you asked the LLM it's possible it would tell you Java is a better fit.

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#108
post #3

I wonder how long npm/pip etc even makes sense. Dependancies introduce unnecessary LOC and features which are, more and more, just written by LLMs themselves. It is easier to just write the necessary functionality directly. Whether that is more maintainable or not is a bit YMMV at this stage, but I would wager it is improving.

As long as "don't roll your own crypto" is considered good advice, you'll have at least a few packages/libraries that'll need managing.

For a decent number of relatively pedestrian tasks though, I can see it.

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#109

Earlier quoted context omitted.

You're describing a multi-agent long horizon workflow that can be accomplished with any programming language we have today.

I'm always open to learning, are there any example projects doing this ?

yes "now what?" | llm-of-choice

Re: ChatGPT Containers can now run bash, pip/npm install packages and download files

#110

Earlier quoted context omitted.

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

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.

It doesn't map anything 1 to 1, it uses our guidelines and architecture for porting it which works well. I did say YMMV anyway; it works well for us.
Post reply on HN