Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use boring languages with LLMs

jry.io

Post reply on HN
Print view View original

51–60 of 180 posts

Re: Use boring languages with LLMs

#51

Post by p2detar »

dist-epoch wrote: post #12
wewewedxfgdf wrote: post #5

Has Go become a "boring language"?

Become? Always has been. It was intentionally designed for programmers with limited skill. Go language creator Rob Pike: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build goo…

> It was intentionally designed for programmers with limited skill.

No. That is not true. It was designed as a language so programmers of all levels can be productive at the scale of what Google does and across possibly many different teams, no matter your prior background. Google does a lot at scale and a language that is easy to pick up and handles concurrency seamlessly is definitely a helpful tool.

Re: Use boring languages with LLMs

#52

Post by cyanydeez »

quietbritishjim wrote: post #23

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

no, i believe it needs to be solved in finetuning. collectively, the OSS community should be pooling local LLM resources and providing a route to models that inately choose best practices as a "full stack" engineer would see them.

in your mind, you think a harness and prompt is sufficient framing to keep the LLM output to design goals. but no matter your context size, as it grows, anomolous gradients appear that try to normalize competing patterns of development.

the only real way is directly training out unwanted crosswise options.

Re: Use boring languages with LLMs

#53

Post by quietbritishjim »

lionkor wrote: post #37
quietbritishjim wrote: post #23

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

> > everyone knows goto was bad.

> Absolutely hard disagree. You can write extremely clean and resilient C with C89, goto, and a handful of rules.

That's a different goto. The one in C89 can only jump around within functions, but the article is talking about goto that can jump between any two points in the whole codebase arbitrarily. It stresses that point a bit more later on in the article, but you can already see it from the FLOW-MATIC code quoted above (which doesn't even have functions).

Your point actually still stands: it's theoretically possible to write clean code using even the more general goto. (Probably by building abstractions with it like "function" and "for loop".) But would you be happy doing that with someone else - or especially with a coding agent? It's better that the "handful of rules" are enforced by the language, in my opinion.

---

Edit:

> That's also exactly what Dijkstra was arguing, if you read past the much misquoted "goto considered harmful", which he never said

I just re-read the original "GOTO considered harmful" article (it's short and clear) and, while the title might not have been his, Dijkstra was definitely making a very plain argument that goto is bad for everyone and should be scrapped. He says in the introduction:

> I [have] become convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code).

And in the conclusion:

> The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program.

Re: Use boring languages with LLMs

#54

Post by quietbritishjim »

cyanydeez wrote: post #52
quietbritishjim wrote: post #23

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

no, i believe it needs to be solved in finetuning. collectively, the OSS community should be pooling local LLM resources and providing a route to models that inately choose best practices as a "full stack" engineer would see them. in your mind, you think a harness and prompt is sufficient framing to keep the LLM output to design goals. but no matter your context size, as it grows, anomolous gradients appear that try…

I think you replied to the wrong comment. (Or, at least, I have no idea what you're saying.)

Re: Use boring languages with LLMs

#55

Post by quietbritishjim »

nathannaveen wrote: post #22
keepamovin wrote: post #15

I agree with the idea that boringly predictable should be what is preferred but anecdotally my experience in using Go with LLMs is that they trip up a lot on the races and locking from go’s thread model. I haven’t seen the same problem in rust which is now why I’m doing all my LLM work for tooling in rust. The parallelism issue in particular was also not something I noticed agent struggling with in JavaScript, althou…

Personally I generally try to avoid concurrency when writing code with AI since I feel AI makes concurrency unnecessary complex in Golang.

Probably reasonable, but that means you're disagreeing with the article's point about goroutines being good for LLMs (since goroutines are a form of concurrency). I've never seriously used Go so I don't know how easy it is to avoid using them.

Re: Use boring languages with LLMs

#56

Post by quietbritishjim »

Retr0id wrote: post #29
dminik wrote: 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.

If 100 goroutines are handled by 10 threads, the effect on correctness is identical: any two can be running in parallel with each other (not just concurrently). From the point of view of this discussion, that's all that matters.

Re: Use boring languages with LLMs

#57

Post by pjmlp »

p2detar wrote: post #51
dist-epoch wrote: post #12

Earlier quoted context omitted.

Become? Always has been. It was intentionally designed for programmers with limited skill. Go language creator Rob Pike: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build goo…

> It was intentionally designed for programmers with limited skill. No. That is not true. It was designed as a language so programmers of all levels can be productive at the scale of what Google does and across possibly many different teams, no matter your prior background. Google does a lot at scale and a language that is easy to pick up and handles concurrency seamlessly is definitely a helpful tool.

Nope, it was designed by one Oberon, and two UNIX heads, disgruntled to be faced with C++ at their work, they happened to be working at Google, and got support from their managers for developing it further.

Thanks to Docker pivoting from Python into Go, and Kubernetes from Java into Go, while it was still pre-1.0, it managed to take off, and has more users outside Google than at Google itself, where Java, Kotlin, C++, Python still dominate most projects outside Kubernetes ecosystem.

There is a certain irony that Google would need a language like Go, given their hiring process.

Re: Use boring languages with LLMs

#58

Post by anthk »

dist-epoch wrote: post #12
wewewedxfgdf wrote: post #5

Has Go become a "boring language"?

Become? Always has been. It was intentionally designed for programmers with limited skill. Go language creator Rob Pike: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build goo…

Not that true; it was dessigned as the C succesor for Unix. The Go counterpart for the Post-Unix OS would be Inferno and Limbo. 9front has a C and compiler suite (among CSP) which is like the link between their Unix/C and modern Go. Literally as the first Go releases used C plan9 compilers.

Re: Use boring languages with LLMs

#59

Post by anthk »

pjmlp wrote: post #57
p2detar wrote: post #51

Earlier quoted context omitted.

> It was intentionally designed for programmers with limited skill. No. That is not true. It was designed as a language so programmers of all levels can be productive at the scale of what Google does and across possibly many different teams, no matter your prior background. Google does a lot at scale and a language that is easy to pick up and handles concurrency seamlessly is definitely a helpful tool.

Nope, it was designed by one Oberon, and two UNIX heads, disgruntled to be faced with C++ at their work, they happened to be working at Google, and got support from their managers for developing it further. Thanks to Docker pivoting from Python into Go, and Kubernetes from Java into Go, while it was still pre-1.0, it managed to take off, and has more users outside Google than at Google itself, where Java, Kotlin, C++…

Go it's just condensed Plan9 C philosophy (and Limbo/Alef) for legacy Unix users. If we ditched Unix in the 90's being Inferno and Plan9 under a libre licenses GNU would be running Emacs under an Inferno kernel.

Also, proper namespaces from the start, Unicode, 9p even under Emacs and who knows what. Oh, and fore sure far less exploits, and with no Kubernetes or Docker nonsense. Half of VC's would be bankrupt today because damn namespaces would do the 90% of today's backends seamlessly.

And maybe we would be using some Inferno based smartphone with custom UI's and programming in Limbo for that. Oh, and batteries lasting a week for sure.

Re: Use boring languages with LLMs

#60

Post by Retr0id »

quietbritishjim wrote: post #56
Retr0id wrote: post #29

Earlier quoted context omitted.

Goroutines are not directly equivalent to threads.

If 100 goroutines are handled by 10 threads, the effect on correctness is identical: any two can be running in parallel with each other (not just concurrently). From the point of view of this discussion, that's all that matters.

Correctness is nice but performance characteristics exist too.
Post reply on HN