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

421–430 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#421

Post by pvg »

b3morales wrote: post #408
pvg wrote: post #392

Earlier quoted context omitted.

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

two critical articles about a particular programming language on consecutive days are flamebait and detrimental to the site

I'm not sure who you're quoting here but it's not me.

US political and COVID articles

These also get moderated quite a bit but it's a little different with ongoing hot topics - many more submissions, angles, etc. One person's take on Go, however interesting, is not an ongoing hot topic. Plus it's had a pretty good life on the site!

Re: Lies we tell ourselves to keep using Golang

#422

Post by mumblemumble »

pvg wrote: post #420
mumblemumble wrote: post #407

Earlier quoted context omitted.

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…

What I mean is that you can figure out the logic of this kind of moderation without litigating the quality of the pieces submitted. As to the 'significant discussion' bit, it's basically the same article - the first article has had multiple big discussions on HN. The second article is a response to the most recent such discussion, from yesterday. It's also framed, in some ways, as a direct response to people who said…

But at this point, we're no longer debating whether TFA is "a dupe fairly straightforwardly"; you've now moved the goalpost quite far from where we started.

Perhaps you didn't personally get much out of the article. I did. I didn't love the invective aspects of it very much, either, but there were still some interesting take-aways and new things to say. Apparently enough so that 593 people so far thought it worthwhile to click the "upvote" button, which is really quite a staggering number when you consider that it had been banished from the front page. When you've got that many people seeing value in it - that's really quite a lot more than most of the rest of what's been on HN today - even if you don't personally see why, maybe it's enough for you to simply not see why, and leave it at that.

And that is what I am getting at. I can see the logic of the moderation just fine, but I think that the logic in question is wrong and perhaps even edging toward paternalistic or mean-spirited. And my interactions with dang on it elsewhere in the thread strike me as being mostly just defensive. Which doesn't really jive all that well with the stated purpose of elevating the quality of conversation on HN. I'm more impressed with what the broader community has done: largely looking past the flamebait, eschewing "shallow dismissals", and instead choosing to "respond to the strongest plausible interpretation of what someone says."

Re: Lies we tell ourselves to keep using Golang

#423

Post by imran0 »

aidaman wrote: post #412
Thaxll wrote: post #355

Earlier quoted context omitted.

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?

Does Javascript not exist?

When talking about language design, it's the first one to be kicked out.

Re: Lies we tell ourselves to keep using Golang

#424

Post by pvg »

mumblemumble wrote: post #422
pvg wrote: post #420

Earlier quoted context omitted.

What I mean is that you can figure out the logic of this kind of moderation without litigating the quality of the pieces submitted. As to the 'significant discussion' bit, it's basically the same article - the first article has had multiple big discussions on HN. The second article is a response to the most recent such discussion, from yesterday. It's also framed, in some ways, as a direct response to people who said…

But at this point, we're no longer debating whether TFA is "a dupe fairly straightforwardly"; you've now moved the goalpost quite far from where we started. Perhaps you didn't personally get much out of the article. I did. I didn't love the invective aspects of it very much, either, but there were still some interesting take-aways and new things to say. Apparently enough so that 593 people so far thought it worthwhil…

you've now moved the goalpost quite far from where we started

I don't follow. You weren't familiar with the rules of HN dupery and I've tried to explain them. That's not moving the goalposts. Followups are almost always dupes. Metaish follow-ups the very next day dupely so.

Re: Lies we tell ourselves to keep using Golang

#425

Post by mumblemumble »

dylanowen wrote: post #419
Thaxll wrote: post #355

Earlier quoted context omitted.

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?

Java has immutability and more powerful types than go. Also considering how easy it is to intermix jvm languages you could add in scala or kotlin for truly powerful type systems without null.

I've grown a little disgruntled by the hype surrounding Scala's and Kotlin's null handling.

For starters "without null" is a myth. They both have null. They have to; there is no other practical option. The JDK uses null all over the place, so you need to have null in order to talk to the JDK.

