25 ms·

This is entirely tangential to the article, but I’ve been coding in golang now going on 5 years. For four of those years, I was a reluctant user. In the last y

by jjcm 8mo ago

This is entirely tangential to the article, but I’ve been coding in golang now going on 5 years. For four of those years, I was a reluctant user. In the last year I’ve grown to love golang for backend web work. I find it to be one of the most bulletproof languages for agentic coding. I have a two main hypotheses as to why: - very solid corpus of well-written code for training data. Compare this to vanilla js or php - I find agents do a very poor job with both of these due to what I suspect is poorly written code that it’s been trained on. - extremely self documenting, due to structs giving agents really solid context on what the shape of the data is In any file an agent is making edits in, it has all the context it needs in the file, and it has training data that shows how to edit it with great best practices. My main gripe with go used to be that it was overly verbose, but now I actually find that to be a benefit as it greatly helps agents. Would recommend trying it out for your next project if you haven’t given it a spin.

IhateAI_2 8mo ago
[dead]
tejinderss 8mo ago
I wonder how is the experience writing Rust or Zig with LLMs. I suspect zig might not have enough training data and rust might struggle with compile times and extra context required for borrow checker.
- embedding-shape 8mo ago
  > I wonder how is the experience writing Rust or Zig with LLMs I've had no issues with Rust, mostly (99% of the time) using codex with gpt-5.2 xhigh and does as well as any other language. Not sure why you think compile times would be an issue, the LLM doesn't really care if it takes 1 minute or 1 hour to compile, it's more of a "your hardware + project" issue than about the LLMs. Also haven't found it to struggle with borrow checker, if it screw up it sees the compilation errors, fixes it, just like with any other languages I've tried to use with LLMs.
- jwxz 8mo ago
  I found Opus 4.6 to be good at Zig. I got it to write me an rsync like CLI for copying files to/from an Android device using MTP, all in a single ~45 min sitting. It works incredibly well. OpenMTP was the only other free option on macOS. After being frustrated by it, I decided to try out Opus 4.6 and was pleasantly surprised. I later discovered that I could plug in a USB-C hard drive directly into the phone, but the program was nonetheless very useful.
dizhn 8mo ago
I'm having similarly good results with go and agents. Another good language for it is flutter/dart in my experience.
oncallthrow 8mo ago
Yeah in my experience Claude is significantly better at writing go than other languages I’ve tried (Python, typescript)
- 9rx 8mo ago
  Same goes for humans. There are some wild exceptions, but most Go projects look like they were written by the same person.
JetSetIlly 8mo ago
Interesting. I've only dipped my toe in the AI waters but my initial experience with a Go project wasn't good. I tried out the latest Claude model last weekend. As a test I asked it to identify areas for performance improvement in one of my projects. One of the areas looked significant and truth be told, was an area I expected to see in the list. I asked it to implement the fix. It was a dozen or so lines and I could see straightaway that it had introduced a race condition. I tested it and sure enough, there was a race condition. I told it about the problem and it suggested a further fix that didn't solve the race condition at all. In fact, the second fix only tried to hide the problem. I don't doubt you can use these tools well, but it's far too easy to use them poorly. There are no guard rails. I also believe that they are marketed without any care that they can be used poorly. Whether Go is a better language for agentic programming or not, I don't know. But it may be to do with what the language is being used for. My example was a desktop GUI application and there'll be far fewer examples of those types of application written in Go.
- wild_egg 8mo ago
  You need to be telling it to create reproduction test cases first and iterate until it's truly solved. There's no need for you to manually be testing that sort of thing. The key to success with agents is tight, correct feedback loops so they can validate their own work. Go has great tooling for debugging race conditions. Tell it to leverage those properly and it shouldn't have any problems solving it unless you steer it off course.
  - treyd 8mo ago
    If only there was a way to prevent race conditions by design as part if the language's type system, and in a way that provides rich and detailed error messages that allow coding agents to troubleshoot issues directly (without having to be prompted to write/run tests that just check for race conditions).
  - deleted 8mo ago
    [deleted]
  - JetSetIlly 8mo ago
reactordev 8mo ago
Go’s design philosophy actually aligns with AI’s current limitations very well. AI has trouble with deep complexity, go is simple by design. With usually only one or two correct paths instruction wise. Architecturally you can design your src however but there’s a pretty well established standard.
jespino 8mo ago
One of the things that makes it work so well with agents is two facts. Go is a language that is focused on simplicity and also the gofmt and go coding style makes that almost all go code looks familiar, because everyone write the code with a very consistent style. That two things makes the experience pleasant and the work for the llm easier.
epolanski 8mo ago
I don't believe the "corpus" argument that much. I have been extending the Elm language with Effect semantics (ala ZIO/Rio/Effect-ts) for a new langauge called Eelm (extended-Elm or effectful-elm) and both Haskell (the language that the Elm compiler is written in) and Eelm (the target language, now we some new fancy capabilities) shouldn't have a particularly relevant corpus of code. Yet, my experiments show that Opus 4.6 is terrific at understanding and authoring both Haskell and Eelm. Why? I think it stems from the properties of these languages themselves: no mutability makes it reason to think about, fully statically typed, excellent compiler and diagnostics. On top of that the syntax is rather small.
hippo22 8mo ago
I have had good experience with Go, but I've also had good results with TypeScript. Compile-time checks are very important to getting good results. I don't think the simplicity of the language matters as much as the LLM being generally aware of the language via training data and being able to validate the output via compilation.

