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

381–390 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#381

Post by dang »

mumblemumble wrote: post #357
dang wrote: post #263

Earlier quoted context omitted.

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

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), then I'd be willing to take another look - in that case the best thing would be to link to the subthreads that you think make the best case for it.

The and in the previous paragraph is important, though, because a core moderation principle is to de-emphasize generic discussion (and follow-up threads, and repetition generally) in favor of significant new information. Past explanations on all that, if anyone cares:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

Re: Lies we tell ourselves to keep using Golang

#382

Post by mumblemumble »

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 don't really use Go, I think mostly because I'm not in the target market, but this article's complaints (and some of these comments) actually got me thinking that I should take another look at it.

A long time ago, in a Haskell community chat, I saw someone dismiss Go with a pithy comment along the lines of, "Go isn't a programming language, it's a DSL for writing network services." I think I may need to re-assess that comment as actually being a really compelling elevator pitch for the language.

Armed with that perspective, I'm seeing why I wasn't terribly convinced by the article's specific complaints about Go. "Traditional IPC is a PITA and forces you toward talking over a socket? Well, yes, exactly. That's kind of the whole point."

Sometimes I wonder if we are all suffering unnecessarily because of our incessant demanding that all languages try to be all things to all people.

Re: Lies we tell ourselves to keep using Golang

#383

Post by AnimalMuppet »

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…

But people write "low-effort attempts" at exception handlers all the time. So using exceptions instead of error values doesn't actually change the situation.

Re: Lies we tell ourselves to keep using Golang

#384

Post by pvg »

mumblemumble wrote: post #377
pvg wrote: post #372

Earlier quoted context omitted.

The guiding logic here is 'it would be boring to have a discussion of X on the front page every day'. For many X, there's infinitely many things to say but the front page is finite and has a goal of not being boring. HN's been moderated like that for ages and it seems to work reasonably well.

I don't think it's necessarily the HN moderation team's job to tell us what we should and should not find interesting. It's a crowdsourced news aggregation site and discussion forum, not a magazine with an editorial board. The sheer number of upvotes on this article, despite the attempt at suppressing it, is a clear indication that, regarldess of what dang thinks, a lot of people in the HN community think that someth…

I don't think it's necessarily the HN moderation team's job to tell us what we should and should not find interesting. It's a crowdsourced news aggregation site and discussion forum, not a magazine with an editorial board.

That's fundamentally not how HN works, though. It's neither just crowdsourced nor just editorially curated. This thing ends up being a dupe fairly straightforwardly, it's not some weird edge case. Any big front page discussion naturally has a lot of people interested in keeping the discussion going.

Re: Lies we tell ourselves to keep using Golang

#385

Post by kaba0 »

boulos wrote: post #148

As people have remarked, Amos's style can be grating and hyperbolic. That doesn't make a lot of his complaints about Go as a language incorrect. I do think he's misunderstanding that the design intent is "networked C" and that Go + Protobuf is much better than he thinks. A lot of his complaints with the language and runtime boil down to: - It's got a primitive type system (yep, nobody disagrees) - It leaves a lot of…

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 has some warts but it is a very easy and small language, the reflection-based frameworks are not at all mandatory, Java can be quite expressive without those as well and it is extremely performant. Once value types get included it will be really hard to get ahead of Java.

Re: Lies we tell ourselves to keep using Golang

#386

Post by mumblemumble »

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…

I think the quote marks were there to indicate that this was walking through a hypothetical thought process that someone might go through. (It proceeds on to the next line after that, where you see the closing quote mark.) The gist of the whole thing was basically to say, "Don't make the perfect the enemy of the good."

Re: Lies we tell ourselves to keep using Golang

#387

Post by mumblemumble »

pvg wrote: post #384
mumblemumble wrote: post #377

Earlier quoted context omitted.

I don't think it's necessarily the HN moderation team's job to tell us what we should and should not find interesting. It's a crowdsourced news aggregation site and discussion forum, not a magazine with an editorial board. The sheer number of upvotes on this article, despite the attempt at suppressing it, is a clear indication that, regarldess of what dang thinks, a lot of people in the HN community think that someth…

I don't think it's necessarily the HN moderation team's job to tell us what we should and should not find interesting. It's a crowdsourced news aggregation site and discussion forum, not a magazine with an editorial board. That's fundamentally not how HN works, though. It's neither just crowdsourced nor just editorially curated. This thing ends up being a dupe fairly straightforwardly, it's not some weird edge case.…

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 article is a much more nuanced and thoughtful position on the subject that definitely adds a different perspective to the conversation. It focuses on higher level questions about how one designs (or chooses) a software platform and ecosystem, where the original one was a fairly shallow fisk of language design issues. Wasn't it mostly drumming on syntax?

Re: Lies we tell ourselves to keep using Golang

#388

Post by mumblemumble »

tracerbulletx wrote: post #320
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."

As developers get more and more senior they tend to ignore more and more problems because they realize the majority of them actually don't matter very much to doing useful work.

Or, perhaps more frequently, they can quickly see that any possible fix for it would be penny wise and pound foolish.

Re: Lies we tell ourselves to keep using Golang

#389

Post by mumblemumble »

dang wrote: post #381
mumblemumble wrote: post #357

Earlier quoted context omitted.

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

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.

Re: Lies we tell ourselves to keep using Golang

#390

Post by kaba0 »

noisy_boy wrote: post #234
cglan wrote: post #61

I just don't see the issue with Go. After dealing with inscrutable errors in some python code that interfaces with OpenSSL. Or dealing with impossible to trace errors in Spring Boot. Or Javascript? An absolute nightmare from start to finish. There's something extremely nice to get an error, place a breakpoint and trace exactly (even if it's a third party library) that error is happening. I will take all the footguns…

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

I seriously doubt that Go would compile faster than Java. Like, neither does any reasonable amount of optimization, and I have never heard Java considered slow in compile time. Sure, one can do some very cryptic module-graph with their chosen build tool, but otherwise it should be as fast as it gets.
Post reply on HN