That's a DoS attack in the python world.

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?

Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?

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.

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.

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.

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.

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

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.

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.

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

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.

...who invented this letter-casing convention?

    import (
        "embed"
        "html/template"
        "net/http"
    )

    //go:embed templates/*.html
    var files embed.FS

    var tmpl = template.Must(template.ParseFS(files, "templates/*.html"))

but the names of functions accessed via its namespace upper-cased?

how does this make sense?

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.

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.

OCaml?

.NET has almost all these upsides, but with a concurrency model (async/await) that is (now) more transferable to other languages.

Also: why can't we vouch for flagged stories now? This post is actually good, and funny, and the conversations are worth having.

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

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 would not consider anything else without a good reason and especially never going for Javascript or TypeScript for anything server related.

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.

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.

It truly does not.

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

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.

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

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.

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.