Lies we tell ourselves to keep using Golang

I don't really use Go, I think mostly because I'm not in the target market, but this article's complaints (and some of these comments) actually got me thinking that I should take another look at it.

A long time ago, in a Haskell community chat, I saw someone dismiss Go with a pithy comment along the lines of, "Go isn't a programming language, it's a DSL for writing network services." I think I may need to re-assess that comment as actually being a really compelling elevator pitch for the language.

Armed with that perspective, I'm seeing why I wasn't terribly convinced by the article's specific complaints about Go. "Traditional IPC is a PITA and forces you toward talking over a socket? Well, yes, exactly. That's kind of the whole point."

Sometimes I wonder if we are all suffering unnecessarily because of our incessant demanding that all languages try to be all things to all people.

I was struck by ThePrimeagen[0] saying that it took him 5x longer to write a game server in Rust than in Go—despite having significantly more Rust experience. They performed about the same (I think Go actually did better due to how much easier it was to get concurrency working?).

Personally I lean towards strict compilers (I suppose years of JavaScript has traumatized me), but 5x dev time is a big tradeoff! Of course this is just one data point, but it did seem worth mentioning.

[0] - https://www.youtube.com/watch?v=Z0GX2mTUtfo

The problem with:

"I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd...

None of the modern language do it beside Rust so every language are then bad?

Checkout Elixir, I think it's better than GO for a lot of the use cases GO handles.

Oh man. The fake ads on that first link had me rolling around. Have an upvote!

Haha, your comment on the weird date formatting rings very true.

> If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine.

as the person on call for such events, it's really not fine.

would you rather handle these errors upfront during development time or unexpectedly and uncontrollably, during runtime? having been on-call in one way or another for ~10 years, i know which i'd prefer.

after having used golang in production, i will never go back to using a dynamically typed language if i can avoid it. almost 0 thought or effort is required to handle errors correctly in go, and it's still possible to ignore them (just use `_`). not that i'd recommend ever doing that.

> If something blows up in production

The problem is if it doesn’t quickly blow up, but instead silently corrupts data or causes other problems down the line that are hard to backtrack to that specific missing check.

> Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests.

I kinda get it though, because the compiler or linters will show that as a warning or error going "bruh you forgot to handle this error", and as a perfectionist one wants to get rid of all of those.

I mean IMO those should be logged anyway, if only so you get some data on how often it happens, if there's anything that can be done about it, and if it's harmless, to ignore the error - but make it explicit.

It's buried in the article, but I think the suggestion is "use almost any language other than Go" rather than Rust specifically.

The takeaway - if you gloss over the ranting and look for the good bits - seems to be that you should choose a language that handles a lot of the boilerplate for you (e.g., no verbose error handling) and has FFI.

It's not a bad argument, and it's making me think about how and when I use Go. For that, at least, it's worth reading.

It's really not, and it's even saying so explicitly in the article.

Why not Node? Or Typescript if you really have to have types? Or even plain old PHP/Ruby (for people that just use Go to build web backends) - doesn't Kubernetes kinda solve scaling?

This strikes me as very odd. The post yesterday is about a 2-year-old article. This post is about a brand new article, from the same author, written more or less as a response to all of the responses to the original article over the past 2 years.

If a flamewar is a problem, then that's what moderation is for, including potentially locking. I know you've posted comments on divisive articles before cautioning everyone about not wanting the comments to devolve into a flamewar, that would have been a great first step here.

But instead of doing that, you're saying that because of the old article popping up again yesterday and rehashing the same old flamewar, you've chosen to suppress the author's own response. I would think that the old article popping up yesterday makes this new post especially timely and even more important. It's not a rehash of the old flamewar, it's the author's own words with a well-written and fairly comprehensive response to the common criticisms, and it's highly relevant to the HN audience. And especially in the context of the discussion yesterday it seems a good idea to ensure visibility of the author's own response so anyone who saw yesterday's flamewar can see this. It took 2 years from the old post for the author to write this response, I'm pretty sure you don't have to worry about having a third post tomorrow.

