Maybe since you're invested so in the idea you'd like to write a guide to best practice programming with a GC? There are numerous tricks used in real programming languages like allocating shortlived objects onto the stack (so you don't have to fiddle with the heap which is expensive) which wouldn't be applicable in Java, but presumably there are some tricks you can use to make your application run without lagging out for 10 seconds every 3 minutes.
I'd be glad to. I'm not sure when the last time you used Java was, but it definitely does not freeze up on me, even running applications at a high frame rate. Difference in speed is no longer noticeable to users of applications.
Unless you're writing a program that causes the GC to run major collections in short intervals, you won't even notice it's there. Short-lived objects aren't neglected, as you probably know. 3 different spaces of heap are dedicated to objects that don't live as long as others, and get tended to properly with minor collections that's managed on a background thread and takes milliseconds, not affecting processing time, nor do you have to worry much about context switching, seeing how the thread is short-lived. Yeah there's overhead, but like all pros and cons, you weigh them. Computers have more resources now-a-days, and the overhead becomes less and less of a problem. As the idea of not forcing programmers to manage memory grows, new systems will be implemented hopefully reducing overhead. The whole "stop-the-world" behavior only exists in some JVM implementations.
I understand you don't like the idea of people not managing their low-level resources, but times are changing, and the focus is targeted more at innovating consumer products now. Similar to how we no longer need to know how to kill a cow and cut it up to eat steak, people no longer need to understand all the underlying information in order to create unique applications.
As long as you manage object creation properly (implement pools where possible, cut back on creation by using patterns like the flyweight pattern) and don't interfere nativly with things you shouldn't (the JIT compiler nor any threads managing garbage collection), you shouldn't get any non-deterministic behavior, so if you could reproduce any behavior that isn't consistent without force, please let me know, because not even in theory can I think of anything that could cause strange behavior.
I'm not trying to attack you or your view on programming. I respect your opinion; the world still needs developers with that kind of mind-set. I'm just trying to show you reason why these languages really aren't as bad as you're putting them out to be. Even with understanding underlying information, modern computers can handle things looming around in memory for a bit longer than they need to, and if time is of true concern, the option is now available. Allowing programmers to focus on their application rather than how the memory is managed is a HUGE step forward
