Author should have used this article to propose Go 2.0 changes. For me, I read it like a rant.
Lies we tell ourselves to keep using Golang
191–200 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#192Earlier quoted context omitted.
This is the second day in a row where a post about Go in a negative light was flagged. The first one was an extremely detailed criticism, maintained the front page, and was flagged like crazy. What gives?
This is the second day in a row where a post about Go _from the same blog_ has been posted. I think that's enough, especially since it's mostly a knee jerk reaction from that very HN post from yesterday. https://news.ycombinator.com/item?id=31191700
This post is (sort-of) a response to yesterday's discussion. I think it's fair to post it today.
Re: Lies we tell ourselves to keep using Golang
#193Earlier quoted context omitted.
This is the second day in a row where a post about Go _from the same blog_ has been posted. I think that's enough, especially since it's mostly a knee jerk reaction from that very HN post from yesterday. https://news.ycombinator.com/item?id=31191700
Who cares if it is a legitimate criticism and makes unique points in both cases (also, they were both written two years apart!)? Some call it "inflammatory" but it has scientific and critical value nonetheless.
> Who cares if it is a legitimate criticism and makes unique points in both cases?
Clearly, the people flagging it care, whether because they disagree with your assessment of it providing legitimate criticism and unique points in both cases, or because they think some other quality it has outweighs that in assessing it against the bar for belonging on HN.
> Some call it "inflammatory" but it has scientific and critical value nonetheless.
Value is subjective and people clearly disagree with you on this point.
Re: Lies we tell ourselves to keep using Golang
#194I have a hard time judging the "actual quality" of the article, but considering the quality of the discussions it generates, I don't think something like that is a good fit for HN. There's something that I think is important to mention: there's a difference between theorical ways to make bugs and bugs that happen in reality. The author spends more time talking about theorical ways to make bugs than bugs that happen i…
> there's a difference between theorical ways to make bugs and bugs that happen in reality On a large enough (time)scale, no there isn't. But also, all this is rooted in years of running and/or watching someone run Go in production. These bugs aren't theoretical, they cause incidents and outages, and occasionally wake me up. I don't like being woken up.
I'd appreciate it if you wouldn't ignore most of my post and my experience. As I've said, our codebase is more than 20 years old (which is a large time scale for most code), and the vast majority of errors are logic errors and not TypeError: Thing is undefined. You seem to think that only your vision of things is valid, which is a terrible attitude to have. If you don't like being woken up, find a job where you're not on call.
Re: Lies we tell ourselves to keep using Golang
#195Re: Lies we tell ourselves to keep using Golang
#196Earlier quoted context omitted.
For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very…
If that's all you want, Haskell has had goroutines (forkIO, yes it's called "fork" but it doesn't spawn an OS level process, that's forkOS), channels, and select since 1996. https://www.microsoft.com/en-us/research/wp-content/uploads/...
No post body was provided.
Re: Lies we tell ourselves to keep using Golang
#197What's up with the anti-Golang shitposts lately? I liked fasterthanlime better when he didn't just sound like a card-carrying Rust zealot. This isn't even about the practicalities of his argument really; optics matter, and it's especially bad since the Rust community used to be known for its politeness and always being fair to other language communities.
The last time his "I want off" article was reposted[0], the comments were pretty rough, ranging from ad-hom attacks to (at best) misunderstandings of the arguments he was making. I see this article being an address to these criticisms (which are not limited to this forum, I've seen similar arguments on twitter, etc.). Pointing out shortcomings isn't really impolite or unfair. The author specifically mentioned shortco…
> The last time his "I want off" article was reposted[0]
Of note: the last time in question was yesterday, the flagging and ad-hominems pretty obviously made lime's cupeth runneth over.
Re: Lies we tell ourselves to keep using Golang
#198Re: Lies we tell ourselves to keep using Golang
#199I'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…
To put it shortly, the tone is so pointlessly aggressive that it obscures what accurate information the post contains. The information itself is also presented in a haphazard manner, seemingly chosen to maximize the critical intention as opposed to clarifying things for the reader. Some info that would be potentially valuable to the reader is simply not there, purely because it doesn't fit the "bad Golang!" overall emphasis of this post. E.g. what about pointing at newer novice-friendly prototyping languages with a better FFI story than Go? There's quite a few of them: Nim, Crystal, the new language Hare etc. But you won't find any serious mention of them here, or any comparison of their benefits and drawbacks.
Re: Lies we tell ourselves to keep using Golang
#200This shouldn't be flagged...
I flagged it because it appears to be written to mostly elicit outrage, as opposed to informing the reader. For example the headline "Mom smokes, so it's probably okay" and then 8 paragraphs of lead-up to the argument that the Go standard library has an inelegant IP type. Afterwards the author equates people using custom types to "build a whole new type system". "Evidently, the Go team didn't want to design a languag…
The headline and the paragraphs lead up to an illustration how the IP type in Go is inelegant because of several shortcomings in Go. It's a perfectly acceptable instrument to the argument.
It immediately follows up with interesting discussion about how it's acceptable for a team of experts to use Go. I think he's wrong, Go is perfectly powerful in the hands of novices. And I actually think a team of experts like Tailscale would probably be much better served by choosing Rust.
But that's all besides the point. The article is excellent, fits our forum and is a great basis for discussion. You are not using the flagging feature as it's intended to be used.