Now, they do still have mechanism to make null easier to handle. And they're both pretty impressive designs. (Especially Kotlin's, though I haven't tried Scala 3 yet so maybe I'm missing something wonderful there. Aesthetically, I just prefer "we're going to openly acknowledge it and tame it as much as we can" over "we're going to try to sweep it under the carpet.") But there's a sort of Amdahl's Law analogue hiding in that situation: the upper bound on how much practical null safety you can achieve is constrained by how much you can avoid relying on modules that were written in Java. And I know that's basically true of languages like Haskell, too, because you often have to rely on at least a little bit of code that was written in languages like C. But it doesn't preoccupy me the same way it does in Scala or Kotlin, where interacting directly with Java code is a much more everyday kind of affair.

Re: Lies we tell ourselves to keep using Golang

#426

Post by pensatoio »

I don't understand all the attention these articles are getting. If you don't like it, stop using it. Why are you going to so much effort to complain?

You can write bad code in any language. You can write difficult to read code in any language. Every language has pitfalls and downsides.

Personally, I work in golang full time, and I adore it. Development is painless, and our codebase feels very easy to read.

Re: Lies we tell ourselves to keep using Golang

#427

Post by mumblemumble »

pvg wrote: post #424
mumblemumble wrote: post #422

Earlier quoted context omitted.

But at this point, we're no longer debating whether TFA is "a dupe fairly straightforwardly"; you've now moved the goalpost quite far from where we started. Perhaps you didn't personally get much out of the article. I did. I didn't love the invective aspects of it very much, either, but there were still some interesting take-aways and new things to say. Apparently enough so that 593 people so far thought it worthwhil…

you've now moved the goalpost quite far from where we started I don't follow. You weren't familiar with the rules of HN dupery and I've tried to explain them. That's not moving the goalposts. Followups are almost always dupes. Metaish follow-ups the very next day dupely so.

A rule and its implementation are two separate matters.

With all due credit to rmasters, "I suspect it would not have been flagged if the topic were different."

Re: Lies we tell ourselves to keep using Golang

#428

Post by pvg »

fasterthanlime wrote: post #403
pvg wrote: post #358

Earlier quoted context omitted.

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.

I haven't read them all and it's not wrong that they aren't the same article or the same discussion but it's HN-wrong. It's definitely disappointing if you have a big J. Winnfieldean 'allow me to retort' lined up but it works that way for pretty decent, time-tested reasons which I think have also been explained in great detail in the various moderation parables and proverbs.

Re: Lies we tell ourselves to keep using Golang

#429

Post by pvg »

mumblemumble wrote: post #427
pvg wrote: post #424

Earlier quoted context omitted.

you've now moved the goalpost quite far from where we started I don't follow. You weren't familiar with the rules of HN dupery and I've tried to explain them. That's not moving the goalposts. Followups are almost always dupes. Metaish follow-ups the very next day dupely so.

A rule and its implementation are two separate matters. With all due credit to rmasters, "I suspect it would not have been flagged if the topic were different."

Well, yeah, that's your suspicion but it is not an argument, it's just a suspicion that something nefarious is going on. I don't think you've really responded to any of the explanations of why HN works this way. That doesn't mean the way HN works is right but you have to bring something more to it than aspersions if you want to argue for change.

Re: Lies we tell ourselves to keep using Golang

#430

Post by mumblemumble »

boulos wrote: post #400
kaba0 wrote: post #385

Earlier quoted context omitted.

What I don’t generally get is why Go when there is Java already? Like other than the somewhat smaller memory footprint that is not inherent to the language, but the runtime — in what way is Go better that could not have been a Java library? Hell, with Google’s resources one other GC/mode could be added to OpenJDK that prioritizes memory footprint (at the expensive of throughput - there is no free lunch). Sure, Java h…

There are a few things, mostly due to the runtimes but also because the JVM bytecode assumption has real implications for system behavior. Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to m…

I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that:

Java is more intimidating to get in to. It starts with "Oh dear, which JDK do I use?", proceeds to, "Oh dear, now I have to pick a build tool and every single one has a near-vertical learning curve by modern standards." Then you're on to, "I want to do X. Why are there 28 competing libraries for X, and why are the most popular ones invariably the most hated?" And so on.

There's a strong case to be made that procedural is a better paradigm than object-oriented for a lot of the niche that Go targets.

You mentioned concurrency ergonomics, but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's. There's too much legacy baggage that can never be unloaded.

Post reply on HN