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

61–70 of 180 posts

Re: Use boring languages with LLMs

#61

Post by pjmlp »

anthk wrote: post #59
pjmlp wrote: post #57

Earlier quoted context omitted.

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

Except that it throws away many nice things about Inferno and Limbo, and also proves the point that techonlogy needs good sponsors to make it out into the market..

Re: Use boring languages with LLMs

#62

Post by tracker1 »

For myself, I've generally setup a few boundaries... for JS projects, I tend to use Deno for tooling, even targeting npm lately. Similarly, I've favored modern TypeScript over JS. Often Hono + OpenAPI + Zod as a set for services.

I've also been doing quite a bit of Rust for web services and wasm targets, which has worked exceedingly well... similarly with Tokio + Axum, etc.

I have seen very few issues with either of the above... that said, C# has been a bit more painful by comparison... I often rely on FastEndpoints for services and Grate for database migrations, and LLMs often get a bit tangled with those libraries in practice.

Re: Use boring languages with LLMs

#63

Post by eithed »

I think that this not only applies to languages, but general patterns that you use. Don't mix functional with OO. Don't mix repositories with DAOs. Don't mix MVC and MVVM. Code should be predictable in what it does and what you expect from other developers how to code. If you don't have that then you shouldn't blame LLM when it goes haywire and starts doing whatever

Re: Use boring languages with LLMs

#64

Post by dnautics »

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.

I don't have this issue in elixir.

Re: Use boring languages with LLMs

#65

Post by dnautics »

I don't think the python package manager is the high level difficulty for LLMs doing python. I think the high level difficulty are nonlocal effects. At any given callsite, it might be difficult to know exactly what is going to happen to the data you pass into the call.

Re: Use boring languages with LLMs

#66

Post by masklinn »

IshKebab wrote: post #34
Retr0id wrote: post #29

Earlier quoted context omitted.

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

Even when goroutines were cooperatively scheduled, because the cooperation was mostly hidden and every function call was a yield point the average developer would treat them as being cooperative... until they spawned too many goroutines with a tight loop (and no function call) and the runtime locked up.

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

They are technically threads: they are independently scheduled, concurrent units of execution sharing an address space. They're just not OS (or kernel) threads. Hell, technically userspace threads (generally cooperatively scheduled) are the original, they predate kernel threads by a decade or two.

Re: Use boring languages with LLMs

#67

Post by jshen »

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…

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

This isn't true. I'm mostly using python and UV with claude and it periodically decides to try to run scripts directly instead of using UV.

Re: Use boring languages with LLMs

#68

Post by jshen »

pyrale wrote: post #49
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…

> This really does read as "Go is my favourite language". Because it always is that. People advocating for boring languages always advocate for their boring language. For instance, if you tell a gopher that you agree with the point, and therefore the project is going to use java, they won’t be happy about it.

Except for the part where he says that he found Go infuriating to use as a developer prior to LLMs.

Re: Use boring languages with LLMs

#69

Post by amarant »

wryoak wrote: post #2

Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially

I think you touch on a language feature I think is very important: compile time errors over runtime ones.

I'm biased, I preferred it this way before AI. But even so I think there is real merit. Firm guardrails and clear feedback seem to benefit AI.

Anecdotally, the worst AI performance I've seen was with gdscript, which is basically python minus the huge corpus of training data. Best results I'm getting with rust, which is in the opposite end of the strictness spectrum.

Post reply on HN