Lies we tell ourselves to keep using Golang • Hacker News Board

Re: Lies we tell ourselves to keep using Golang

#401

Post by dang » Fri, Apr 29, 2022, 10:56 PM UTC

mumblemumble wrote: post #389

dang wrote: post #381

Earlier quoted context omitted.

I don't have the impression that interesting technical discussion about Go has been particularly scarce on HN over the years? But if you think that today's thread is different enough from yesterday's thread to be significantly higher-quality and not just generic (i.e. about something specifically interesting in the OP, rather than just another generic discussion of Go, even if it's a good generic discussion of Go), t…

If you'll excuse me for not taking the time to gather hyperlinks, I think just scrolling down would suffice. Basically any of the next-most-highly-ranked top-level comments seem like decent candidates to me.

It's not clear to me that the discussion isn't still rather generic, but ok - if you or someone else wants to suggest an accurate, neutral, non-flamebaity title, we can give this thread a second chance.

Re: Lies we tell ourselves to keep using Golang

#402

Post by andai » Fri, Apr 29, 2022, 11:00 PM UTC

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…

I was struck by ThePrimeagen[0] saying that it took him 5x longer to write a game server in Rust than in Go—despite having significantly more Rust experience. They performed about the same (I think Go actually did better due to how much easier it was to get concurrency working?).

Personally I lean towards strict compilers (I suppose years of JavaScript has traumatized me), but 5x dev time is a big tradeoff! Of course this is just one data point, but it did seem worth mentioning.

[0] - https://www.youtube.com/watch?v=Z0GX2mTUtfo

Re: Lies we tell ourselves to keep using Golang

#403

Post by fasterthanlime » Fri, Apr 29, 2022, 11:10 PM UTC

pvg wrote: post #358

fasterthanlime wrote: post #329

Earlier quoted context omitted.

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

There's nothing I can say about "this is not actually the same article" and "the two comment sections do not say the same thing at all" that hasn't already been said by many other HN users in response to this moderation thread, so, I'll leave it there, still disappointed.

Re: Lies we tell ourselves to keep using Golang

#404

Post by ay » Fri, Apr 29, 2022, 11:35 PM UTC

andai wrote: post #402

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…

I was struck by ThePrimeagen[0] saying that it took him 5x longer to write a game server in Rust than in Go—despite having significantly more Rust experience. They performed about the same (I think Go actually did better due to how much easier it was to get concurrency working?). Personally I lean towards strict compilers (I suppose years of JavaScript has traumatized me), but 5x dev time is a big tradeoff! Of course…

My experience in writing a small side project in both (on the order of 2-3 KLOC) was that the time to a working project is significantly shorter with golang. The time to the correctly working project was about the same between the two.

Golang gets out of the way in me doing what I want.

Rust actively resists me doing things I will later regret.

Also, unexpectedly, I have gotten some positive comments on my C coding style after I coded some Rust.

All of this is completely anecdotal and personal experience, of course.

Re: Lies we tell ourselves to keep using Golang

#405

Post by EdwardDiego » Fri, Apr 29, 2022, 11:36 PM UTC

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…

Haha, your comment on the weird date formatting rings very true.

Re: Lies we tell ourselves to keep using Golang

#406

Post by NIckGeek » Sat, Apr 30, 2022, 12:06 AM UTC

kretaceous wrote: post #304

streblo wrote: post #56

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been produ…

As a beginner learning Go for the past 3 weeks, thanks for the last paragraph. I was looking into a new language to learn outside of JS and Python. I wanted to learn a hot language. I did some digging between Rust and Go and found out that Go is more suitable for web backends, CLI apps, etc. while Rust was more of a contender to C/C++, as it was primarily was made to be used as a memory-safe, correct, strict language…

Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc.

A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, reference counted) and not worry about any of the low level memory management details.

See things like https://ggez.rs/ for games and https://www.arewewebyet.org/ for web stuff.

Although honestly I think if you're looking for a "hot" backend web language I'd say Elixir is the more well designed one than Go.

Re: Lies we tell ourselves to keep using Golang

#407

Post by mumblemumble » Sat, Apr 30, 2022, 12:35 AM UTC

pvg wrote: post #392

mumblemumble wrote: post #387

Earlier quoted context omitted.

