[mcluck]

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how those who have bought in to Go may not want to hear what they're saying and it's right. No one wants to hear that their baby is ugly but sometimes it's the truth.

To those who do use Go: someone can call your baby ugly and you can still love it.

[BaseballPhysics]

I couldn't agree more. Some of the comments on this post are way out of line, straying into personal attacks on the author or their intentions. It's clearly touched a nerve and the reaction seems wildly out of proportion to the content.

[busterarm]

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.

[jhugo]

One thing to consider is that there is now a lot of Go out there, especially in the ops world thanks to k8s, Terraform, etc. A lot of people have put a lot of effort into learning it, and may have even built their career around it. So it's not surprising (even if it's a little sad) that people react very strongly to criticism of it. You sometimes see similar reactions to criticism of JS.

Just this week I've been dealing with a random crash when we run `terraform plan` which turned out to be a data race in Terraform itself. I honestly can't understand why something like Terraform, dealing with critical infrastructure, secrets, etc, would be built in a language like Go, apart from that all the other ops-adjacent stuff was being built in Go. The discussion in TFA about not selecting your tools solely based on what other companies are using is cogent.

[Thaxll]

When the author make such claim:

"It may well be that Go is not adequate for production services unless"

Who is exactly the author to tell us to not use a language that was proven to be just fine and successful. What actually OP shipped in production to be able to make such claim? Does it means also that Java / C# / Python, Ruby ect have the same fate since they're not up to part with Rust?

Kubernetes is everywhere and is built 100% in Go, it solves real complex issues, so was Go the wrong choice for it?

You can find many tools built in Go that are used by pretty much every compagnies now days, was Go the wrong language for those tools as well? Kuberentes, Docker, Grafana, Prometheus, esbuild etc ... the list is actually long.

Yes Go is not a perfect language, but saying that you should not use it production where the last 10years has shown that it deliver value is wrong.

[rglullis]

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

[Thaxll]

I gave example of very successful tool used, Kubernetes works fine, did you ever heard about Kuberentes gone bad or full of bug or unusable? It's very stable and it's used by millions of people.

[rglullis]

> Kubernetes works fine

At what cost? How many man-hours did it take? How many bugs could have been avoided? How much faster could it be done with other languages? Most importantly: if Google stops backing its development, who else could replace it?

Redis/SQLite are written in C, and it is also used by millions of people. They are also not known to be bad or full of bugs. You don't see that being used as an argument to claim that C is an "adequate" language for most people nowadays.

And if you did see anyone using that argument, we probably would say that this is just a lie they tell themselves to keep using C.

[VMtest]

> At what cost? How many man-hours did it take? How many bugs could have been avoided? How much faster could it be done with other languages? Most importantly: if Google stops backing its development, who else could replace it?

Same question can be asked when Rust or C/C++ are being used to write k8s

> And if you did see anyone using that argument, we probably would say that this is just a lie they tell themselves to keep using C.

A bad programmer is a bad programmer. If all you have is a hammer, everything looks like a nail

People who did read this article should be aware of the shortcomings of Golang by now, and some of them will still be using it, and I am very sure of that

[oxnrtr]

a) calm down

b) please read the article before complaining

[ploxiln]

Let's not pretend that some flagging of this article represents all or most developers who use Go, and also not pretend that this post represents all or most developers who use Rust.

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've written a fair bit of Go, lots of Python and C, lots of bash and posix sh ... and I've written good and reliable-for-purpose software in all these languages, and I've enjoyed it much of the time. (In college I also wrote a chess playing engine in java, a malloc implementation and a trivial unix-like OS kernel with fork and threads in C of course, also a mips and z80 cpu implementation in verilog for fpga ... does that make me a "blub" programmer?)

Is it really an unacceptable flaw to have a program that only works with printable paths, and only makes sense to run on one's own files? Or which runs fine on both unix and windows, but doesn't do anything with file permissions? Or which only operates on file permissions on unix, but only runs on our servers and VMs?

I like high quality software, I really do. But I think that people writing these blog posts want something more, something impossibly pure. They want a messiah, and if everyone just believed, the world would be perfect. I like high quality software which has been possible and practical for 20+ years.

[thatswrong0]

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.

[Mawr]

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

'Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions.'

This mutability argument is present throughout the article. Seems like nothing sans Rust or niche functional languages is enough.

> Nil pointer exceptions, for example, don't have to exist anymore..

The language most notorious for those is Java due to almost everything being passed via a nullable reference. When everything can be nullable, how can you know where to check for it? Go addresses this to an extent by explicitly separating pointers from values. Values are the default and cannot be nil, so the opportunity for null dereferences is greatly diminished. It's not a perfect solution, but it's not nothing either.

> and yet they do in Go because they couldn't be bothered to add sum types.

Damn those lazy Go devs!

> Its type system is barely a step above a dynamic language.

Turns out even a basic type system is a huge improvement over none. Just being able to restrict values to concrete types goes a long way.

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

There are arguments to be made either way, but I definitely agree generics (along with iterators) should have been there since day 1.

> Every function that does meaningful work is littered with if err != nil { return err }.

One big positive of this that I don't see in other languages is every `return` in a function must be on the start of a line. That is, every single exit path of a function is easily findable by visually scanning the start of each line for `return`.

> you can't encode invariants explicitly

I'm curious, are there any limitations here besides enums/sum types?

[oxnrtr]

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

[gjsman-1000]

