7 ms·

> 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

> 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-go-statement-considered-harmful/ 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.

dminik 5mo ago
> 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.
- Retr0id 5mo ago
  Goroutines are not directly equivalent to threads.
  - IshKebab 5mo ago
    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.
    - masklinn 5mo ago
      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.
  - quietbritishjim 5mo ago
    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.
    - Retr0id 5mo ago
      Correctness is nice but performance characteristics exist too.
- bfivyvysj 5mo ago
  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.
- p2detar 5mo ago
  As someone below said, they might be from programming perspective, but technically they are not. See GOMAXPROCS for more info. That being said the whole `tractable primitive` thing used in the article sounds somewhat sloppy to me. I don't quite get it. Yeah, they could be easier for an agent to write than async/await, but threads are also trivial in that matter, and you'd still need a mutex with go routines.
kibwen 5mo ago
> 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.
lionkor 5mo ago
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).
- jmiskovic 5mo ago
  Bad code is result of not following enough good practices rather than following one too many. Goto creates too much cognitive load. It had to be phased out to make room for better ideas on describing the intention with code more clearly.
- quietbritishjim 5mo ago
  > > 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.
pyrale 5mo ago
> 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.
- jshen 5mo ago
  Except for the part where he says that he found Go infuriating to use as a developer prior to LLMs.
cyanydeez 5mo ago
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.
- quietbritishjim 5mo ago
  I think you replied to the wrong comment. (Or, at least, I have no idea what you're saying.)
jshen 5mo ago
> 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.

dminik 5mo ago

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

Retr0id 5mo ago
Goroutines are not directly equivalent to threads.
- IshKebab 5mo ago
  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.
  - masklinn 5mo ago
    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.
- quietbritishjim 5mo ago
  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.
  - Retr0id 5mo ago
    Correctness is nice but performance characteristics exist too.
bfivyvysj 5mo ago
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.
p2detar 5mo ago
As someone below said, they might be from programming perspective, but technically they are not. See GOMAXPROCS for more info. That being said the whole `tractable primitive` thing used in the article sounds somewhat sloppy to me. I don't quite get it. Yeah, they could be easier for an agent to write than async/await, but threads are also trivial in that matter, and you'd still need a mutex with go routines.

kibwen 5mo ago

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

lionkor 5mo ago

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

jmiskovic 5mo ago
Bad code is result of not following enough good practices rather than following one too many. Goto creates too much cognitive load. It had to be phased out to make room for better ideas on describing the intention with code more clearly.
quietbritishjim 5mo ago
> > 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.

pyrale 5mo ago

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

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

cyanydeez 5mo ago

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.

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

jshen 5mo ago

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