They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
EDIT: I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
Good.
In a past engagement I developed the real-time, QNX Neutrino-based control systems for power plants (not nuclear, but a very large power facility all the same). I certainly don't expect you to know that, but it does make your dismissal rather humorous.
However literally you decided to take that comment, the point of it is that certain benefits are very important in certain domains, and unimportant in others. GC as a simple checkbox is something that matters in hard real-time systems, for instance. It matters when every cycle is important.
In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.
> They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
No they didn't. You just perceive it this way because fans of Rust often post in threads adding 'What about Rust'.
Fans non withstanding, I haven't really seen pcwalton or others (top 10 Rust contributors) behaving as you said they do. They comment on GC and various Firefox related technologies. Once the talk comparing Rust/Go starts, but I don't think they are as dismissive as you paint them.
But hey, prove me wrong, cite some messages.
--------------------
> In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.
I offered no checkbox, just an explanation why people are excited about Rust. To me the greatest power comes not so much lack of GC, but concurrency, safety (no nil, compiler errors on unassigned variables) and zero cost abstractions.
> I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
I certainly don't see it that way. I comment in Go threads occasionally because I have experience in the areas people are discussing (for example, garbage collection). Again, I think Go is a really practical language for the kinds of things people are doing with it, like Docker and Camlistore.
> In many other domains it needs to be analyzed, and there are no hard and fast rules.
Sure, I agree with that. The question is what you do when it becomes a problem. That's where having precise control can help.
I know the Rust team doesn't have any animosity toward Go, at least not those that I have talked to. And the Go team certainly doesn't have anything against Rust. But I must say that I do notice you being overwhelmingly negative about Go a lot on HN and I wonder why you do that. Technically, yes, you are adding to the discussion in some ways but to me it seems unnecessary.
Can you cite some overwhelmingly negative comments that pcwalton has made towards Go? I always cringe whenever I see him comment in a Go-related thread, because I know how people will interpret any criticism of Go that comes directly from a Rust dev, whether or not the criticism itself mentions Rust. That said, pcwalton has seemed even-keeled every time that I've seen him comment.
I ask because I'm the moderator of the Rust subreddit, and I have a strict rule against bashing other languages there. Not even Rust devs are exempt, though thankfully this has never been a problem. I'd like to encourage a culture of respect, rather than letting us get bogged down in holy wars. The constant comparisons of Go and Rust that I see on HN and the like are quite dismaying in my eyes.
I'd rather just drop this. I don't see any point in escalating the discussion when we're all on the same page regarding relations between the two projects.
Sharing my thoughts on language design as it relates to other languages seems to be doing more harm than good, so I'll stop.
> They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
> EDIT: I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
I've written a ton of Go code and a bit of Rust code and I love both languages.
FWIW, I disagree that the Rust team is dismissive of Go. I've always found their comments to be well balanced and cognizant of the relevant trade offs involved when comparing two languages like Go and Rust.
They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
EDIT: I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
Good.
In a past engagement I developed the real-time, QNX Neutrino-based control systems for power plants (not nuclear, but a very large power facility all the same). I certainly don't expect you to know that, but it does make your dismissal rather humorous.
However literally you decided to take that comment, the point of it is that certain benefits are very important in certain domains, and unimportant in others. GC as a simple checkbox is something that matters in hard real-time systems, for instance. It matters when every cycle is important.
In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.