There's a lot of merit in this. I call Go the Honda Odyssey Minivan of the programming world. It doesn't do anything exceptionally well but it does lots really well and in a way that's simple and reliable. Especially for the backend serving react front end niche.
But it's also a pig to write and comes with a lot of foot guns. Especially the Null handling. Somehow they made it worse than every other language.
I've worked on large Go codebases on large teams at large orgs with large dreams. That garbage us straight up unmaintainable in the large and nobody can convince me otherwise. I have deep knowledge of the language, platform, used it for over a decade. It sucks.
I like go, but a lot of little things stop me from loving it.
Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists.
I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the expense of making it harder to keep the software I'm writing in my head. Is this "enum" the same as that "enum"? I have to go read the code to figure it out.
But Go is excellent at a lot of things. Compile times, static binaries, resources compiled right into that binary, execution speed ... there is a lot to love.
You cose something and if you don't use some weird 3rd party packages (Go stdlib is quite complete) you can check that code again in 3 years and will still work.
Now that LLMs can breeze through the Rust boilerplate there's no reason to ever write Go again.
It's one of the dullest, most mediocre languages out there and despite a nice toolchain and the fact it's undoubtedly a "safe" choice, I just have zero interest.
I often think of go as a "better" python. As in, easy to learn and easy to use. But also performant and the module system and package manager seem to be a little neater. (sorry for flamebait)
But I wonder how well it can cover similar use cases? Go is great for devops and web backends. But what about AI and data science?
I love go, but I find it did little to make concurrency management easier to reason about. Race conditions are easy to write. Go routines have all the same concurrency problems of threads.
In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out?
I know it’s a toy example, but one must consider all these things in a real system. Go does have good pathways for these concerns, but it’s also easy to do it wrong. I still have to manually reason about access to variables/struct fields from multiple go routines.
I find I have to design servers from a data flow view; when my performance demands let me do everything via channels to worker goroutine pools (including sending a response Channel back to the request handler) I don’t have to do any locking at all. I find when I have to add in mutexes it means I haven’t thought enough about the problem (or I am fixing some hot spot from the profiler, rarely).
Not mentioned is that Gemini does a pretty good job of writing Go in my experience of using it to generate utility scripts, and a friend’s use of generating an internal website for using a corporate API.
I've typically leaned towards Python for my agentic programming, because the LLMs have been good at it and I'm familiar with it if I need to take a look. But I'm just finishing up an apt-cacher replacement and decided to use golang and the experience has been really great.
I'm using CC+Opus 4.7 max effort, and it's produced a working apt cacher from the first phase of development, so far there have only been a few things I've had to ask it to fix. This is over ~52KLOC (counted by "wc -l"), going on day 3 of it working on it. This includes: caching proxy, garbage collection, "http://HTTPS///" kludge (apt-cacher-ng semantics), MITM https proxy, admin website + metrics, deep validation of metadata and rejecting invalid updates, snapshots of upstream state and delayed metadata update until "hot packages" are available after metadata update...
10/10, would go again.
FYI: My agent loop is: "Work on next step, have codex review it, compact", and then a couple rounds at the end of a phase to review the code against the spec, and a couple rounds at the beginning of a phase to create the spec.
"This is getting really fucking irritating. Every 3rd comment on every HN post is "This is LLM", which has become a proxy for "I dont like it so it must be llm"
Go, similar to Rust, has a horrible ecosystem, IMHO. I want to like it, but they already broke backwards compatibility with older systems (try to get the Go compiler running on a slightly older OS X, f.ex.), and for a compiler that's a no-go to me.
Isn't that the same thing that Homebrew does? It only has CI for the last couple of Mac OS X versions. Seems like this is more of an issue with Mac OS X architecture than Go.
Dunno about Homebrew (haven't used that since many years for various reasons), but Apple is certainly pushing things in a way that makes 3rd party developers quickly abandon old systems too. That's true. At least lots of 3rd party developers are very quick to give up if their new Xcode will not cooperate.
I regret to inform you, but the post was not about maintaining old systems, it was about simplicity in creating services using a language purpose-designed for creating services. The modern underlying os/docker image was kind of a baked-in assumption.
The post was about Go and uses the "The boring choice is the right choice." point at the end. But a compiler that's so quick to abandoned previously perfectly fine supported systems, and basically is bleeding edge, is anything but the "boring right choice". I personally prefer long term stability in the toolchains I use for my projects at least.
> `if err != nil` is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it
Haven't really used Go, but can't you just `result, _ := foo()` and go on using `result`, not checking any errors?
The way Rust does it seems closer to forcing you to handle any errors in order to obtain the result (though it is still easy to just `.unwrap()` without properly thinking about it).
Since AI coding, I've switched 90% of my code to Go. It's really great for most things. Lacks a development community large enough to have a really solid UI framework, but the existing frameworks are "good enough". I used AI to make an AI agent that works on Windows, Linux, Mac, iOS, and Android, with CLI, GUI, and web serving. LOC: 5575. Binary size: 35MB.
Also: why can't we vouch for flagged stories now? This post is actually good, and funny, and the conversations are worth having.
My big issue with Go is, the language just isn't that great. Zero values instead of sum types, reflection instead of proper macros, a mediocre module system…
Java's warts are far worse than Go. Everything is nullable. There's no module system to speak of. It's so IDE-dependant.
I agree with the spirit of "use boring technology." So thank god Go is boring enough that I don't have to write Java anymore.
EJB, Spring, Ant, Struts (I'm getting old - Like Hot Java Alpha 3 and Java applets old), maven, pom files, etc.
I used to love Java but the complexity merchants showed up and ruined the party. 1.5 was just coming out when I stopped doing Java dev. Kotlin might pull me back into the fold though for when I can't use Go.
I love Go. But I prefer .NET for web development that also compiles to a binary and has a great ecosystem of libraries and packages. Go is great if standard library works (and it can for many cases) but when you need to start looking into non standard libraries, Go can hit limitations.
For example, to build a full production web application with database in Go, there is no great out of the box migration tool. There are some good 3rd party libraries of course but compared to something like EFCore in .NET, they don't come as close.
For me, it is now .NET and then Go. Of course, I use Go when just doing a lot of non web stuff as well.
Maybe some common complaints about Go are finally less of a problem in the current coding agent era - e.g. ecosystem weakness complaints and verbose error handling.
Though TypeScript's type system is maybe still more powerful - and therefore might have the edge for agents writing code? (Not to mention there's probably more TypeScript in the training data for LLMs, though perhaps there's _better quality_ Go - I'm not a Go dev though so I couldn't comment further on this.)
This is getting really fucking irritating. Every 3rd comment on every HN post is "This is LLM", which has become a proxy for "I dont like it so it must be llm"
In seriousness, Go is a good choice. Or at least it’s not a bad choice, I’d definitely pick go over many other languages. If go had a better type system, it would be damn near perfect.
Maybe I develop games. Maybe I develop IoT devices. I might even be working in a high-stakes environment where formal verification is needed, who knows.
Whatever the case may be, we all have our reasons for choosing certain technologies. Not everyone is building run-of-the-mill 'backends' after all.
So please, let's stuff that neckbeardy arrogance away. It serves no purpose and distracts from the discussion.
I still can understand the attraction with having the same language and codebase if you need a deeper level of interactivity on the frontend. That's where Node shines.
With agentic coding you can just use Rust. AI agents are really good at Rust and the good error message the compiler and or borrow checker gives makes it easy for the AI agent to adjust its code and fix it.
For non agentic coding Go has terrible error handling. It does not have exceptions or monadic error handling. Some call that a feature but many avoid Go or that specific reason. This will not change because that debate has been settled so if you can live with if err != nil after each function call (almost) then you are fine.
Things that is beautiful with Go are:
* Its simplicity
* Superb cross compilation support and excellent support for many different OS/arch combos. Not sure if anything comes close to this level of easy way of compiling to Many targets and target support.
After a few years of Kotlin, I recently ran into what I consider to be some shortcomings here as well, with respect to returning errors. As we know, Kotlin does not have checked exceptions. Ok, but ...
The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:
1) throw exception if something goes wrong
2) return null if something goes wrong (stdlib XXXorNull)
3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException
4) Use Arrow if Result<T> doesn't meet your needs
5) Return Sealed Classes / Interfaces with all the possibilities.
Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).
The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).
Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.
Exactly, I don’t know why we are even arguing over this anymore. People basically don’t write code today so why not use the best languages?
Go is handicapped in significant ways which were specifically designed so that it was easier for humans to write. People pushing for Go code in this age either don’t understand the future or the past
I can write go but I don't prefer it. It's ... okay.
Things I dislike:
- if err != nil. Just give me some syntactic sugar instead of letting me write the same thing a bajillion time.
- no way to bind a struct to an interface. I'd like my IDE to tell me when I accidentally stopped implementing an interface
- some stdlib parts are too bare bones. Unpacking an archive requires me to handle all files, directories, links, etc. myself. There is no move command that can move a file or directory across fs boundaries. The little things.
Now your compiler will tell you you stopped implementing the interface. Pretty? No. But it works. And gopls will even offer to implement stubs for missing methods.
The big idea with LLMs is consistent references in the training corpus produced cheddar output by the language model during inference.
Go is an amazing language for language models because it's actually quite boring predictable while packing a lot of powerful distractions with a world class tool chain supported by Google and strong std library as well.
As a programmer I actually hated writing Go... and wanted to write Rust; but using coding agents makes me appreciate writing Go more.
I can get consistent results out while having concurrency cross compilation and predictability.
Just fucking use the language appropriate to the task you're trying to accomplish.
Just fucking use the language your colleagues can understand and support for the next few years.
Just fucking use the language with the framework and tooling you need to get your job done efficiently and effectively, and one at the appropriate level of abstraction for the project.
Just fucking use the language which AI agents can read and write well, because we're in the End Times and this stuff matters.
Just fucking use the language with great testing and CI/CD support because you'll be spending longer supporting your code than writing it.
The skill is choosing well, and a key realisation is that it's never a one-size-fits-all thing. That's why an article like this is less than helpful, gosh darn it.
I start out writing most of my terminal applications and utilities in Python but when something hits a performance ceiling I convert it to Go. That's been a pretty good bar for when it's time to use Go for me and so far so good.
> and doesn't shit itself when a transitive dependency gets yanked from npm
For non-trivial golang apps you're still gonna find npm in the mix. I recently packaged forgejo, yopass, and a few others, and if you don't have `npm` on the build machine, the resulting daemon won't serve the front end.
I should write one of these for Haskell. Huffing abstractions is great for boring, line-of-business applications.
Goroutines? Meh. Software transactional memory and green threads? Heck yeah.
An actual type system? Chef's kiss.
Scott Wlaschin from the F# world has written and talked extensively about F# for "boring" software. It works equally well in Haskell. You don't need to use type-level meta programming to spit out a basic service.
I got turned off of Go pretty fast by GOPATH shenanigans and polluting my home directory for no reason, since I don't think a programming language should really have any say on my filesystem.
Error handling also seems pretty dumb in comparison to Rust. Admittedly Rust is a much more complicated language, but I felt like I could just go learn more Rust instead of bothering with Go and have more fun.
> Hey, dipshit. You know what compiles in two seconds, deploys as a single binary, and doesn't shit itself when a transitive dependency gets yanked from npm at 3am?
If you like a sort of weakly-typed version of Python or PHP, use Go. As the article points out it can be good for web forms. Not all development is web forms.
Strange position to take. Python and Go are both duck typed but given Go has compile time type checking it is providing another layer of safety. Could you add more detail supporting your stance?
I know this is nitpicky, but whenever I see Go code I see those capitalized function or variable names and know: “aha, these were imported from another file; or will be exported later” and I think to my self: “why? oh why is that relevant information for my at this point in the code?” and I just think about what kind of a weird ill thought out design decision that was, just to save authors from writing an “export” keyword, and further judge the rest of the language predicting it must have more weird design decisions in it.
I would like someone to explain me Go. Really, I will use strong words but that's really what I feel.
The syntax changes a lot from the C one, and I can't see any reason for it. To me, it looks unstructured, with the lack of colons for example. It ignores memory safety, it feels like it ignored all of the typing system research since C, no discriminated union, and structures and types in general are heavy to write. It encourages bad patterns, errors out on mundane things like an unused variable, forces you to handle errors with a lot of code while not catching much more than C in terms of bug-prone practices. The package/module system is a nightmare for contributing to open source projects. Modifying a dependency to find a bug is very hard, even swapping a dependency (version) is annoying.
And what do you get from all of this compared to C? A garbage collector, tuples, and goroutines. No metaprogramming (aside from generics, and that was a whole story), interop with C is limited. To me, it looks like it does not focus on the algorithms, but on the code implementation, which is imo what leads us into poor programming and missing critical logic flaws, because the logic is buried. I may have forgotten other gripes I got while working with Go, but honestly, if I wanted all of that, I would pick D, at least it interops well with C and has metaprogramming (and has been made earlier, which excuses a little the lack of certain things).
But really, I am open to someone explaining me how they enjoy Go. Because I feel like I should be wrong as I see most people (which, for some of them, I know are clever) praise Go.
Edit: I added modal expressions to make it clear that it is my opinion.
I like it because I have more control over the size and layout of my memory structures than many GC languages, and the goroutine/channel data flow design model lets me use all the cores pretty evenly without having to worry about mutexes or subtleties. Pretty easy to get into the 100k request per second performance regime without special tweaking. I tend to either write long lived servers where the performance per container directly affects the cost, or analytics sort of Calais where I want my laptop to use 1/2 or 3/4 of its cores and get a faster answer from scraping 10M whatevers.
There's a lot of merit in this. I call Go the Honda Odyssey Minivan of the programming world. It doesn't do anything exceptionally well but it does lots really well and in a way that's simple and reliable. Especially for the backend serving react front end niche.
But it's also a pig to write and comes with a lot of foot guns. Especially the Null handling. Somehow they made it worse than every other language.
Why the Null handling and in Go is worse than others?
Nilaway linter FTW here.
I've worked on large Go codebases on large teams at large orgs with large dreams. That garbage us straight up unmaintainable in the large and nobody can convince me otherwise. I have deep knowledge of the language, platform, used it for over a decade. It sucks.
I like go, but a lot of little things stop me from loving it.
Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists.
I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the expense of making it harder to keep the software I'm writing in my head. Is this "enum" the same as that "enum"? I have to go read the code to figure it out.
But Go is excellent at a lot of things. Compile times, static binaries, resources compiled right into that binary, execution speed ... there is a lot to love.
I really wish they had added Enums instead of the stupid generics.
The best feature of Gon is that it is boring.
You cose something and if you don't use some weird 3rd party packages (Go stdlib is quite complete) you can check that code again in 3 years and will still work.
I can't see any reason this list why I should use Go over C# / .NET.
.NET has almost all these upsides, but with a concurrency model (async/await) that is (now) more transferable to other languages.
Agreed-- c# has a lot of these advantages and is a lot easier to write (yes, I know this will depend). Plus it has a much larger ecosystem
The only thing I can think of: I dont think c# can compile as easy to a single executable binary, like Go (or even rust)?
It's had support for single exe compilation for a while now, although the file sizes can get large without being more careful about dependencies.
Go is fine for simple applications especially backend ones that connect to the internet. I do prefer it to node/js/ts/etc.
I do think a lot of projects would be better served having been written in go instead of java, or whatever else.
I don't think it's a panacea for anything. It's pretty easy to shoot yourself in the foot with. The easy stuff is easy the hard stuff is really hard.
I like rust a little more, and I don't rewrite things with it. I choose it first. That's my preference but go ahead and gopher on.
Now that LLMs can breeze through the Rust boilerplate there's no reason to ever write Go again.
It's one of the dullest, most mediocre languages out there and despite a nice toolchain and the fact it's undoubtedly a "safe" choice, I just have zero interest.
I often think of go as a "better" python. As in, easy to learn and easy to use. But also performant and the module system and package manager seem to be a little neater. (sorry for flamebait)
But I wonder how well it can cover similar use cases? Go is great for devops and web backends. But what about AI and data science?
If Go interfaced with C as well as Python, I’d use it a lot more.
But I’m using the slower language because it still integrates with more things
For example, one reason AI is all in Python is because CUDA is basically part of the C ecosystem (ie build system)
I love go, but I find it did little to make concurrency management easier to reason about. Race conditions are easy to write. Go routines have all the same concurrency problems of threads.
In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out?
I know it’s a toy example, but one must consider all these things in a real system. Go does have good pathways for these concerns, but it’s also easy to do it wrong. I still have to manually reason about access to variables/struct fields from multiple go routines.
I find I have to design servers from a data flow view; when my performance demands let me do everything via channels to worker goroutine pools (including sending a response Channel back to the request handler) I don’t have to do any locking at all. I find when I have to add in mutexes it means I haven’t thought enough about the problem (or I am fixing some hot spot from the profiler, rarely).
Not mentioned is that Gemini does a pretty good job of writing Go in my experience of using it to generate utility scripts, and a friend’s use of generating an internal website for using a corporate API.
I've typically leaned towards Python for my agentic programming, because the LLMs have been good at it and I'm familiar with it if I need to take a look. But I'm just finishing up an apt-cacher replacement and decided to use golang and the experience has been really great.
I'm using CC+Opus 4.7 max effort, and it's produced a working apt cacher from the first phase of development, so far there have only been a few things I've had to ask it to fix. This is over ~52KLOC (counted by "wc -l"), going on day 3 of it working on it. This includes: caching proxy, garbage collection, "http://HTTPS///" kludge (apt-cacher-ng semantics), MITM https proxy, admin website + metrics, deep validation of metadata and rejecting invalid updates, snapshots of upstream state and delayed metadata update until "hot packages" are available after metadata update...
10/10, would go again.
FYI: My agent loop is: "Work on next step, have codex review it, compact", and then a couple rounds at the end of a phase to review the code against the spec, and a couple rounds at the beginning of a phase to create the spec.
I read this, as my computer crashed while compiling a 1000 dependency CRUD rust app, for the fourth time today. Then I take a deep breath.
RAM test and check swap memory is large enough. A compiler can't take down the whole machine.
If you've found an actual compiler bug (especially in rustc) it usually replicates reliability and reports itself as such.
Why is this flagged? Because of the swearing? Cause there have been previous posts with swearing in them? Or do people in general hate Go so much?
I know the OP said dont use external libraries, but I love bubble tea (And their related libs), they are a great reason to use Go for TUI
that said, I only use Go for hobby projects, I dont know how good it feels if you have to use it for work 40 hours a week
It's likely being flagged because people believe it's more AI-written than not
Let me copy paste my other comment:
"This is getting really fucking irritating. Every 3rd comment on every HN post is "This is LLM", which has become a proxy for "I dont like it so it must be llm"
I'll grit my teeth and tolerate "if err != nil" if I have to, but null pointers are where I get off the train.
Go, similar to Rust, has a horrible ecosystem, IMHO. I want to like it, but they already broke backwards compatibility with older systems (try to get the Go compiler running on a slightly older OS X, f.ex.), and for a compiler that's a no-go to me.
Isn't that the same thing that Homebrew does? It only has CI for the last couple of Mac OS X versions. Seems like this is more of an issue with Mac OS X architecture than Go.
Dunno about Homebrew (haven't used that since many years for various reasons), but Apple is certainly pushing things in a way that makes 3rd party developers quickly abandon old systems too. That's true. At least lots of 3rd party developers are very quick to give up if their new Xcode will not cooperate.
I regret to inform you, but the post was not about maintaining old systems, it was about simplicity in creating services using a language purpose-designed for creating services. The modern underlying os/docker image was kind of a baked-in assumption.
The post was about Go and uses the "The boring choice is the right choice." point at the end. But a compiler that's so quick to abandoned previously perfectly fine supported systems, and basically is bleeding edge, is anything but the "boring right choice". I personally prefer long term stability in the toolchains I use for my projects at least.
> `if err != nil` is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it
Haven't really used Go, but can't you just `result, _ := foo()` and go on using `result`, not checking any errors?
The way Rust does it seems closer to forcing you to handle any errors in order to obtain the result (though it is still easy to just `.unwrap()` without properly thinking about it).
Since AI coding, I've switched 90% of my code to Go. It's really great for most things. Lacks a development community large enough to have a really solid UI framework, but the existing frameworks are "good enough". I used AI to make an AI agent that works on Windows, Linux, Mac, iOS, and Android, with CLI, GUI, and web serving. LOC: 5575. Binary size: 35MB.
Also: why can't we vouch for flagged stories now? This post is actually good, and funny, and the conversations are worth having.
> The boring choice is the right choice. It always was.
Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?
My big issue with Go is, the language just isn't that great. Zero values instead of sum types, reflection instead of proper macros, a mediocre module system…
Java's warts are far worse than Go. Everything is nullable. There's no module system to speak of. It's so IDE-dependant.
I agree with the spirit of "use boring technology." So thank god Go is boring enough that I don't have to write Java anymore.
EJB, Spring, Ant, Struts (I'm getting old - Like Hot Java Alpha 3 and Java applets old), maven, pom files, etc.
I used to love Java but the complexity merchants showed up and ruined the party. 1.5 was just coming out when I stopped doing Java dev. Kotlin might pull me back into the fold though for when I can't use Go.
Where my brain went.
[dead]
Lack of extensive standard library, for one. But yeah Java is pretty great. Spring boot/quarkus especially
I love Go. But I prefer .NET for web development that also compiles to a binary and has a great ecosystem of libraries and packages. Go is great if standard library works (and it can for many cases) but when you need to start looking into non standard libraries, Go can hit limitations.
For example, to build a full production web application with database in Go, there is no great out of the box migration tool. There are some good 3rd party libraries of course but compared to something like EFCore in .NET, they don't come as close.
For me, it is now .NET and then Go. Of course, I use Go when just doing a lot of non web stuff as well.
Maybe some common complaints about Go are finally less of a problem in the current coding agent era - e.g. ecosystem weakness complaints and verbose error handling.
Though TypeScript's type system is maybe still more powerful - and therefore might have the edge for agents writing code? (Not to mention there's probably more TypeScript in the training data for LLMs, though perhaps there's _better quality_ Go - I'm not a Go dev though so I couldn't comment further on this.)
Screams LLM. They're very bad at being sober without sounding edgy. This is only edgy
> Screams LLM.
This is getting really fucking irritating. Every 3rd comment on every HN post is "This is LLM", which has become a proxy for "I dont like it so it must be llm"
Nothing about this screams LLM; it's very clearly a riff on Just fucking use HTML and Just Fucking Use Postgres
https://justfuckingusehtml.com/
https://www.justfuckingusepostgres.com/
It was funny the first time. Maybe second. Third is just a bad taste, not original, not funny.
I took the mistake of reading further and my speculation was confirmed. A lot of red flags
> "No X, no Y, just fucking Z".
Hmm, they misspelled Gleam.
In seriousness, Go is a good choice. Or at least it’s not a bad choice, I’d definitely pick go over many other languages. If go had a better type system, it would be damn near perfect.
Go's Webassembly story is a joke at the moment, so no.
Yeah, C is king right now.
> necessary for a CRUD app that does maybe forty requests a second.
That's a DoS attack in the python world.
Hey dipshit,
Maybe I develop games. Maybe I develop IoT devices. I might even be working in a high-stakes environment where formal verification is needed, who knows.
Whatever the case may be, we all have our reasons for choosing certain technologies. Not everyone is building run-of-the-mill 'backends' after all.
So please, let's stuff that neckbeardy arrogance away. It serves no purpose and distracts from the discussion.
Thanks.
P. s. I develop my backends in go.
I still can understand the attraction with having the same language and codebase if you need a deeper level of interactivity on the frontend. That's where Node shines.
With agentic coding you can just use Rust. AI agents are really good at Rust and the good error message the compiler and or borrow checker gives makes it easy for the AI agent to adjust its code and fix it.
For non agentic coding Go has terrible error handling. It does not have exceptions or monadic error handling. Some call that a feature but many avoid Go or that specific reason. This will not change because that debate has been settled so if you can live with if err != nil after each function call (almost) then you are fine.
Things that is beautiful with Go are: * Its simplicity * Superb cross compilation support and excellent support for many different OS/arch combos. Not sure if anything comes close to this level of easy way of compiling to Many targets and target support.
> Not sure if anything comes close to this level of easy way of compiling to Many targets and target support.
Cross-compilation has been a standard feature of every compiled language toolchain for the past decade at least.
Also a big plus for Go: no async.
After a few years of Kotlin, I recently ran into what I consider to be some shortcomings here as well, with respect to returning errors. As we know, Kotlin does not have checked exceptions. Ok, but ...
The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:
1) throw exception if something goes wrong
2) return null if something goes wrong (stdlib XXXorNull)
3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException
4) Use Arrow if Result<T> doesn't meet your needs
5) Return Sealed Classes / Interfaces with all the possibilities.
Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).
The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).
Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.
Exactly, I don’t know why we are even arguing over this anymore. People basically don’t write code today so why not use the best languages?
Go is handicapped in significant ways which were specifically designed so that it was easier for humans to write. People pushing for Go code in this age either don’t understand the future or the past
I can write go but I don't prefer it. It's ... okay.
Things I dislike:
- if err != nil. Just give me some syntactic sugar instead of letting me write the same thing a bajillion time.
- no way to bind a struct to an interface. I'd like my IDE to tell me when I accidentally stopped implementing an interface
- some stdlib parts are too bare bones. Unpacking an archive requires me to handle all files, directories, links, etc. myself. There is no move command that can move a file or directory across fs boundaries. The little things.
> I'd like my IDE to tell me when I accidentally stopped implementing an interface
I don't know about others, but Goland's analyser is pretty powerful and can navigate from interface to implementation(s) and vice versa.
I wrote about this here [1]
The big idea with LLMs is consistent references in the training corpus produced cheddar output by the language model during inference.
Go is an amazing language for language models because it's actually quite boring predictable while packing a lot of powerful distractions with a world class tool chain supported by Google and strong std library as well.
As a programmer I actually hated writing Go... and wanted to write Rust; but using coding agents makes me appreciate writing Go more.
I can get consistent results out while having concurrency cross compilation and predictability.
https://jry.io/writing/ai-makes-golang-one-of-the-best-langu...
Just fucking use the language appropriate to the task you're trying to accomplish.
Just fucking use the language your colleagues can understand and support for the next few years.
Just fucking use the language with the framework and tooling you need to get your job done efficiently and effectively, and one at the appropriate level of abstraction for the project.
Just fucking use the language which AI agents can read and write well, because we're in the End Times and this stuff matters.
Just fucking use the language with great testing and CI/CD support because you'll be spending longer supporting your code than writing it.
The skill is choosing well, and a key realisation is that it's never a one-size-fits-all thing. That's why an article like this is less than helpful, gosh darn it.
How well does Go handle GPGPU?
I start out writing most of my terminal applications and utilities in Python but when something hits a performance ceiling I convert it to Go. That's been a pretty good bar for when it's time to use Go for me and so far so good.
> and doesn't shit itself when a transitive dependency gets yanked from npm
For non-trivial golang apps you're still gonna find npm in the mix. I recently packaged forgejo, yopass, and a few others, and if you don't have `npm` on the build machine, the resulting daemon won't serve the front end.
Go or Rust in 2026 is the standard go to and I never looked back on anything else.
I would not consider anything else without a good reason and especially never going for Javascript or TypeScript for anything server related.
I should write one of these for Haskell. Huffing abstractions is great for boring, line-of-business applications.
Goroutines? Meh. Software transactional memory and green threads? Heck yeah.
An actual type system? Chef's kiss.
Scott Wlaschin from the F# world has written and talked extensively about F# for "boring" software. It works equally well in Haskell. You don't need to use type-level meta programming to spit out a basic service.
Monads are a great honking idea, btw.
I know it doesn't matter, but...
...who invented this letter-casing convention?
why is the name of a module lower-casedbut the names of functions accessed via its namespace upper-cased?
how does this make sense?
Upper case symbols in a module are exported. Everything else should be lower case.
Say No to Go.
A dig at Django's ORM seems hilarious. I wonder how many SQL injection vulnerabilities are written daily by Go devs.
sqlc is pretty darn great but it's no comparison to Django. Django has its own problems and I would love for it to take some lessons from sqlc.
Really hate we don't have proper type hints for Django.
> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it.
It truly does not.
Lately using go is becoming attractive to me also this seems a sign to take the plunge
I got turned off of Go pretty fast by GOPATH shenanigans and polluting my home directory for no reason, since I don't think a programming language should really have any say on my filesystem.
Error handling also seems pretty dumb in comparison to Rust. Admittedly Rust is a much more complicated language, but I felt like I could just go learn more Rust instead of bothering with Go and have more fun.
> the race detector will tell you when you screwed up.
lol
> if err != nil {
lmao
> defer rows.Close()
Oh dear
...
I'm only poking fun, I'll take a go backend any day over most of the alternatives. Same goes for CLI tools.
> Hey, dipshit. You know what compiles in two seconds, deploys as a single binary, and doesn't shit itself when a transitive dependency gets yanked from npm at 3am?
OCaml?
archived: https://nonogra.ph/just-fucking-use-go-05-08-2026
If you like a sort of weakly-typed version of Python or PHP, use Go. As the article points out it can be good for web forms. Not all development is web forms.
Strange position to take. Python and Go are both duck typed but given Go has compile time type checking it is providing another layer of safety. Could you add more detail supporting your stance?
how is go a weakly typed version of python or php? or even more generic, how is go weakly typed? explain please.
no!
I know this is nitpicky, but whenever I see Go code I see those capitalized function or variable names and know: “aha, these were imported from another file; or will be exported later” and I think to my self: “why? oh why is that relevant information for my at this point in the code?” and I just think about what kind of a weird ill thought out design decision that was, just to save authors from writing an “export” keyword, and further judge the rest of the language predicting it must have more weird design decisions in it.
[dead]
I would like someone to explain me Go. Really, I will use strong words but that's really what I feel.
The syntax changes a lot from the C one, and I can't see any reason for it. To me, it looks unstructured, with the lack of colons for example. It ignores memory safety, it feels like it ignored all of the typing system research since C, no discriminated union, and structures and types in general are heavy to write. It encourages bad patterns, errors out on mundane things like an unused variable, forces you to handle errors with a lot of code while not catching much more than C in terms of bug-prone practices. The package/module system is a nightmare for contributing to open source projects. Modifying a dependency to find a bug is very hard, even swapping a dependency (version) is annoying.
And what do you get from all of this compared to C? A garbage collector, tuples, and goroutines. No metaprogramming (aside from generics, and that was a whole story), interop with C is limited. To me, it looks like it does not focus on the algorithms, but on the code implementation, which is imo what leads us into poor programming and missing critical logic flaws, because the logic is buried. I may have forgotten other gripes I got while working with Go, but honestly, if I wanted all of that, I would pick D, at least it interops well with C and has metaprogramming (and has been made earlier, which excuses a little the lack of certain things).
But really, I am open to someone explaining me how they enjoy Go. Because I feel like I should be wrong as I see most people (which, for some of them, I know are clever) praise Go.
Edit: I added modal expressions to make it clear that it is my opinion.
I like it because I have more control over the size and layout of my memory structures than many GC languages, and the goroutine/channel data flow design model lets me use all the cores pretty evenly without having to worry about mutexes or subtleties. Pretty easy to get into the 100k request per second performance regime without special tweaking. I tend to either write long lived servers where the performance per container directly affects the cost, or analytics sort of Calais where I want my laptop to use 1/2 or 3/4 of its cores and get a faster answer from scraping 10M whatevers.