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.
> 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.
> 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.
FWIW, when Xcode (on OS X) switched from GC to ARC (automated reference counting), it got a massive performance boost.
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.
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.
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.
Yeah, the error is on my part. Meant to say 'ARC is like a super primitive GC'. It gives a very small amount of automatism over manually freeing memory, but must be done by hand.
It's a super primitive in a same way an abacus is a super primitive computer.
Yeah, no, you aren't helping your case at all. ARC is, again, not like a super primitive GC. And it most certainly is not "done by hand". That completely contradicts the "Automated" part of "Automated Reference Counting".
Yeah, no - is a very bad linguistic form. Try to avoid it. I speak from experience.
Also, it is like a super primitive GC, in that it's a much more primitive and much more performant automatic memory management system (like GC). It's just a different level of abstraction we're talking here.
It's no different than saying how is polygon is like a super primitive circle.
GC and ARC are two very different approaches to memory management. Neither is more "primitive" than the other. They have different characteristics, different goals, different strengths & weaknesses.
> 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.
> 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?
> 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.
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.)
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.
> You said, "I don't want people who've ever used Go to work on nuclear operations."
Artistic license/ Rule of Funny. Using a correct form, wouldn't have been as funny.
Also yeah, it's supposed to be condescending. I was mocking the author, mirroring his condescension towards the Rust team (to paraphrase said - stop checkmarking GC, get crackin' on Rust; Wouldn't use Rust in a nuclear power plant).
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.
> 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.
> 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.
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.
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?
I try to be balanced—I've made it clear that I like a lot of the decisions in Go and have no animosity toward the team—but I will stop commenting on Go if you'd like. No big deal.
Please don't stop commenting on Go. There aren't all that many mainstream (sort of...) language implementors who comment here, which makes your point of view rather unique and very interesting. I'd love to see you comment about more languages, not fewer. While I'm definitely something of a Rust fanboi, this goes for anybody with a depth of experience in actually working on a language - I love reading their thoughts about the trade-offs that their own and other languages made.
It's not my place to ask you to do anything, and I didn't raise this topic. I'm just saying: if you're wondering why people think the Rust team has a beef with Go, that's one reason.
Eh, Rust and Go have been perceived as direct competitors since the day Rust was announced, and before I even worked on it. They even were more direct competitors before Rust started ironing out its low-level performance story and dropped GC. That perception's hard to shake.
And sure, I did end up learning quite a bit about Go. No, Go didn't make all the design decisions I would have made if I were designing the language, and yes, I've posted about some of those on here (null pointers, generics, zero values, lack of memory safety when racing on maps). But that doesn't mean I think it's a bad language, and I'd even like to use Go at some point for some projects (lack of time, argh).
Sure. I know you feel that way. But "the Rust and Go teams hate each other!" is a delicious and irresistible idea for some. When we are vocally critical of one another it perpetuates that meme whether we mean it or not. :-)
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.
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.
> , 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.
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.