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

351–360 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#351

Post by cytzol »

Thaxll wrote: post #347
cytzol wrote: post #229

Earlier quoted context omitted.

> Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. I agree with this. I learnt Rust before Go, and using Go makes me feel like The Oatmeal piracy guy[1]: "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 comprehensi…

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

Sorry, I don't get what you mean. Could you elaborate or re-phrase?

Re: Lies we tell ourselves to keep using Golang

#352

Post by blippage »

cytzol wrote: post #229
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…

> Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. I agree with this. I learnt Rust before Go, and using Go makes me feel like The Oatmeal piracy guy[1]: "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 comprehensi…

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

Re: Lies we tell ourselves to keep using Golang

#353

Post by lenkite »

yen223 wrote: post #92
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.

Golang has the most hilarious approach to date formatting

Lol, I thought it was some sort of Joke when I first learnt it. And kept hunting for the 'proper' way. When I realised this was serious, I banged my head against the wall.

Re: Lies we tell ourselves to keep using Golang

#354

Post by lenkite »

busterarm wrote: post #267
Thaxll wrote: post #174

Earlier quoted context omitted.

"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://gith…

They really need to add a deprecation note to the default http server and client. I have seen SO many people trip over this.

Re: Lies we tell ourselves to keep using Golang

#355

Post by Thaxll »

cytzol wrote: post #351
Thaxll wrote: post #347

Earlier quoted context omitted.

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

Sorry, I don't get what you mean. Could you elaborate or re-phrase?

None of the modern and popular language have immutability, compiler enforced thread safety, powerful type ( debatable ), same for nil...

Java / C# / Python / Ruby so they fall in the same bucket as Go I assume?

Re: Lies we tell ourselves to keep using Golang

#356

Post by Thaxll »

adhoc_slime wrote: post #48
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

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.

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

Re: Lies we tell ourselves to keep using Golang

#357

Post by mumblemumble »

dang wrote: post #263
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 t…

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

Re: Lies we tell ourselves to keep using Golang

#358

Post by pvg »

fasterthanlime wrote: post #329
dang wrote: post #284

Earlier quoted context omitted.

Yes. The problem here is that there was a big one of those just yesterday. HN does poorly with repetition, and throwing in the indignation aspect and the meta aspect (can you believe what an HN commenter said yesterday? the nerve!) guarantees that the thread will get high and go crazy. None of that is intentional, but it's a well-known failure mode, so the flags in this case were helpful. We've taken the [flagged] st…

> We've taken the [flagged] stigma off the title above, so as not to rub salt in any wounds. Sending it to page 2 when it's only 3 hours old and has more upvotes than almost everything on page 1 /and/ removing the [flagged] marker feels weirder to me than not doing anything, but eh.

The ranking aims for interestingneses, not points so it makes sense to rank down a discussion of the merits Go a day after the front page has had a long discussion of the merits of Go. Taking off the flagged helps with the 'why was this flagged' meta (a little late now but still) since fewer people assume there is something wrong with the post, other than it happening to be a dupe on HN.

Re: Lies we tell ourselves to keep using Golang

#359

Post by formerly_proven »

yegle wrote: post #121
14113 wrote: post #65

Earlier quoted context omitted.

From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."

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.

IME there are sort of two kinds of people here. People who are "fans" and defend "their" toy and people who don't. For example, I've been using Python for a very long time. I'm a "Senior Python Developer" so to speak. I quite like it for various purposes, but I can also talk your ear off about problems with Python.

I'd say if you run into someone who says they're experienced with X or love X etc., but they can't give criticism of it, they're most likely either not that experienced with X, or fanboys.

Re: Lies we tell ourselves to keep using Golang

#360

Post by Thaxll »

Diggsey wrote: post #258
Thaxll wrote: post #174

Earlier quoted context omitted.

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

> You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.

I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
Post reply on HN