I learned a great deal from the article. Thankfully I discovered it from twitter. If flame wars are the issue, then the thread should be locked, rather than pulling it from the front page. Really disappointed in this move.

> Having another big Go flamewar the next day...

I haven't read all the comments on this one yet - there are quite a lot of them already - but reading this makes me think that perhaps we don't see the same comment section. (Perhaps because I'm not tasked with moderation, so I don't have much reason to go look at the 2nd page.) They've mostly been very thoughtful and balanced. It strikes me as some of the highest quality discussion on the subject of Go that I've seen on this site in years. It's a shame it was flagged and then buried on the 2nd page. A pinned comment reminding us not to get our hackles up in response to the author's abrasive style seems like it would have been plenty sufficient. I fear that, in your haste to head off an anticipated flamewar, what you've actually done is suppressed a potentially healing example to the community that it really is possible to have a mature conversation about Go.

I appreciate the extra context. For what it's worth, I was not aware of the previous discussion and I just thought it was an interesting post. (I really don't have any feelings about golang one way or another.)

I can appreciate your point about having limited resources to moderate posts that have a track record of generating big flamewars. But I didn't get the impression from the comments (many being ad-hominem) that the post was flagged for that reason and my use of the word "shameful" was directed at those comments.

As someone coding in Go (and having doubts about the language) I find articles like this professionally valuable.

They don't have to be correct, they just need to provoke meaningful discourse, which for me means crowdsourcing the insights of hundreds of fellow devs.

I agree. The signal to noise ratio of these "Rust vs Go" post comments is so bad they border being mostly a pile of anecdotes.

Also not meant to diminish the blogger but if you check their posts, it almost seems they feed on Go flamewar.

I could read every one of the 443 comments and still come out with zero knowledge gained because that's the kind of comment these posts incentivize.

Startups were built with less man-hours than what was collectively wasted on this thread.

It's like this: when the input is a soup of reasoned discussion plus sensational flamebait, the flamebait will always dominate, and will always determine the output. Sad, but reliable.

Because people learn to cling emotionally to hyped-up topics.

Any criticism of sacred icon is taken like an aggression to the reader's sense of self.

What's "inappropriate" about the post? I for one wish that we had more posts like these instead of typical stuff that has been getting to the front page lately.

That post also got flagged initially FWIW.

I find it difficult to see a standard where Rust is not ready for "serious work" but Haskell is.

What did you think those warts were?

> GRPC and protobufs are f'in messy and full of footguns.

Distributed data modeling is inherently messy and IME gRPC is one of the least messy, most scalable solutions to it. Or do you have a better alternative?

> "Why are my TCP connections not closing? Why am I encountering port exhaustion?"

So… why?

"Why are my TCP connections not closing? Why am I encountering port exhaustion?"

This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false.

Networking works just fine in Go and it's actually easy to use.

https://pkg.go.dev/net

Edit: I'm getting downvoted but please share with TCP issues in Go.

> Building a successful company has very little to do with tech choices.

This is what Hacker News doesn't want to hear, and so needs to hear.

Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.

Especially when other languages got them right.

Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc.

A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, reference counted) and not worry about any of the low level memory management details.

See things like https://ggez.rs/ for games and https://www.arewewebyet.org/ for web stuff.

Although honestly I think if you're looking for a "hot" backend web language I'd say Elixir is the more well designed one than Go.

Rust is indeed a general purpose programming language, but unlike the sibling poster I'm not going to sell it for low-level systems programming _and_ other things just because it can and has some (hit-or-miss depending on the domain) crates for them.

