Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

271–280 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#271
post #14

Earlier quoted context omitted.

The last time his "I want off" article was reposted[0], the comments were pretty rough, ranging from ad-hom attacks to (at best) misunderstandings of the arguments he was making. I see this article being an address to these criticisms (which are not limited to this forum, I've seen similar arguments on twitter, etc.). Pointing out shortcomings isn't really impolite or unfair. The author specifically mentioned shortco…

Pointing out shortcomings isn't impolite - writing that Go wasn't designed, but happened by accident is however (IMHO).

Especially since it was designed by computer science luminaries who are almost certainly better programmers/engineers than the author of this blog.

It's also more accurate to say that Rust wasn't designed / was an accident since it was technically a side project of one guy at Mozilla.

Re: Lies we tell ourselves to keep using Golang

#272

Earlier quoted context omitted.

>read from multiple queues at the same time Agreed, and things happening "at the same time" are possible only with parallelism. Hence my question =)

I interpreted "at the same time" as "without blocking", But sure you could also add parallelism using a few built-in Node modules (there's cluster and worker threads, also don't know if atomics are already in Node, they are in V8), It's not trivial anymore but also not that hard. A newcomer could figure it out in ~30 mins from the docs.

Gotcha, sounds like we interpreted it differently. I appreciate you taking the time to clarify, I am an old hand as JS but didn't know true parallelism had become feasible these days. Thank you, sincerely!

Re: Lies we tell ourselves to keep using Golang

#273
post #251

Earlier quoted context omitted.

I've seen far more inflammatory commentary/criticism in the tech community over the years. This post is honestly pretty mild if you look at it objectively. 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.

Can we do without the finger pointing as well? I am not part of the Go community, and I would prefer not seeing any reaction posts and divisive opinion pieces on this forum, whatever the language or topic. Honestly I just hope @dang nukes this thread from orbit, and maybe it'll be posted again and get a cooler reaction from everybody.

> I would prefer not seeing any reaction posts and divisive opinion pieces on this forum, whatever the language or topic.

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.

Re: Lies we tell ourselves to keep using Golang

#274
The recent paper from Go core devs, "The GO PL and its Environment" highlights that a major aspect of Go is its environment/ecosystem, from the very start.

But the OP, in either article, zeroes in on narrow language/STL design choices and never zooms out to consider the ecosystem and how Go works in an actual software engineering team. Pardon the vulgar analogy, but this is like zooming in on a dog's asshole and going "what the fuck is this? It looks gross and shit comes out" without considering that it is an integral part of a well-functioning whole.

It all comes down to misunderstanding each other's positions.

Re: Lies we tell ourselves to keep using Golang

#275
I'm just a simple dev in a 3-man team building an app and a back-end to go with it. Our company is default dead. Maybe some day I will regret choosing Go for our back-end. But right now it is the right balance of scalability, easy async, good tooling, great back-end infrastructure (Google App Engine and Firestore) and productivity.

I read articles like this, and think to myself ... some future CTO will curse my choices today. But then I feel that future CTO will curse any choices I make, and it won't be fair for her to curse my choices ... because I'm just trying to get us from default dead to default alive without running out of the small amount of money we raised.

Rust is absolutely not an option for us. We don't have the skills or time to write a Rust backend right now.

Re: Lies we tell ourselves to keep using Golang

#276
post #243
post #105

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…

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 a…

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

Re: Lies we tell ourselves to keep using Golang

#277

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…

> "Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever."

I think this is going to change. I couldn't find the relevant blog post now, but I believe to remember there was an initiative to provide a standard async runtime.

Re: Lies we tell ourselves to keep using Golang

#278

Earlier quoted context omitted.

Dang explained it many times, that HN is optimized for interesting things instead of just reasonable discussions, particularly if they are repetitive / predictable. Also it's not a ,,new'' way to discourage reasoned discussions, it was already like that when you decided to join HN in 2016.

So you have nothing "new" to say after all, but repeating what "everyone" should know already. HN should now censor your comment.

I didn't post this. Posts and comments have different criteria.

But if I would be censored, that's OK, it happened multiple times before, but I still prefer it compared to other web forums, because I deserved it.

Re: Lies we tell ourselves to keep using Golang

#279
post #243

Earlier quoted context omitted.

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 a…

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

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.

Re: Lies we tell ourselves to keep using Golang

#280

Flagging this post strikes me as shameful censorship of an unpopular opinion. You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. Presuming the author is making bad-faith arguments for internet blog points goes against the spirit of HN. I prefer to draw my own conclusions, thank you. I normally expect HN to take the higher ground wit…

I am also surprised that a reasoned discussion like this gets flagged while comments calling it a "shitpost" are not.

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.
Post reply on HN