This is the second day in a row where a post about Go in a negative light was flagged. The first one was an extremely detailed criticism, maintained the front page, and was flagged like crazy. What gives?

[sph]

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

[BaseballPhysics]

> This is the second day in a row where a post about Go _from the same blog_ has been posted.

Unless you consider this post either spam or off topic (and I personally don't believe it falls into either category), then flagging the post is not in keeping with my understanding of the site guidelines.

Just don't upvote it.

[ackfoobar]

This post is (sort-of) a response to yesterday's discussion. I think it's fair to post it today.

[stickfigure]

No sort-of about it. The author directly quotes from yesterday's HN discussion. It's a continuation of the dialogue.

[oxnrtr]

The article is over two years old and posted by random people regularly.

The timing is a coincidence.

[sph]

The author is active on HN, he was active on yesterday's thread. Shall we post tomorrow's response as well?

[jhugo]

Anyone can post it if they want to. If it gets enough upvotes it will be on the front page for a while, just like this one...

[hu3]

And users are free to flag if they deem the content spammy.

[gjsman-1000]

Who cares if it is a legitimate criticism and makes unique points in both cases (also, they were both written two years apart!)? Some call it "inflammatory" but it has scientific and critical value nonetheless.

[dragonwriter]

> Who cares if it is a legitimate criticism and makes unique points in both cases?

Clearly, the people flagging it care, whether because they disagree with your assessment of it providing legitimate criticism and unique points in both cases, or because they think some other quality it has outweighs that in assessing it against the bar for belonging on HN.

> Some call it "inflammatory" but it has scientific and critical value nonetheless.

Value is subjective and people clearly disagree with you on this point.

[gjsman-1000]

If you find it does not have value to you, don't upvote it and ignore it. Don't flag it to try to hide it from people who it may have value for. It's clearly not spam, so it's not your job to determine whether it has value for other people.

[sph]

Flagging posts that would not fit on HN or would just cause pointless flamewars is acceptable. Given the state of this thread, I think it's even more justified.

"Users [flag] post as breaking the guidelines or otherwise not belonging on HN."

https://news.ycombinator.com/newsfaq.html

[whimsicalism]

What makes a reaction knee jerk? Is it just not liking it?

[brundolf]

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"

[gjsman-1000]

But that is literally one of the oldest logical fallacies in the book - Ad Homenem - defined as "(of an argument or reaction) directed against a person rather than the position they are maintaining."

[brundolf]

I'm not saying people were right to react this way, I'm just explaining.

[eatonphil]

Could you link? I must have missed it.

[gjsman-1000]

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

[eatonphil]

Ah OK just the author's 2020 post. Thanks!

[bayesian_horse]

Many people say Go is a better language to scale a codebase than Python, mainly because of typing, but I really doubt it. I can't tell for sure, because I haven't done a lot of Go coding. But to me the stated problems and the general lower-level nature suggest a productivity loss compared to Python, on average.

[sophacles]

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.

[bayesian_horse]

For me it is hard to attribute such differences to a programming language rather than the people creating and maintaining the code.

At the moment I am maintaining a C# codebase which doesn't feel maintainable at all, and I don't think C# is the only problem there.

[Mawr]

> This article was, yes, a little aggressive in tone

A little?

"[...] but I remember fondly the time an audience member asked the Go team "why did you choose to ignore any research about type systems since the 1970s"?"

"Unless you're out for confirmation bias, that whole article is a very compelling argument against using Go for that specific problem."

"[...] and tooling that would make C developers jealous, if they bothered looking outside their bubble."

"[...] and most importantly, you adopted a language that happened by accident."

"Evidently, the Go team didn't want to design a language. [...] "And so they didn't. They didn't design a language. It sorta just "happened"."

"And breaking down an argument to its smallest pieces, rebutting them one by one, is a self-defense tactic used by those who cannot afford to adjust their position in the slightest. "

"We've reached the fifth stage of grief: acceptance."

"Because it has been decided that abstractions are for academics and fools [...]"

> [...] but presented very honest and accurate information about a language that the author clearly has experience in.

It's biased flamebait, just like the original article.

> It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how those who have bought in to Go may not want to hear what they're saying and it's right. No one wants to hear that their baby is ugly but sometimes it's the truth.

>

> To those who do use Go: someone can call your baby ugly and you can still love it.

Sure, I'd love to read such a well-considered article. Please link any you know of below.

Here's an exemplary article that managed to criticize Go without evoking a flamewar ([1]): https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...

I pose that if you present valid arguments in a reasonable, intellectually-curious way, people will respond positively. But if you set out on a holy war instead, well...

[1]: https://news.ycombinator.com/item?id=29494136

[oxnrtr]

It only hurts because it's true.

[yjftsjthsd-h]

Sure, the baby is ugly. That's perfectly fine. The problem is when you continuously insist that the only reason anybody could ever love the baby is because they're delusional and in denial.

[zozbot234]

To put it shortly, the tone is so pointlessly aggressive that it obscures what accurate information the post contains. The information itself is also presented in a haphazard manner, seemingly chosen to maximize the critical intention as opposed to clarifying things for the reader. Some info that would be potentially valuable to the reader is simply not there, purely because it doesn't fit the "bad Golang!" overall emphasis of this post. E.g. what about pointing at newer novice-friendly prototyping languages with a better FFI story than Go? There's quite a few of them: Nim, Crystal, the new language Hare etc. But you won't find any serious mention of them here, or any comparison of their benefits and drawbacks.