Rust is a complex language and its APIs tend to reflect the underlying domain complexity nearly 1:1. It also does not have a GC. Rust interops with native code well. When you're writing code that needs to be very correct especially in complicated problem domains, Rust is a great language to reach for because it bubbles up that underlying complexity so well. If you really need the lack of GC pausing then Rust is also IMO much better than most other non-GC languages in common use (c.f. C, C++). If you need C interop, then Rust is great. If you're a fan of writing elegant abstractions, Rust is also a great tool as its macro processor and language constructs make it easy to write abstractions (compared to other imperative languages at least). But its use for other areas is, IMO, a bit fraught.

Go is a lot more opinionated as a language. Its stdlib hides the complexity for certain interfaces. It has a simple-to-use concurrency model that the whole language opts into. It compiles quickly. It produces a no-nonsense static binary and has a great cross-compilation story. Go code is repetitive but simple to read. Go's tooling is stellar and because of how easy it is to write third-party tooling, people often build useful tools for themselves. I find it really easy to hack on or debug other Go projects if needed. Overall, Go is opinionated, and if the applications you're writing and the style you're writing them in fall into Go's opinions then you'll love it. If you don't like Go's style, you'll hate it. Go is my go-to (pun not intended lol) language for hobby coding because when coding as a hobby I'm often working on a constrained problem and don't need Rust's complexity.

To offer a concrete example, the OP in his previous blog post wrote a diatribe about Go's filepath handling on Windows, but when I recently used Rust to write something that templated a few filenames, the whole thing took incredibly long. The complexities of Rust filepaths accurately reflect all the edge cases available for different platforms but was ridiculous overkill for my simple app that I was hacking on that was only ever going to run on a single Linux x64 platform.

IMO to just "get things done" use Go. If you find yourself fighting Go's idioms, then Go isn't for you. If you really enjoy writing elegant abstractions, Go isn't for you. If you need to go deep into an API that Go simplifies and will spend most of your logic doing just that, then Go isn't for you. If you can't tolerate the GC pauses then Go isn't for you. Otherwise just use Go to get stuff done.

There are a few things, mostly due to the runtimes but also because the JVM bytecode assumption has real implications for system behavior.

Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to make this better). For some people, just as bad or even worse (remember, distributed system) is the impact that JIT-compilation and warm-up has on tail latencies. The static nature of most compiled languages mean this isn't a thing you worry about. You've got enough tail latency problems in your life, you don't need "oh hey, I just saw this loop for the Nth time, I took 10ms to hot compile it!".

That leads into the runtime and some of the language choices around it. Java GCs are generally fighting a harder problem than Go's GC, and with a very different tuning point. Java making everything an object and support classloading and so on, has real knock-on effects for the amount of work required to get high-quality, low-pause GC to work. This is much better today than it was in 2008 when the Go team started, but it's still the case that Go has an out-of-the-box better GC experience. Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that work in Go; I applaud the ingenuity in Java GC work, but if what you care about is "reasonably good at collecting memory, never pauses for long", the Go language decisions made the GC problem easier.

I think it's fair to ask "Shouldn't Google have just improved Java?", but I think you miss out on lots of the concurrency ergonomics. Again, this has to be compared to a decade ago. Especially post 2010 (Oracle acquisition) it was super unclear that you'd want to attempt to "bet on Java".

To be clear, I do think Go is at the wrong point on the language/type-system sophistication curve for my tastes. That said, I find myself shaking my head at most Java code, while looking at the Go code and thinking "sigh, lots of repetition. I hope one day that gets better, but at least it's obvious".

As developers get more and more senior, they have a different perspective on what constitutes a "serious" problem. Also, as developers get more experience with a language, they get better at doing things in ways that are idiomatic for that language - they work with the language instead of against it.

Take Haskell. If I were a Haskell novice, and tried to do everything procedurally with do notation, and then complained that Haskell had all these problems, would that make Haskell a bad language? No. Would it mean that all Haskell programmers were telling themselves lies in order to keep using it? No. It would mean that I was using it badly.

