It always plays out that way though.
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.
"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.
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?
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.
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
b) please read the article before complaining
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.
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.
'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?
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.
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.
The timing is a coincidence.
The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint.
It's been almost 24 hours since it was posted, a majority of posts are buried by then. The post seems to have followed a fairly normal lifecycle.
I am not a huge fan of the tone of the OP either, but it does have substantive content and discusses genuine issues (though it probably is not the best way to trigger discussion of those issues), some of which have bitten people at my workplace (dealing with bugs in two different very popular products written in Go, the kind of bugs that are simply not possible in other languages) in just the last week.
It would be interesting to see the response to a less inflammatory article discussing the same issues — I have noticed in general that criticism of Go is often badly received around here regardless of its tone.
No. Here's a post with much less upvotes, much less comments still on page 2: https://news.ycombinator.com/item?id=31205139
There are many other examples if you care to compare.
Meanwhile this post is nowhere to be seen because most conversation here is not up to HN standards.
Flagging is detrimental to post ranking. And rightfully so.
> Flagging is detrimental to post ranking. And rightfully so.
As I understand it, flagging is to get moderator attention to posts that don't follow the HN guidelines. It's not the general way to punish posts that upset you, that's called downvoting. Treating flags as a "stronger downvote" basically makes the very concept of flagging worthless.
There are multiple posts older than this one that are listed within the first 9 pages, some of them 2 days older even. While this one isn't.
Take a guess why :)
The flag was removed by moderators, but by then the algorithm already did its thing.
> Take that as a hint.
As a hint that sometimes you should do you research before making claims? Agreed.
> I read the content as lacking maturity, emotionally loaded
The article is perfectly fine, but what I gather from the reactions of Go fans is that they are lacking in maturity and become too emotional if their toy is criticized.
Something the author explicitly mentioned in his article. You should read it.
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.
"Users [flag] post as breaking the guidelines or otherwise not belonging on HN."
The fact that a small subset of the Go community is triggered by this post and can't behave in a civil manner isn't a reason to flag it.
That it isn't the most inflammatory commentary (even if one agrees with that, which is, of course, subjective) in the tech community doesn't mean that people assess that it “gratifies one's intellectual curiosity.” The latter, not the former, is the criteria for being on-topic at HN.
Naturally, people will disagree with what is within and outside of this boundary, and use flags or not accordingly.
Honestly I just hope @dang nukes this thread from orbit, and maybe it'll be posted again and get a cooler reaction from everybody.
Eh, unless there's evidence a submission is genuinely shitposting--i.e. trolling the community by being intentionally divisive while not actually believing what they're saying--or is outright offensive, I really don't agree.
Writing provocative critiques, like this, has been a standard in the tech world for as long as I can remember. If the rule is "don't post anything that runs the risk of upsetting someone", we'd have to ban half the leaders in the community, including Linus Torvalds.
So the worse the (Go) community behaves, the more careful authors have to be?
HN is a powder keg of emotions about programming languages, and fasterthanlime's posts tend to be... shall we say, "sparky"
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.
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.
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...
To those who do use Go: someone can call your baby ugly and you can still love it.