> Object pools were good JVM thinking 10 years ago. It's been a very long time since they made any sense for memory-based objects.I guess that's why libgdx very recently added pooling, right? And (OK, it's Dalvik, but still) why Android uses view recycling all over the place? Why recommended practice for ListView is to re-use existing objects whenever possible?
I'm not pulling the use of pooling out of my ass here. This is what you do for high-performance managed stuff, in games and otherwise. Everybody I've ever worked with, and I've worked with some pretty heavy hitters (some of my former coworkers at TripAdvisor are insanely plugged into the Way Of The JVM), has kept pooling in the toolbox for latency-sensitive problems.
> Unity manages to do quite a bit with the CLR on a cross-platform basis, and that looks like Javascript to me.
Well, for one, it's not. It's statically typed sort-of-JScript. It bears little relation to JavaScript; it was originally called UnityScript and the name was changed largely for buzzword bingo purposes. (It's really very frustrating when working in Unity, both because it's not real JavaScript but doesn't play nicely with Boo and C# scripts a lot of the time.)
Unity also has notable performance problems for nontrivial scenes due about 50/50 to expensive creation on the front end and garbage collection on the back end. One of the most popular Asset Store items is--wait for it--an object pooling system.
> Horrors! AngelScript has Garbage Collection! But since it didn't come from the JVM, I guess it's OK.
It does, but only if you're allocating within it. I literally never allocate non-stack data in it. I use it as a logical glue layer within my application, which is not garbage collected.
> Every victim of a use-after-free just cried out in anguish. Your world weeps at 60 fps.
I literally can't remember the last time I hit a use-after-free in my own code. If you understand your object lifetimes, RAII will usually (almost always?) put you in the right place. In the worst of cases, where you've found yourself in a thoroughly opaque situation and can bear the perf hit, you have tools like boost::shared_ptr (though in my current project I don't use it anywhere).
It's certainly possible to make mistakes, but it is easier to do the right thing than most managed-languages people are willing to admit. I used to be one. It's why I was pretty terrified of working in C++ for so long. As it happens, I think former-me was pretty wrong about that.
> What's a good language for implementing a browser? The number one requirement for a browser today is not performance. It is security.
I'm of two minds about this. Sure, security is a critical concern. But user experience isn't to be ignored, and I really do feel that user-detectible pauses are to be avoided at all costs. Writing better native code is, to me, a more feasible option than an imperceptibly fast general-purpose garbage collector.
(As an example, I grow frustrated when scrolling a big list on my Nexus 4 when I can watch the scrolling get stuttery. In my experience, it's almost always due to someone not following best practices and re-allocating instead of re-using existing objects.)