5 ms·
Just use Go. LLMs have seen a ton of it, they write it well, it compiles practically instantly, and it has all the advantages of a typed compiled language. I c
by bensyverson 5mo ago
Just use Go. LLMs have seen a ton of it, they write it well, it compiles practically instantly, and it has all the advantages of a typed compiled language.
I created a big Python codebase using AI, and the LLM constantly guesses arguments or dictionary formats wrong. Unit tests and stuff like pydantic help, but it's better to avoid that whole class of runtime errors altogether.
- hirvi74 5mo agoBut what is the selling point for Go? I get that it is allegedly hailed to be a simple language with basically no batteries included, but why is that a selling point? Does Go excel at anything no other language does?
- deleted 5mo ago[deleted]
- chickenman_98 5mo agoI think that’s sort of the selling point no? It’s really boring. It has like -10 keywords, compiles insanely fast, and has a concurrency model that’s easy to use and read. LLMs are great at using Go tooling to sanity check along the way. It’s easy to write shitty Go but it’s really pleasant to work with if you find those things compelling.
- khimaros 5mo agodon't you worry about garbage collection?
- camdenreslink 5mo agoIf you were using Python, then probably not.
- bensyverson 5mo agohaha exactly. I’m coming from Swift, and I don’t want to go back to manually releasing objects like I used to in ObjC, let alone reason about lifetimes.
- mellow_observer 5mo agoWhat's the big issue with GC nowadays? It has mattered to me exactly once in decades and it was still manageable anyway by using a more low level style in a hot loop. I see very few usecases where GC actually matters and for those rare few cases it was not like you were using python beforehand anyway
- coldtea 5mo agoWhy the hell would he "worry about garbage collection"? That kind of thing is a cargo cult fear. Garbage collection is not an issue for 99% of programs. And for those that it is, there are ways to mitigate the issue (e.g. there are extremely high performance trading system written in Java, where every last sub-millisecond counts). Blanket fear of GC reminds me when new programmers learned about how assembly is lower level and can be faster, and wondered why everything is not written in assembly.
- enneff 5mo agoFor one thing it’s statically typed and has many fewer foot guns than Python, so the llm-produced code is more likely to do what you expect.
- shepherdjerred 5mo agoGo is statically typed but the type system leaves much to be desired. Go’s benefit are primarily around simplicity, readability, and concurrency.
- coldtea 5mo ago>Go is statically typed but the type system leaves much to be desired. Not that much. Looking at Rust or Haskell complexity, I don't really desire it.
- wiseowise 5mo agoPython has much better type system than Go, I don’t know what you’re on. With Trio it has a better async capabilities too.
- pylotlight 5mo agoPerformance? Second only to rust and other lower level langs. Surely you don't need this spelled out for you...
- nvader 5mo agoNot just performance, but static typing and prevalent in the training data/easy for LLMs to reason about. Of course, your response admits, "second to Rust", which I am guessing is an unspoken question in the grandparent's mind.
- hirvi74 5mo agoIf performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint? Are we mainly talking about performant Web backends? Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?
- overfeed 5mo ago> why choose Go over say... Swift? Language religious wars are silly: you should choose a language based on your constraints and personal tastes. If there's no clear advantage of one language over another for a given task - then all the options are viable, pick one and get on with solving the problem.
- coldtea 5mo ago>If performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint? Or when performance is the main but not the only difference, and there are many other benefits. >Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift? Because unless you're building for macOS/iOS, Swift is really a no-go, with lackluster support for other platforms. Plus slow to build and convoluted.
- za3faran 5mo agoJava and C# are there and faster.
- sly010 5mo agoNo batteries!? Go has a huge stable standard library no other language even comes close to. Built in tooling for unit testing, performance testing, debugging, code formatting, package management, etc. And most go binaries can be compiled statically so libc is not even a dependency. Golang is the definition of batteries included.
- coldtea 5mo ago>Go has a huge stable standard library no other language even comes close to Well, Java and Python do.
- walthamstow 5mo agoYet the first thing most people do before making a HTTP request is pip install requests
- coldtea 5mo agoYet, a nicer request wrapper is not the be all end all of batteries, and Python covers a huge spread of libs
- IshKebab 5mo agoPython has a quite random collection of stuff, and it's often quite low quality and people don't use it anyway. I wouldn't say it is close to Go. I haven't used Java for a decade or so but as I recall its standard library was pretty bare bones (similar to Rust). Apparently C# has a pretty comprehensive standard library but I've never used it.
- coldtea 5mo ago>Python has a quite random collection of stuff, and it's often quite low quality and people don't use it anyway. I wouldn't say it is close to Go. People who came into Python for ML and Data Science, and just care for their array and ML libs maybe. But long time Pythonistas absolute use Python's standard library - and it's hardly "quite low quality". "Batteries Included" is one of the community slogans.
- clintonb 5mo agoI picked Go because it tends to use fewer resources than Node.js, and startup time is quite fast.
- hirvi74 5mo agoI've never used Node, so I can't judge it. I'm still stuck in the C# world. So, I am curious how Go performs in comparison. I'll need to do some research. Though, it was a slap in the face for a lot of C#-ers when Go beat out C# for the Typescript compiler rewrite. I personally do not mind because C# is my Enterprise language, but it's not my favorite language or anything.
- clintonb 5mo agoI don’t have any head-to-head comparisons of the same app written in both languages. I can compare apps with similar functionality: listening to GitHub web hooks vs. Linear web hooks. Both are deployed to Kubernetes. The GitHub listener written in Go has a CPU limit of 50m, but actual usage of 10m. Memory consumption is around 34MB of a 64MB limit. The Linear listener written in Typescript consumes around 20m/250m CPU, but 235MB/500MB memory. The 2x CPU and 9-10x memory consumption is significant, especially as we scale usage or add services. (Yes, I know we need to do more right-sizing.)
- DeathArrow 5mo ago>I get that it is allegedly hailed to be a simple language That might be its core feature if you do agentic coding.
- coldtea 5mo agoGo has a very full featured standard library. It's simple (do you really ask why that's a selling point?) It's fast to compile. It's fast to run. It's good with parallelism. It has myriads of examples, and LLMs can pick it up well too. It has good backing. It has good tooling. It's fun. It statically compiles to a trivially deployable binary. It's excellent at cross compiling. It has good adoption.
- hirvi74 5mo ago> (do you really ask why that's a selling point?) Yes. Assembly languages are simple, but that does not mean they easy to use well. Fast to compile? A nice to have but not a requirement of mine. Parallelism is nice, but not something of value in my current project. Perhaps the next though! I do like the LLM ease. It's make learning the language n times faster. I can get behind the good backing, tooling, fun, and ease to deploy. Hmm, I am supposed to be working on a game for a friend soon. I was going to go with C#, but I might play with Go and see how that goes.
- mrsmrtss 5mo agoFun it is not. if err != nil It's amazing how they managed to design a new language with all the flaws of '90s languages.
- coldtea 5mo agoEven that is fun. A little tedious, but straighforward, no compiler magic.
- CodesInChaos 5mo ago1. It has first-class co-routines, so supports high concurrency without having to deal with async bullshit 2. It produces a dependency-less statically linked binary 3. Duck typed interfaces give you static typing with minimal ceremony. They are implemented even for types outside your own code base, which is a common pain point in Java or C#. 4. It compiles quickly
- intelVISA 5mo agoI really don't like the lang itself but nobody will deny it has a very strong ecosystem and stdlib for handling around 95% of many well-solved problems you are likely to encounter.
- smw 5mo agogoroutines make building scalable network (web) servers trivial and fast. I'm not a big fan of the language, but the runtime is fantastic.
- kansface 5mo agoGolang truly excels at cross compiling.
- mbreese 5mo agoThat’s what I’ve settled on. Python is so flexible that there are a million ways to organize code, pass arguments, etc. If you already have a code base to work from, an LLM can make new code in the style of the old code. But a fresh project? Once you get to a certain level of complexity it quickly can turn into write once, read never code (even if the code is passing tests). This is where I’ve found that a compiled, strongly typed language (any one really) works well with an LLM. With the little bits of friction that is part of writing a language like Go, the LLM can produce pretty decent (and readable) code.
- isityettime 5mo agoTIMTOWTDI strikes back.
- mountainriver 5mo agoWhy? Go has a GC, is basically incompatible with C and very limited overall
- Alejandro2026 5mo agoGo's limited syntax is actually a feature here,because it stops the LLM from trying to be too clever
- spongebobstoes 5mo agoLLMs use `any` types, `recover`, `init`, and other weird warts of golang rust is a better language in every way for LLMs: more precise typing, better compiler errors, fewer performance footguns, no race conditions, clear interface definitions and implementations golang is easier for humans to quickly get productive, but the language is lacking in helpful features for an LLM
- badc0ffee 5mo agoCGO exists.
- mountainriver 5mo agouh huh, how's the trampoline working out?
- baq 5mo ago'incompatible with C' isn't a serious problem nowadays and won't be a problem at all in a couple years.
- mountainriver 5mo agoor the language was fundamentally designed to make mid level engineers more productive...
- deleted 5mo ago[deleted]
- shepherdjerred 5mo agoWhy use Go when you can use Rust?
- Alejandro2026 5mo agowhy,i have same question
- bionhoward 5mo agoI’m heavy into rust and never really use golang, but one big benefit of go over rust is compile times are significantly quicker, which could be more fun if you’re running CI checks 50 billion times
- coldtea 5mo ago>which could be more fun if you’re running CI checks 50 billion times Even running them 5 times it's WAY more fun
- Aerroon 5mo agoDoesn't Rust have long compile times? Does Go suffer from the same problem?
- bfung 5mo ago1. Amount of Rust training data isn’t as much as Go. 2. Golang syntax and style is very verbose yet simple. There’s not as many options nor programming language to domain mapping needed as in Rust. Leads to needing less sophisticated LLM to spit out Golang than Rust successfully and efficiently.
- trimbo 5mo agoYup, adopting Go is exactly what I've done too. Typed, garbage collected, fast to compile and run, stdlib that includes just enough to work out of the box. I really don't like writing it by hand but for the LLM it's perfect.
- DeathArrow 5mo ago>Just use Go. LLMs have seen a ton of it, they write it well, it compiles practically instantly, and it has all the advantages of a typed compiled language. Or any of the faster typed languages you are most comfortable with, as you might need to look at the code some times. LLMs are great at writing and understanding C# and Java.
- arw0n 5mo agoAlso there are still considerations like domain, team expertise, org ecosystem etc. to consider. I love to use Rust for most things, but now I'm working with an org that primarily has expertise in Java, and I'm not going to rock the boat for barely any reason. Python is also still useful for most ML stuff, and Django is quite a pleasure to work with (although it wouldn't be my first choice). The great thing about LLM-assisted coding is that an experienced software engineer can acquire decent familiarity with a language quite quickly. And then has a useful sparring partner for understanding and using the quirks and features of a new language.
- t0mas88 5mo agoSame here, working with a team that knows Java, so I'm letting Claude write Java. If I compare the results to another team that uses Python with Claude I see slightly better results on the Java side. Not because Claude knows that better, but because the tools are more rigid by default which creates more of a self correcting loop for Claude. The Python side has Pydantic, but it's a bit of an afterthought, while in Java you can't skip the type checking. In the end you can do the same things on both sides, it's 95% a team/engineering culture difference. So pick the language that the team knows best.
- morningsam 5mo ago>the LLM constantly guesses arguments or dictionary formats wrong [...] it's better to avoid that whole class of runtime errors altogether. Use Mypy in strict mode and run it in the post-turn hook of your LLM harness so the LLM has no choice but to obey it. And don't use overly general dictionary types when the keys are known at development time; use TypedDicts for annotations if you must use dicts at runtime.