Just Use Go

ChocolateGod

> necessary for a CRUD app that does maybe forty requests a second. That's a DoS attack in the python world.

alexander2002

Lately using go is becoming attractive to me also this seems a sign to take the plunge

worldsayshi

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?

twic

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

perarneng

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.

2ndorderthought

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.

baalimago

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.

codegeek

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.

treis

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.

shrubble

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.

krona

Go's Webassembly story is a joke at the moment, so no.

sudb

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

runarberg

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.

thomascgalvin

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.

binaryturtle

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.

boxed

A dig at Django's ORM seems hilarious. I wonder how many SQL injection vulnerabilities are written daily by Go devs.

xRyen

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.

nohell

archived: https://nonogra.ph/just-fucking-use-go-05-08-2026

elevation

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