5 ms·

> You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you

by Ygg2 12y ago

> You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?), but it's interesting that you did exactly what I said -- it's just a checkmark. It's natural he's a heavy advocate, he is part of the Rust development team. Would be weird you are developing something you wouldn't advocate. They attacked Go how? They responded to your reply that was about GC, rarely if ever mentioning Go. This is a thread about Rust and people hijacked it with Go comparison, saying server are better suited for Go, etc. Like if I was working on developing some language X and people started making talks about competitor Y, I'd want to address any such claims, simply out of pride of my own work. > Now, I'm not going to make a real-time nuclear power plant controller (minor edits) Good. I wouldn't trust anyone that has dabbled in Java/Go/.Net and made various servers/web-applications to look upon schematics of a real-time nuclear power plant controller, let alone be in same room with the code. Neither would I trust their opinion on whether language X is suited for that need. They are about as competent to make that decision as a bull is competent to make judgement of quality of fine Chinese porcelain. With his feet. This set of people includes myself. NOTE: I'm merely mirroring your dismissive stance about authors focusing on releasing and not talking (seriously, you have no idea how much effort went and still goes into Rust). Also programming RT systems of critical importance is on the complete opposite side of developing GC web application/servers. While your argument about GC on web apps might be considered valid, you haven't shown any knowledge of critical RT nuclear components, that would merit a different comment.

personZ 12y ago
They attacked Go how? 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.
- pcwalton 12y ago
  > 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.
  - enneff 12y ago
    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.
    - kibwen 12y ago
      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.
      - pcwalton 12y ago
        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.
burntsushi 12y ago
> This is a thread about Rust and people hijacked it with Go comparison, saying server are better suited for Go, etc. Umm, no, they didn't. This thread started with someone whining about Go's type system. > I wouldn't trust anyone that has dabbled in Java/Go/.Net and made various servers/web-applications to look upon schematics of a real-time nuclear power plant controller, let alone be in same room with the code. How deliciously condescending of you! And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants? Count me skeptical.
- Ygg2 12y ago
  > Umm, no, they didn't. This thread started with someone whining about Go's type system. I meant the entirety of this discussion, see the name of thread - Is Rust web yet? Not really. > How deliciously condescending of you! > And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants? Yes, yes it is. I didn't say that anything about C++. I'd assume that whatever C / Ada / Assembly /Machine code variant people working on critical embedded software use. C++ has exceptions, that alone disqualifies as critical performance language.
  - burntsushi 12y ago
    I respectfully submit that you missed my point. I randomly picked C++ as a language you didn't mention. My point is that you were being condescending. I'll be more direct: please don't be condescending. (I really don't know how to deal with the fact that you're seriously talking about who is and who isn't qualified to work on nuclear operations based on languages they've used.)
    - Ygg2 12y ago
      And you missed my point. Right tool for the right job. You don't take a fork to drink a soup and you don't take a spoon to cut meat (unless the knife is duller than the spoon). Sure sometimes is fun to improvise by using knife as a fork, but that's a silly way to eat. With that in mind a different language operates with a different set of limitations and a different mental model of execution. Most people that program in Java don't have to worry too much about memory footprint, whether GC pause will kill performance, etc. Fact that they are using GC means they accepted non-deterministic pauses as part of the programming. To move from that frame of mind to a really performance sensitive where frequency and voltage matters requires a radical shift of thought.

by Ygg2 12y ago

personZ 12y ago

They attacked Go how? 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.

pcwalton 12y ago
> 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.
- enneff 12y ago
  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.
  - kibwen 12y ago
    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.
    - pcwalton 12y ago
      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.

burntsushi 12y ago

> This is a thread about Rust and people hijacked it with Go comparison, saying server are better suited for Go, etc. Umm, no, they didn't. This thread started with someone whining about Go's type system. > I wouldn't trust anyone that has dabbled in Java/Go/.Net and made various servers/web-applications to look upon schematics of a real-time nuclear power plant controller, let alone be in same room with the code. How deliciously condescending of you! And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants? Count me skeptical.

Ygg2 12y ago
> Umm, no, they didn't. This thread started with someone whining about Go's type system. I meant the entirety of this discussion, see the name of thread - Is Rust web yet? Not really. > How deliciously condescending of you! > And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants? Yes, yes it is. I didn't say that anything about C++. I'd assume that whatever C / Ada / Assembly /Machine code variant people working on critical embedded software use. C++ has exceptions, that alone disqualifies as critical performance language.
- burntsushi 12y ago
  I respectfully submit that you missed my point. I randomly picked C++ as a language you didn't mention. My point is that you were being condescending. I'll be more direct: please don't be condescending. (I really don't know how to deal with the fact that you're seriously talking about who is and who isn't qualified to work on nuclear operations based on languages they've used.)
  - Ygg2 12y ago
    And you missed my point. Right tool for the right job. You don't take a fork to drink a soup and you don't take a spoon to cut meat (unless the knife is duller than the spoon). Sure sometimes is fun to improvise by using knife as a fork, but that's a silly way to eat. With that in mind a different language operates with a different set of limitations and a different mental model of execution. Most people that program in Java don't have to worry too much about memory footprint, whether GC pause will kill performance, etc. Fact that they are using GC means they accepted non-deterministic pauses as part of the programming. To move from that frame of mind to a really performance sensitive where frequency and voltage matters requires a radical shift of thought.