Live data from Hacker News

Use boring languages with LLMs

jry.io

31–40 of 180 posts

Re: Use boring languages with LLMs

#31
post #28

> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…

> Goroutines are a far more tractable primitive for coding agents than threads Goroutines are literally threads. Yeah, this really is a "go is my fav" article.

I use both go and python in my day job. The code that Sonnet produces for Go is much better than the Python it creates.

This could be because our go code is typically smaller more defined services but I don't really believe that since even the isolated python services are pretty spaghetti looking.

Re: Use boring languages with LLMs

#33

> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…

> Function colouring a red herring

Any time you see anyone overly fixating on "function coloring" for any context other than ancient versions of Javascript it's a clue that the speaker has no idea what they're talking about.

Re: Use boring languages with LLMs

#34
post #29
post #28

Earlier quoted context omitted.

> Goroutines are a far more tractable primitive for coding agents than threads Goroutines are literally threads. Yeah, this really is a "go is my fav" article.

Goroutines are not directly equivalent to threads.

They used to not be, because they were cooperatively scheduled and threads can be preempted. But they added goroutine preemption in Go 1.14 so in practice there aren't really any significant differences to threads, at least in semantics. (At least as far as I remember; been a while since I wrote any Go.)

You can be pedantic and say they aren't technically threads but that doesn't really matter from a programming perspective.

Re: Use boring languages with LLMs

#36
What??

Python __is__ a boring language (it is mature and well supported) with a somewhat convoluted package manager that has gotten a lot better since that xkcd came out.

Yeah, I get it, Go is better for distributing your code-- just one binary you can copy. But what does that have to do with "boring"?

Re: Use boring languages with LLMs

#37

> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…

RE the article you've linked:

> everyone knows goto was bad.

Absolutely hard disagree. You can write extremely clean and resilient C with C89, goto, and a handful of rules. Telling people `goto` is bad is how we get shitty C programs and paradigms where goto would have been better.

Goto isn't bad, its misuse is bad. Beginners will write shit code regardless of whether you tell them they can or can't use goto. That's also exactly what Dijkstra was arguing, if you read past the much misquoted "goto considered harmful", which he never said (it was an editorialized title, and not even the full version).

Re: Use boring languages with LLMs

#39
This is an interesting idea, but I'd want to see something solid before acting on it.

From what I can tell, LLMs know/use patterns above the syntax and idioms of specific languages and the syntax and idioms of specific languages and how to apply the former to the latter.

The bottleneck isn't what languages the LLM can handle, but what I can handle coming out of the LLM. The general advice, then, is to use the language (and related setup/environment) you're familiar with.

Re: Use boring languages with LLMs

#40
post #38

Rust, Elixir, and Go are the way to go for LLMs in my testing and experience, for this and other reasons

I have no professional experience in Rust and over 10 years in c++ but to me the decision to use rust in a greenfield project written by agents was obvious.
Post reply on HN