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

21–30 of 180 posts

Re: Use boring languages with LLMs

#21

Post by dust-jacket »

ChrisMarshallNY wrote: post #19

I program in two languages: Swift (my main language), for client work, and PHP, for backend work. It’s overwhelmingly Swift. In the last year or so, I have been using LLMs, to assist my work, with generally, excellent results. I have noticed that the LLM delivers much better PHP, than Swift. I seldom need to rewrite or correct, the PHP code I get from it, and am constantly correcting the Swift. Part of the reason, ma…

> Part of the reason, may be that I am a much better Swift programmer, than PHP programmer

Hard not to think that's a major part of it. IME you make loads more corrections in languages you're more opinionated about (and opinionated usually follows more experience & confidence).

I correct AI Python all the time. When it cranks out TypeScript I just check it works.

Re: Use boring languages with LLMs

#22

Post by nathannaveen »

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.

Re: Use boring languages with LLMs

#23

Post by quietbritishjim »

> 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 coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere.

I disagree with this. Goroutines, along with threads, callbacks, and traditional async, are all in the same category: spaghetti of unbounded background tasks. Structured concurrency [1] on the other hand is dramatically easier to reason about. Python has support for this (in Trio and asyncio.TaskGroup) as do other languages like Kotlin and Swift. Function colouring a red herring; if anything, it's useful because it highlights the scheduling/cancellation points in your code.

[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

-----

This really does read as "Go is my favourite language". In fairness, that's a good reason to choose a language to use with an LLM (so long as it's powerful enough and not too obscure). But let's not pretend it's the best language for everyone.

Re: Use boring languages with LLMs

#24

Post by boxed »

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…

Such a weird take from him since Go has a bunch of pit falls that are not needed at all.

Re: Use boring languages with LLMs

#25

Post by iamcalledrob »

sleepy_keita wrote: post #20
ChrisMarshallNY wrote: post #19

I program in two languages: Swift (my main language), for client work, and PHP, for backend work. It’s overwhelmingly Swift. In the last year or so, I have been using LLMs, to assist my work, with generally, excellent results. I have noticed that the LLM delivers much better PHP, than Swift. I seldom need to rewrite or correct, the PHP code I get from it, and am constantly correcting the Swift. Part of the reason, ma…

I think it's pretty simple - there's just so much more open source PHP code out there in the LLM's training dataset. Swift has been around for much less, and most Swift is closed-source - not that many years have passed since Swift has been able to run on non-Apple platforms, too.

I would also bet that 90% of Swift training data is UI code.

And UI code quality tends to be technically pretty crummy/low-discipline. Your UI code doesn't need much consideration around data races, for example.

Re: Use boring languages with LLMs

#27

Post by keepamovin »

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.

Right. But for things like GUI or orchestration tooling it’s unavoidable

Re: Use boring languages with LLMs

#28

Post by dminik »

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…

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

Re: Use boring languages with LLMs

#29

Post by Retr0id »

dminik wrote: post #28
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…

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

Re: Use boring languages with LLMs

#30

Post by badgersnake »

citbl wrote: post #26

We are the point now where we let LLM dictate the language?

Yeah, but then generally you pick the language your dev team are most familiar with.

Or you hire a team of specialists for the language you want. Perhaps niche languages should have fine-tuned LLMs in the same way.

Post reply on HN