If I were a brand new programmer, and took up Java, I might well complain about "public static void main(String[] args)". But an experienced programmer would brush that off, telling me that that's just syntax - there are real problems with Java, but that isn't one.

So this particular statement, that senior and more experienced devs ignore more and more problems, isn't proof of anything. It's particularly not proof that developers have to keep lying to themselves in order to keep using Go. (They may, but this isn't proof.)

As developers get more and more senior they tend to ignore more and more problems because they realize the majority of them actually don't matter very much to doing useful work.

He made some good points in the article but this particular paragraph stuck out as being hypocritical. The entire motivation of him writing this was because he felt people dismissed his previous article out of hand. And then he makes a remark that preemptively dismisses any rebuttal out of hand (and as others have pointed out, can equally apply to any language so hardly a point worth complaining against Go specifically).

> as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it.

I've been coding professionally since the 90s. The last project I worked on was in Go. It was pleasant and surprisingly productive. A few warts, like the parent said, but all told it was a great experience. I'm now working on a Typescript project. It is painful. Typescript itself is quite nice, but the deep problems with the rest of the ecosystem have not gone unnoticed.

Hmm won't this apply to any language and therefore not a valid argument? A: language FOO is a great language! B: You are telling lies because you are fluent in this language and ignore the problems in the language.

As an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute nightmare. But at least I with MUSL can I have a 100% statically linked binary, which really should have been easier but that's another argument.

Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.

Go tooling is awesome compared to other language ( Rust included ). Everything is built it and you don't need something external, everything works out of the box dependencies included, it has been the case for 4 years with go mod.

The fact that you can cross compile a win10 .exe on a raspberry pi with a single command as easy as "GOARCH=amd64 GOOS=win go build ." it's very powerful and I don't know a single language that does it out of the box like go does.

Go tooling is one of the strongest point of Go you have all of that built-in:

- compilation

- testing

- benchamark

- dep managment

I love Rust as a language but its packaging mechanism is as flawed as all the others. I don't really see what breath of fresh air it brings.

I suppose you can define feature flags in your Cargo.toml but that's about it.

Golang has the most hilarious approach to date formatting

> As far as I know, no other popular language allows you to read from multiple queues at the same time

Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about.

That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.

If that's all you want, Haskell has had goroutines (forkIO, yes it's called "fork" but it doesn't spawn an OS level process, that's forkOS), channels, and select since 1996. https://www.microsoft.com/en-us/research/wp-content/uploads/...

here's some documentation on how to do it in C++ with boost in 2008, before go even existed: in this example two threads pull events from a single queue.

https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tu...

(of course it was possible before)

>read from multiple queues at the same time

That's a trivial thing in javascript.

Lots of languages have similar async, channel and pattern matching syntax these days. Kotlin, C#, off the top of my head. Probably a lot more.

