Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

261–270 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#261

Post by ploxiln »

mcluck wrote: 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…

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.

Re: Lies we tell ourselves to keep using Golang

#262

Post by dragonwriter »

BaseballPhysics wrote: post #248
sph wrote: post #242

Earlier quoted context omitted.

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

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.

> I've seen far more inflammatory commentary/criticism in the tech community over the years.

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.

Re: Lies we tell ourselves to keep using Golang

#263

Post by dang »

rmasters wrote: post #151

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…

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

HN has had plenty of threads about Go over the years. What's different here is that there was just a big Go flamewar yesterday (https://news.ycombinator.com/item?id=31191700), from the same site. Having another big Go flamewar the next day is a really bad idea, because then on top of shallow ragey flameposts (boo) the thread will fill up with fluffy ragey metaposts (double boo). More explanation here: https://news.ycombinator.com/item?id=31207126

"Shameful censorship" is one way to put it, but front page space is the scarcest resource that HN has (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...) and the amalgam of upvotes, flags, software weightings, and mod actions is what determines which stories end up / stay there vs. which stories fall off. This is the cycle of life on HN—it's always been that way and always will. One psychological effect is that everybody feels like their favorite topic is under-represented (or shamefully censored!) and in a way everybody is right.

I've often joked by adding "even Rust hackers feel that way" but maybe that's not the best line to use in this case :)

p.s. I feel like it's been a long time since HN had a passionate explosion about flagging and censorship (side note: ctrl+f misinformation...yup, that too) around a programming language. In a way it feels like a healthy sign. Like a family fight at Thanksgiving - at least it's about, say, a board game or something.

Re: Lies we tell ourselves to keep using Golang

#264

Post by victoryhb »

xiphias2 wrote: post #201
victoryhb wrote: post #184

Earlier quoted context omitted.

So the reason for the censorship is they read the entire article and saw nothing "new" about something you "all know is true"? That's indeed a "new" way to discourage reasoned discussions.

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.

Re: Lies we tell ourselves to keep using Golang

#265

Post by conradludgate »

busterarm wrote: post #150
adhoc_slime wrote: post #48

Earlier quoted context omitted.

This has perhaps been my biggest pain-point with Golang.. Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc. if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.

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.

I'm interested if you could elaborate on that?

My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo

Re: Lies we tell ourselves to keep using Golang

#266

Post by frou_dh »

kgeist wrote: post #209

We have tens of microservices written in Go. Go is good for onboarding new devs because it's simple. Our existing PHP devs were taught Go and it was painless. Jumping from PHP straight into Rust would be pretty painful, I think. Finding Rust devs isn't easy in our town. But I agree with most of the points. You got to be very careful when writing in Go, because there are many gotchas. So many gotchas that I had to wri…

That means Go was easy for those devs to pick up, not that Go is simple.

Rich Hickey gave an all time classic presentation about this seemingly nitpicky but important distinction https://www.youtube.com/watch?v=SxdOUGdseq4

Re: Lies we tell ourselves to keep using Golang

#267

Post by busterarm »

Thaxll wrote: post #174
busterarm wrote: post #117

Earlier quoted context omitted.

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of dev…

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

The author of the blog post literally covered it in the article he wrote two years prior that's linked in the first sentence.

It's not "TCP issues in Go" it's "Go leaves you to figure these things out for yourself and write bad code that doesn't work if you don't thoroughly understand its gotchas."

Also, if you've been following Go over the years, you'll know that there's basically _always_ open issues (https://github.com/golang/go/issues/39063) in net & net/http about how Timeouts get mishandled and connections end up not being closed.

Cloudflare even had to write a whole (now old and outdated as hell) article explaining how to "do it properly" https://blog.cloudflare.com/the-complete-guide-to-golang-net... so that you don't footgun yourself.

Re: Lies we tell ourselves to keep using Golang

#268

Post by icholy »

HL33tibCe7 wrote: post #98

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…

The content is mostly ok, but the title suggests that there's some obvious alternative to Go that we should be using. If he's implying it's Rust, then he's totally disconnected from reality.

Re: Lies we tell ourselves to keep using Golang

#269

Post by guipsp »

vbezhenar wrote: post #246
noisy_boy wrote: post #234

Earlier quoted context omitted.

> Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boile…

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

Spring boot is not, in any way shape or form, a "simple" java "library". Not only is it a complex framework, it also uses features very few java programmers are exposed to, such as runtime code generation.

Re: Lies we tell ourselves to keep using Golang

#270

Post by ak217 »

SeanLuke wrote: post #27

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

Without operator overloading, it is basically impossible to adapt a language for numerical computing/data science applications. Yeah, operator overloading is a powerful tool that's easy to abuse; no, it's not optional if you want the language to succeed at all in a whole bunch of applications.
Post reply on HN