Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

151–160 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#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 with calm and reasoned counter arguments of the content but not today I guess.

Re: Lies we tell ourselves to keep using Golang

#152
post #142
post #109

Earlier quoted context omitted.

As I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.

> It's possible to implement CSP channels in most languages, but they're not first-class like go. But does that matter ? In all my experience, I can't think of any instances where that wouldn't be a distinction without a difference. (Perhaps I'm missing something, though.)

Defaults matter because friction matters, but friction there is largely removed by having a decent package manager, so I personally don't think it matters (though the topic of "what batteries should be included" has far from run its course).

Re: Lies we tell ourselves to keep using Golang

#153
I use Go heavily cross-platform developing DataStation [0] and dsq [1]. I am not an expert. And I don't have proof for it but on some rudimentary benchmarks the Linux-specific file idioms in the Go standard library definitely don't seem to translate well to even macOS let alone Windows. For example some good streaming techniques for reading large files on Linux that work really well there seemed to be pretty bad on macOS.

I think Amos has presented more proof than I can on the topic of just how Linux-influenced Go is. And I think it is fine for the majority of Go users because the majority users of Go are building server apps or Linux CLIs.

Amos has spent some time building cross-platform desktop systems with Go for itch.io and I think I'm seeing some of the same things they are in that scenario.

I think this is a reasonable article. I didn't notice anything too flame-y myself but if for you Amos gets flame-y at any point I think that's worth ignoring because there does seem to be something up with Go in cross-platform applications. Amos does have good experience here. (Go look at itchi.io's github like wharf [2] or butler [3] where they are/were the main contributor.)

I like Go a lot and for most things I'd keep using it still. Just sharing some observations.

[0] https://github.com/multiprocessio/datastation

[1] https://github.com/multiprocessio/dsq

[2] https://github.com/itchio/wharf

[3] https://github.com/itchio/butler

Re: Lies we tell ourselves to keep using Golang

#154
I'm just wondering why the author keeps making those articles about strongly disliking Go, ok we get it your favorite language is Rust, you don't like Go. Why does the author does not move on, exactly?

"Fine. It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google)."

This is really wrong on so many level especially coming from someone that has shipped what exactly in production? What is the expertise of OP to tell people to not use a language that was proven to be very successful.

Re: Lies we tell ourselves to keep using Golang

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

I believe that you are perfectly productive with Go, the article hasn't claimed otherwise.

I used to be quite productive with PHP. That does not mean PHP is a good language.

> The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not.

You are replying to an article mentioning many of Go's problems, without rebuking any of the article's points. Perhaps these poor people are using a bad language? (Also perhaps some people reading this are "bad developers", whatever that means? Perhaps I am! What does that matter?)

Re: Lies we tell ourselves to keep using Golang

#156

You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.

Right now our only mechanism to indicate that we don't think a post is appropriate is to flag it. We don't have the ability to downvote posts that we don't feel meet the quality bar for being featured on HN.

Re: Lies we tell ourselves to keep using Golang

#157
This article should get unflagged. This is an eloquently written article and a good discussion about Golang. I think we need more articles critical of Golang.

Edit: I'm really shocked by the downvotes. Can someone explain why my comment is worthy of being downvoted?

Re: Lies we tell ourselves to keep using Golang

#159

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…

No post body was provided.
Post reply on HN