The language spec (https://go.dev/ref/spec) is about 96 pages when printed on A4 paper. Certainly not a page long.

If a language spec is only a page long, it's leaving a bunch of important things unspecified.

> Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc.

Depends on which implementation you're talking about. One of the stated goals of the Go project is that there must not be just one implementation. gc does not, but tinygo depends on llvm. gccgo depends on gcc.

I don’t think I’ve ever seen Java used in isolation without spring boot

How is Spring Boot not Java? Spring Boot is a simple Java library.

I seriously doubt that Go would compile faster than Java. Like, neither does any reasonable amount of optimization, and I have never heard Java considered slow in compile time. Sure, one can do some very cryptic module-graph with their chosen build tool, but otherwise it should be as fast as it gets.

I dont know them as well as I do Go but the libraries (java especially) don't feel as coherent as the go libraries do, though that may be subjective and to do with my lack of experience with them. In addition both of these languages are large enough and have projects structured in such a way as to make it difficult to just use a text editor, which i consider a barrier to me just 'cracking out' a project.

C# also had pretty middling linux support the last time i worked with dotnet. and java tooling is not as out of the box as go is where I have to know is gradle good or still used or should i just use maven. Its all part of me not wanting to have to choose the best dependencies for my project and being handed for the most part good enough dependencies by the language standard library.

Another thing to appreciate in go is it produces good enough binaries and produces them very very quickly -- i've worked on several massive go projects and the build/test turnaround time is quite good.

With Go you can develop a web service with few to no external deps or frameworks, compile it into a single, static binary and then deploy it in a minimal distroless container.

With Java and C# there's a lot of other fuss involved with figuring out deployment. The code, build, test cycle is also much slower in C#/.NET ime. That's starting to improve a bit with the newer dotnet, but still feels behind other everything but the kitchen sink frameworks like Rails, which I would more compare C# to since C# without .NET/dotnet is uncommon.

Interestingly, I have always heard Go is simple, but not easy.

It's always sad to see when someone's favorite tool gets criticized that they fail to realize that there is no perfect tool and that we're just talking about tools.

It always plays out that way though.

"Not being adequate != don't use it ever". Plenty of situations where pragmatism leads us to building things with "inadequate" tools.

Besides that, you do realize that your comment is a perfect embodiment of "Others use it, so it must be good for us too", which is the very first "lie" that he is describing?

a) calm down

b) please read the article before complaining

I didn't get that desire for purity that you gleaned from it.

The fact is that (as the author pointed out) Golang is missing basic language features that other languages have adopted since the creation of C that eliminate whole classes of errors, and it's pretty easy to accidentally do the wrong thing as a result.

Nil pointer exceptions, for example, don't have to exist anymore.. and yet they do in Go because they couldn't be bothered to add sum types. Its type system is barely a step above a dynamic language. You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter). Every function that does meaningful work is littered with if err != nil { return err }. Etc.

It is easy to write code in Go, but IMO it's not easy to write and maintain a production grade system with any amount of complexity in Go because you _have_ to be careful, you can't encode invariants explicitly and let the compiler find problems for you, and you have to repeat yourself so often.

> What kinda gets me from this genre of post, is that it sounds like writing good software in any language besides Rust is impossible, or even impractical. Like 10 years ago it was impractical for anyone to enjoy writing good software. (Or maybe Haskell or Ocaml would be acceptable?)

I think what we are seeing here is that the expectations are growing and people demand more from their tools.

This is a good thing, even if some languages cannot keep up with the higher standards and fall behind.

This is the second day in a row where a post about Go _from the same blog_ has been posted. I think that's enough, especially since it's mostly a knee jerk reaction from that very HN post from yesterday.

https://news.ycombinator.com/item?id=31191700

To play devil's advocate: this author is known for often having a combative style. There's usually lots of good substance alongside that style, but the tone is what it is, and you could argue that it's needlessly incendiary. (Though in their defense, the post yesterday was self-described at the very top as "a proper rant")

HN is a powder keg of emotions about programming languages, and fasterthanlime's posts tend to be... shall we say, "sparky"

Could you link? I must have missed it.

I've written lots of python. Biggest codebase had ~100Ksloc of it.

I currently have a ~80Ksloc codebase in Go.

I like python. I dislike go.

I still hold the position that scaling a codebase is easier in go than in python.

* Goroutines + channels are generally easier for someone besides the author to reason about than their python equivalents, leading to a more consistency and better boundary definition.

* Python has a lot of magic in it - and that stuff is really cool, powerful and fun - but.. it also makes it incredibly easy to write stuff that works well together until it breaks in some wierd corner of a seemingly unrelated object somewhere.

* As python codebases grow, duck-typing becomes much less pleasant - you start seeing a bunch of `if isinstance(...)` in the code and eventually someone will come along and start implementing parts of a type system on top of the python code that exists (see also the previous point).

Those are the primary reasons for me, but there's also just a certain lack of friction in the go codebase (compared to python anyway) that I can't really describe well.

It only hurts because it's true.