511–520 of 561 posts
Earlier quoted context omitted.
> You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.
I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
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 don't think that the author is telling anyone to stop using Go. They are suggesting that there should be a better alternative, and there are lessons to be learnt. I don't think we should be so cynical as to just lie down and accept that some things are just too hard to get right
Earlier quoted context omitted.
Programming languages have a large amount of irreducible complexity. A page long spec for a language more complex than Brainfuck cannot represent the critical distinctions correctly. Without that clarity, you end up with incompatible, spec-compliant implementations. This is a disaster, and so below a certain point relative to language complexity a shorter spec is simply wrong.
> Without that clarity, you end up with incompatible, spec-compliant implementations. The Go team officially maintains two implementations, gc and gccgo, to ensure that implementation doesn't end up ruling over the specification as has happened in other languages. There are also other third party implementations, including tinygo. Which spec-induced incompatibilities across these implementations are you referring to?
We have tens of microservices written in Go. Go is good for onboarding new devs because it's simple. Our existing PHP devs were taught Go and it was painless. Jumping from PHP straight into Rust would be pretty painful, I think. Finding Rust devs isn't easy in our town. But I agree with most of the points. You got to be very careful when writing in Go, because there are many gotchas. So many gotchas that I had to wri…
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…
When the author make such claim: "It may well be that Go is not adequate for production services unless" Who is exactly the author to tell us to not use a language that was proven to be just fine and successful. What actually OP shipped in production to be able to make such claim? Does it means also that Java / C# / Python, Ruby ect have the same fate since they're not up to part with Rust? Kubernetes is everywhere a…
b) please read the article before complaining
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…
Let's not pretend that some flagging of this article represents all or most developers who use Go, and also not pretend that this post represents all or most developers who use Rust. What kinda gets me from this genre of post, is that it sounds like writing good software in any language besides Rust is impossible, or even impractical. Like 10 years ago it was impractical for anyone to enjoy writing good software. (Or…
I think what we are seeing here is that the expectations are growing and people demand more from their tools.
This is a good thing, even if some languages cannot keep up with the higher standards and fall behind.
Earlier quoted context omitted.
This post is (sort-of) a response to yesterday's discussion. I think it's fair to post it today.
No sort-of about it. The author directly quotes from yesterday's HN discussion. It's a continuation of the dialogue.
The timing is a coincidence.
Earlier quoted context omitted.
Yes, exactly, although I personally don't see how a substantive post, responding to a well-discussed issue from the previous day, could possibly qualify as "spam". I guess others agree, since the post did not remain flagged.
And others are free to disagree with your opinion. I read the content as lacking maturity, emotionally loaded and not the kind of content that fosters productive conversation in HN (as can be evidenced by the caliber of most comments in this thread). The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint.
The flag was removed by moderators, but by then the algorithm already did its thing.
> Take that as a hint.
As a hint that sometimes you should do you research before making claims? Agreed.
> I read the content as lacking maturity, emotionally loaded
The article is perfectly fine, but what I gather from the reactions of Go fans is that they are lacking in maturity and become too emotional if their toy is criticized.
Something the author explicitly mentioned in his article. You should read it.
Earlier quoted context omitted.
If you find it does not have value to you , don't upvote it and ignore it. Don't flag it to try to hide it from people who it may have value for. It's clearly not spam, so it's not your job to determine whether it has value for other people.
Flagging posts that would not fit on HN or would just cause pointless flamewars is acceptable. Given the state of this thread, I think it's even more justified. "Users [flag] post as breaking the guidelines or otherwise not belonging on HN." https://news.ycombinator.com/newsfaq.html
So the worse the (Go) community behaves, the more careful authors have to be?
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…