I don't see how one can say that this ends up being a straightforward dupe, unless you're just observing that it's criticism of Go by the same author and with a similarly provocative title. I admittedly haven't read "Mr Golang's Wild Ride" since it first hit HN a couple years ago (and I don't really intend to, I have my doubts that it would be an edifying use of my time) but, based on what I remember of it, this new…

I think you're getting somewhat hung up on the content of the piece and the moderation in this case doesn't have much to do with it. Critique pieces of popular languages are themselves popular and get frequent and regular coverage on HN. This one had one significant discussion yesterday, last year and also the year it was published. That's a pretty good run and it will undoubtedly appear again, along with its update.…

No, I'm more saying that the treatment of this article, and dang's explanation for it, seems to suggest a weirdly arbitrary and paternalistic mindset on the subject.

I'm not sure what "weirdly hung up on the content of the piece" is supposed to mean. Isn't the whole point of Hacker News to share and discuss interesting content? If it's not about digging into full, long-form content, then we might as well take this to Twitter.

I'm also not sure what you mean by "this one had significant discussion yesterday, last year, and also the year it was published." The article was posted on Friday, April 29, 2022 - today, to be precise.

Re: Lies we tell ourselves to keep using Golang

#408

Post by b3morales » Sat, Apr 30, 2022, 12:53 AM UTC

pvg wrote: post #392

mumblemumble wrote: post #387

Earlier quoted context omitted.

I don't see how one can say that this ends up being a straightforward dupe, unless you're just observing that it's criticism of Go by the same author and with a similarly provocative title. I admittedly haven't read "Mr Golang's Wild Ride" since it first hit HN a couple years ago (and I don't really intend to, I have my doubts that it would be an edifying use of my time) but, based on what I remember of it, this new…

I think you're getting somewhat hung up on the content of the piece and the moderation in this case doesn't have much to do with it. Critique pieces of popular languages are themselves popular and get frequent and regular coverage on HN. This one had one significant discussion yesterday, last year and also the year it was published. That's a pretty good run and it will undoubtedly appear again, along with its update.…

I really don't see how "two critical articles about a particular programming language on consecutive days are flamebait and detrimental to the site" can be squared with the handling of US political and COVID articles over the last two-three years. Programming content should be the bread and butter of the site, and popular language critique is par for the course on any hacker-themed board. And tomorrow we'll have moved on to something else, unlike the other topics I mentioned.

Re: Lies we tell ourselves to keep using Golang

#409

Post by Mawr » Sat, Apr 30, 2022, 12:55 AM UTC

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…

> 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

Re: Lies we tell ourselves to keep using Golang

#410

Post by mumblemumble » Sat, Apr 30, 2022, 1:05 AM UTC

kaba0 wrote: post #379

j3s wrote: post #361

Earlier quoted context omitted.

> If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine. as the person on call for such events, it's really not fine. would you rather handle these errors upfront during development time or unexpectedly and uncontrollably, during runtime? having been on-call in one way or another for ~10 years, i know which i'd prefer. after having used golang in p…

It’s a big assumption that you can even handle the error at the callsite, or that you will actually handle it correctly there, or just write some low-effort attempt because the overall picture is more important for now, but later on you won’t notice how it is not correct and it will just silently fail. Exceptions are in my honest opinion better on every single front. Checked exceptions would be the panacea but Java’s…

For reliability, the absolute best discipline I've ever experienced, is "Either handle the error at (or very close to) the callsite, or crash the process." But only if you make sure that everyone on the team understands that (A) this is the only way to do it, and (B) there is no other way to do it, and (C) you will do it no other way.

I think because it sets up the right psychological incentives. Because almost any option other than those two ends up looking like, "Hmm, I don't know how to handle this, but maybe someone else will, so let's bubble it up and hope they do," in practice. It's just the way we humans are.

And that sets up an intractable moral hazard situation. It creates this middle ground where two different owners of two different parts of the code can finger-point and blame and try to pass the buck. And, knowing that (though probably only unconsciously), they won't just become sloppier about handling errors. They will become sloppier about allowing errors to happen in the first place, and doing things that make it harder to handle errors. And they won't even know they're doing it.

That's what I think of when I read your hypothetical, "Let’s say you want to read from a file during a HTTP request but the read fails n methods deep." That sounds to me like code that's been structured in a way that, on this team I was alluding to above, probably wouldn't have happened in the first place and definitely wouldn't have made it past code review. The pushback would be something along the lines of, "Why on earth are you doing both file and network I/O within a single business operation but at two very different depths in the call stack? Did you even notice what you were doing here?"