Hacker News Reader

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

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.

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

Here is a structured cross-codebase GOTO for C++, with optional declared & typed continuation values, sub-tasks/states/state-machines, and optional delegated typed termination values.

  // Syntax: { ...; y = go_to state1(x, ...); }
  // Meaning: Cross-codebase GOTO w/continuation values
  // Implementation: tail call
  #DEFINE go_to return

  // Syntax: { ... y = go_do state2(x, ...); ... }
  // Meaning: Cross-codebase sub-task/sub-state
  // Implementation: normal call
  #DEFINE go_do

  // Syntax: { ... go_terminate(y); }
  // Meaning: State machine termination
  // Implementation: normal return
  #DEFINE go_terminate return

  // Syntax: int state3 state(int x, ...) { ... }
  // Meaning: Structured state definition
  // Implementation: normal function
  #DEFINE state

  // SYNTAX: if (GOTO_NOT_HARMFUL) { ... };
  // Meaning: GOTO is now cleaned up
  // Derivation: Achieved
  #DEFINE GOTO_NOT_HARMFUL true

Example:

  int state1      state() { ...; go_to state2(m); }
  int state2 state(int m) { ...; y = go_do substate2a(); go_to state3(); }
  int substate2a  state() { ... ; go_to substate2b(q); }
  int substate2b  state() { ... ; go_terminate(q); }
  int state3      state() { ...; switch (...) { case 1: go_to state4(v); case 2: go_to state5(); ...} }
  int state4 state(int v) { ...; go_terminate(r); }
  int state5      state() { ...; go_to state3(); } // State cycle

So now you can have your #include <go_to>

EDIT: Compressed/cleaned up my mess

That's not the same: you have to cooperate in the game, so if you have a library that uses it internally and you call one of its functions in the normal way then it will still just return as usual. So it still provides the usual guarantees of function calling, even if you don't want it to.

(It also doesn't allow you to jump into the middle of a function, or to take more than a finite number of steps unless you're using a compiler with guaranteed tail call elimination.)

Just to add:

If you want to have proper jump-anywhere goto in C, you can do it a lot more simply than that: just put all your code in one function and use regular goto. If you want to use only structured programming constructions, use a while(true) loop with a switch statement inside.

The fact remains that code outside that function can still call it safely in the normal way.

I have written C code for several decades. I hate a priori, divorced from context, rules such as "never use goto". "Avoid premature optimization" as a rule is much worse. I used goto a few times in that timespan, surrounded it with rebellious comments, but largely the advice has more than weakly held for me. I don't think goto somehow liberates C developers and avails superior architectures.

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

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

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.

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.

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.

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.

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.

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

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