7 ms·

There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given t

by personZ 12y ago

There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies. 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. "GC baaaaaaad". Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language. Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that. No, .NET and Java do escape analysis as well. .NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding. so heap allocations are essentially as cheap as stack allocations: just a pointer bump When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.

pcwalton 12y ago
> Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies. Ask major game developers whether they would be OK with pervasive GC. (We have, and the answer is near unanimous.) You simply need control over each and every allocation. As a browser developer, I would certainly not be OK with pervasive GC in a browser engine, which are millions of lines of code at this point. The performance competition is just too brutal. > 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?) I'm not attacking Go; I think it's a fine language. I'm taking issue with the idea that GC doesn't matter. The fact that this is happening in the context of Go is a side effect of the unfortunate fact that half of the comments on any Rust thread are about Go, and I would have the same arguments in the context of Java (since I don't think Java and Go are fundamentally that different in their reliance on GC anyhow). > The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing. Sure, but minor collections are really, really fast. In a proper generational copying garbage collector I doubt this matters; the JVM looked at escape analysis for promoting heap allocations to stack allocations and found it didn't help very much.
- fulafel 12y ago
  But still some of the most popular game platforms use GC, like Unity (C#) and iOS.
  - Ygg2 12y ago
    Yeah, but Unity is very Indie oriented, no? I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal. Unreal is defacto industry standard. iOS, has ARC IIRC, not sure it has true GC like Java or C#. ARC is a super primitive GC.
    - eridius 12y ago
      ARC is not GC. It's automated reference counting. It's not a "super primitive GC" because it's a completely different approach to memory management. Notably, it has predictable behavior/performance characteristics, is suitable for realtime work (inasmuch any object-oriented approach with allocation/deallocation is; basically, it doesn't pause like GC does), and is fast. The downside is it is vulnerable to reference cycles.
      - fulafel 12y ago
        The question was about precise control over memory allocations. Arc hides it like other forms of GC. You can tread carefully to avoid pauses with GC, but it is more fragile than explicitly manual mem management. Ref counting does pause, you get cascading deallocations. More deterministic than other GC though.
        eridius 12y ago
        Neither ARC nor GC hide memory allocations. They automate the process of deallocating memory. And ARC does not hide that either. Values get released when they go out of scope, and they get deallocated when the last reference disappears. It's a very explicit process, the only "hiding" is the fact that there is no `[foo release]` line anymore. But it's no more hidden than C++ destructors are. > Ref counting does pause, you get cascading deallocations. That's not pausing. That's it doing work, upon request (i.e. when the object is released). If you have a single object that roots a massive object graph, and you release that single object, yes, it will have to destruct that entire object graph. But that's not the fault of ARC in the slightest, and would happen just the same with manual memory management. > More deterministic than other GC though. It's not GC, so what do you mean by "other GC"? --- ARC has the exact same performance characteristics as manual memory management, except it's all automated so you can't screw it up (e.g. over-releasing or under-retaining). But it's subject to optimizations too (such as skipping the autorelease pool), which actually makes it faster than MRR in a lot of cases.
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.
steveklabnik 12y ago
> the Rust crew has decided that they need to aggressively attack Go FWIW, most Rust people don't even see Rust and Go as competing, but everyone keeps comparing the two, and at some point, repeating a falsehood enough time makes it truth.
- Ygg2 12y ago
  Yeah I can see them competing on the fabulous title of 'systems language' which means in Go's case - Server, Google toolchain and Rust's case - embedded, browser.
  - steveklabnik 12y ago
    Right, Go and Rust have different definitions of 'systems language.' Even Rob Pike thought Go and Ru...errr, C++ would be competing, but was surprised when it turns out they weren't. Go was competing with Python and Ruby all along.
- enneff 12y ago
  This is true, but Patrick does pop up on a lot of Go threads saying negative things. If the Rust team doesn't want to be perceived as critical of Go then they shouldn't be so vocal about it.
  - steveklabnik 12y ago
    I have lots of negative things to say about Go too, but it has nothing to do with Rust. I also have lots of positive things to say as well, but they have nothing to do with Rust. I haven't felt that way about pcwalton's comments. Maybe I'm wrong. Care to link some comments?
    - cnbuff410 12y ago
      Just click on his profile and view his comment history. You won't find the examples lacking
  - 12y ago
Dewie 12y ago
> , and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go Most of the time that I see Go come up as a comparison to Rust on places like HN, it is someone who is asking how Rust compares to Go, some question about 'systems languages like Go, Rust, C++', etc. In turn, someone on the Rust team might answer, but they weren't the one to bring up the topic to begin with.
kibwen 12y ago
> the Rust crew has decided that they need to aggressively > attack Go As the one person in the world who is perhaps most up-to-date on what the "Rust crew" is doing in the community at-large, I can definitively state that this characterization is untrue, though I'm dismayed that you have somehow gotten that impression. All of the people that I've seen who bash Go while praising Rust are completely random internet commentators with no connection to the Rust community. If you can find me examples of Rust community members aggressively attacking Go, I will gladly ban those users from both the Rust subreddit and the official Rust IRC channel.

by personZ 12y ago

pcwalton 12y ago

> Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies. Ask major game developers whether they would be OK with pervasive GC. (We have, and the answer is near unanimous.) You simply need control over each and every allocation. As a browser developer, I would certainly not be OK with pervasive GC in a browser engine, which are millions of lines of code at this point. The performance competition is just too brutal. > 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?) I'm not attacking Go; I think it's a fine language. I'm taking issue with the idea that GC doesn't matter. The fact that this is happening in the context of Go is a side effect of the unfortunate fact that half of the comments on any Rust thread are about Go, and I would have the same arguments in the context of Java (since I don't think Java and Go are fundamentally that different in their reliance on GC anyhow). > The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing. Sure, but minor collections are really, really fast. In a proper generational copying garbage collector I doubt this matters; the JVM looked at escape analysis for promoting heap allocations to stack allocations and found it didn't help very much.

fulafel 12y ago
But still some of the most popular game platforms use GC, like Unity (C#) and iOS.
- Ygg2 12y ago
  Yeah, but Unity is very Indie oriented, no? I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal. Unreal is defacto industry standard. iOS, has ARC IIRC, not sure it has true GC like Java or C#. ARC is a super primitive GC.
  - eridius 12y ago
    ARC is not GC. It's automated reference counting. It's not a "super primitive GC" because it's a completely different approach to memory management. Notably, it has predictable behavior/performance characteristics, is suitable for realtime work (inasmuch any object-oriented approach with allocation/deallocation is; basically, it doesn't pause like GC does), and is fast. The downside is it is vulnerable to reference cycles.
    - fulafel 12y ago
      The question was about precise control over memory allocations. Arc hides it like other forms of GC. You can tread carefully to avoid pauses with GC, but it is more fragile than explicitly manual mem management. Ref counting does pause, you get cascading deallocations. More deterministic than other GC though.
      - eridius 12y ago
        Neither ARC nor GC hide memory allocations. They automate the process of deallocating memory. And ARC does not hide that either. Values get released when they go out of scope, and they get deallocated when the last reference disappears. It's a very explicit process, the only "hiding" is the fact that there is no `[foo release]` line anymore. But it's no more hidden than C++ destructors are. > Ref counting does pause, you get cascading deallocations. That's not pausing. That's it doing work, upon request (i.e. when the object is released). If you have a single object that roots a massive object graph, and you release that single object, yes, it will have to destruct that entire object graph. But that's not the fault of ARC in the slightest, and would happen just the same with manual memory management. > More deterministic than other GC though. It's not GC, so what do you mean by "other GC"? --- ARC has the exact same performance characteristics as manual memory management, except it's all automated so you can't screw it up (e.g. over-releasing or under-retaining). But it's subject to optimizations too (such as skipping the autorelease pool), which actually makes it faster than MRR in a lot of cases.

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.

steveklabnik 12y ago

> the Rust crew has decided that they need to aggressively attack Go FWIW, most Rust people don't even see Rust and Go as competing, but everyone keeps comparing the two, and at some point, repeating a falsehood enough time makes it truth.

Ygg2 12y ago
Yeah I can see them competing on the fabulous title of 'systems language' which means in Go's case - Server, Google toolchain and Rust's case - embedded, browser.
- steveklabnik 12y ago
  Right, Go and Rust have different definitions of 'systems language.' Even Rob Pike thought Go and Ru...errr, C++ would be competing, but was surprised when it turns out they weren't. Go was competing with Python and Ruby all along.
enneff 12y ago
This is true, but Patrick does pop up on a lot of Go threads saying negative things. If the Rust team doesn't want to be perceived as critical of Go then they shouldn't be so vocal about it.
- steveklabnik 12y ago
  I have lots of negative things to say about Go too, but it has nothing to do with Rust. I also have lots of positive things to say as well, but they have nothing to do with Rust. I haven't felt that way about pcwalton's comments. Maybe I'm wrong. Care to link some comments?
  - cnbuff410 12y ago
    Just click on his profile and view his comment history. You won't find the examples lacking
- 12y ago

Dewie 12y ago

> , and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go Most of the time that I see Go come up as a comparison to Rust on places like HN, it is someone who is asking how Rust compares to Go, some question about 'systems languages like Go, Rust, C++', etc. In turn, someone on the Rust team might answer, but they weren't the one to bring up the topic to begin with.

kibwen 12y ago

> the Rust crew has decided that they need to aggressively > attack Go As the one person in the world who is perhaps most up-to-date on what the "Rust crew" is doing in the community at-large, I can definitively state that this characterization is untrue, though I'm dismayed that you have somehow gotten that impression. All of the people that I've seen who bash Go while praising Rust are completely random internet commentators with no connection to the Rust community. If you can find me examples of Rust community members aggressively attacking Go, I will gladly ban those users from both the Rust subreddit and the official Rust IRC channel.