5 ms·

In my experience, Go is one of the best LLM targets due to simplicity of the language (no complex reasoning in the type system or borrow checker), a high qualit

• weinzierl 1y ago
  AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
  • deleted 1y ago
    [deleted]
  • tgma 1y ago
    Not that much different than a type checker in any language (arguably it is the same thing). I have been using various LLMs extensively with Rust. It's not just borrow checker. The dependencies are ever-changing too. Go and Python seem to be the RISC of LLM targets. Comparatively, the most problematic thing about generated Go code is the requirement of using every imported package and declared symbol.
  • steveklabnik 1y ago
    The borrow checker does not change behavior, so any correct program will be fine without borrow checking. The job of borrow checking is to reject programs only. mrustc also does not implement a borrow checker.
• KRAKRISMOTT 1y ago
  Well it certainly makes error handling easy. No need to reason about complex global exception handlers and non-linear control structures. If you see an error, return it as a value and eventually it will bubble up. If err != nil is verbose but it makes LLMs and type checkers happy.
• stouset 1y ago
  I have never understood why people want to use LLMs for programming outside of learning. I have written Perl, C, C#, Rust, and Ruby professionally and to this day I feel like they would slow me down. I have used golang in the past and I was not am still not a fan. But I recently had to break it out for a new project. LLMs actually make golang not a totally miserable experience to write, to the point I’m honestly astonished that people have found it pleasant to work with before they were available. There is so much boilerplate and unnecessary toil. And the LLMs thankfully can do most of that work for you, because most of the time you’re hand-crafting artisanal reimplementations of things that would be a single function call in every other language. An LLM can recognize that pattern before you’ve even finished the first line of it. I’m not sure that speaks well of the language.
  • tgma 1y ago
    > I have never understood why people want to use LLMs for programming outside of learning "I have never understood why people want to use C for programming outside of learning m. I have written PDP11, Motorola 6800, 8086 assembly professionally and to this day I feel like they would slow me down. I have used C in the past and I was not am still not a fan. But I recently had to break it out for a new project. Turbo C actually make C not a totally miserable experience to write, to the point I’m honestly astonished that people have found it pleasant to work with before they were available. There is so much boilerplate and unnecessary toil. And Turbo C with a macro library thankfully can do most of that work for you, because most of the time you’re hand-crafting artisanal reimplementations of things that would be a single function call in every other language. A macro can recognize that pattern before you’ve even finished the first line of it. I’m not sure that speaks well of the language." They are enormously powerful tools. I cannot imagine LLMs not being one of the primary tools in a programmer's toolbox, well... for as long as coding exists.
    • stouset 1y ago
      Right now they are fancy autocompletes. That is enormously useful for a language where 90% of the typing is boilerplate in desperate need of autocompletion. Most of the “interesting” logic I write is nowhere close to autocompleted successfully and most of it needs to be thrown out. If you’re spending most of your days writing glue that translates one set of JSON documents or HTTP requests into another I’m sure they’re wildly useful.
• tapirl 1y ago
  I have never seen any AI system could explain correctly on the following Golang code: package main func alwaysFalse() bool { return false } func main() { switch alwaysFalse() // don't format the code { case true: println("true") case false: println("false") } } > Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across time Not true for Go 1.22 toolchains. When you use Go 1.21-, 1.22 and 1.23+ toolchains to build the following Go code, the outputs are not consistent: //go:build go1.21 package main import "fmt" func main() { for counter, n := 0, 2; n >= 0; n-- { defer func(v int) { fmt.Print("#", counter, ": ", v, "\n") counter++ }(n) } }
  • tgma 1y ago
    You're bringing up exceptions rather than a rule. Sure you can find things they mess up. The whole premise of a lot of the "AI" stuff is approximately solving hard problems rather than precisely solving easy ones.
    • tapirl 1y ago
      I believe future AI systems can make correct answers. The rule is clearly specified in Go specification. BTW, I haven't found an AI system can get the correct output for the following Go code: package main import "fmt" func main() { for counter, n := 0, 2; n >= 0; n-- { defer func(v int) { fmt.Print("#", counter, ": ", v, "\n") counter++ }(n) } }
      • codr7 1y ago
        What do you base that prediction on? Without a fundamental shift in the underlying technology, they will still just be guessing.
        • tapirl 1y ago
          Because I am indeed experiencing the fact that AI systems do better and better.
• pkolaczk 1y ago
  Go is a great target for LLM because it needs so much boilerplate and LLMs are good at generating that.