by jjcm 8mo ago

IhateAI_2 8mo ago

[dead]

tejinderss 8mo ago

I wonder how is the experience writing Rust or Zig with LLMs. I suspect zig might not have enough training data and rust might struggle with compile times and extra context required for borrow checker.

embedding-shape 8mo ago
> I wonder how is the experience writing Rust or Zig with LLMs I've had no issues with Rust, mostly (99% of the time) using codex with gpt-5.2 xhigh and does as well as any other language. Not sure why you think compile times would be an issue, the LLM doesn't really care if it takes 1 minute or 1 hour to compile, it's more of a "your hardware + project" issue than about the LLMs. Also haven't found it to struggle with borrow checker, if it screw up it sees the compilation errors, fixes it, just like with any other languages I've tried to use with LLMs.
jwxz 8mo ago
I found Opus 4.6 to be good at Zig. I got it to write me an rsync like CLI for copying files to/from an Android device using MTP, all in a single ~45 min sitting. It works incredibly well. OpenMTP was the only other free option on macOS. After being frustrated by it, I decided to try out Opus 4.6 and was pleasantly surprised. I later discovered that I could plug in a USB-C hard drive directly into the phone, but the program was nonetheless very useful.

dizhn 8mo ago

I'm having similarly good results with go and agents. Another good language for it is flutter/dart in my experience.

oncallthrow 8mo ago

Yeah in my experience Claude is significantly better at writing go than other languages I’ve tried (Python, typescript)

9rx 8mo ago
Same goes for humans. There are some wild exceptions, but most Go projects look like they were written by the same person.

JetSetIlly 8mo ago

Interesting. I've only dipped my toe in the AI waters but my initial experience with a Go project wasn't good. I tried out the latest Claude model last weekend. As a test I asked it to identify areas for performance improvement in one of my projects. One of the areas looked significant and truth be told, was an area I expected to see in the list. I asked it to implement the fix. It was a dozen or so lines and I could see straightaway that it had introduced a race condition. I tested it and sure enough, there was a race condition. I told it about the problem and it suggested a further fix that didn't solve the race condition at all. In fact, the second fix only tried to hide the problem. I don't doubt you can use these tools well, but it's far too easy to use them poorly. There are no guard rails. I also believe that they are marketed without any care that they can be used poorly. Whether Go is a better language for agentic programming or not, I don't know. But it may be to do with what the language is being used for. My example was a desktop GUI application and there'll be far fewer examples of those types of application written in Go.

wild_egg 8mo ago
You need to be telling it to create reproduction test cases first and iterate until it's truly solved. There's no need for you to manually be testing that sort of thing. The key to success with agents is tight, correct feedback loops so they can validate their own work. Go has great tooling for debugging race conditions. Tell it to leverage those properly and it shouldn't have any problems solving it unless you steer it off course.
- treyd 8mo ago
  If only there was a way to prevent race conditions by design as part if the language's type system, and in a way that provides rich and detailed error messages that allow coding agents to troubleshoot issues directly (without having to be prompted to write/run tests that just check for race conditions).
- deleted 8mo ago
  [deleted]
- JetSetIlly 8mo ago

reactordev 8mo ago

Go’s design philosophy actually aligns with AI’s current limitations very well. AI has trouble with deep complexity, go is simple by design. With usually only one or two correct paths instruction wise. Architecturally you can design your src however but there’s a pretty well established standard.

jespino 8mo ago

One of the things that makes it work so well with agents is two facts. Go is a language that is focused on simplicity and also the gofmt and go coding style makes that almost all go code looks familiar, because everyone write the code with a very consistent style. That two things makes the experience pleasant and the work for the llm easier.

epolanski 8mo ago

I don't believe the "corpus" argument that much. I have been extending the Elm language with Effect semantics (ala ZIO/Rio/Effect-ts) for a new langauge called Eelm (extended-Elm or effectful-elm) and both Haskell (the language that the Elm compiler is written in) and Eelm (the target language, now we some new fancy capabilities) shouldn't have a particularly relevant corpus of code. Yet, my experiments show that Opus 4.6 is terrific at understanding and authoring both Haskell and Eelm. Why? I think it stems from the properties of these languages themselves: no mutability makes it reason to think about, fully statically typed, excellent compiler and diagnostics. On top of that the syntax is rather small.

hippo22 8mo ago

I have had good experience with Go, but I've also had good results with TypeScript. Compile-time checks are very important to getting good results. I don't think the simplicity of the language matters as much as the LLM being generally aware of the language via training data and being able to validate the output via compilation.