For too many aspects for my liking, Go moves complexity out of the language and into your code where you get to unavoidably deal with the cognitive load. It's fine if you can keep things small and simple, but beyond a certain complexity, it's a hard pass for me.
I'm not sure about a single leading OpenJDk build. It may depend on your use case, and even then, I suspect that they're all pretty interchangeable unless you have some very niche need.
If you're doing anything on AWS, Amazon's Corretto is a good choice. Probably similar for Azure and Microsoft's offering.
If you're using JetBrains IDEs and don't mind waiting for the major release (11, 17, 21, etc.), then those aren't a bad choice either.
I've used Azul's Zulu plenty for my own projects. One thing they do different is to provide alternate builds for every JDK version with JavaFX packaged directly into the JVM.
It's pretty easy to pick and choose between them and manage multiple versions from multiple vendors simultaneously using SDKMAN.
Unsurprising. I'm not sure much has changed since this recording of Bruce Bugbee's talk "Why Vertical Farming Won't Save the Planet". There's nothing surprising there but he does give hard numbers to do the math that shows that vertical farming is not as good as its proponents have made it out to be. Solar energy input dwarfs all other energy inputs to agriculture, and the cost to replace one acre of solar energy with electricity comes out to $400,000 per acre (per some unit of days per a growing season). I don't think the economics have tended favorably since. The space needs for solar panels doesn't favor vertical farming either. He also shows the efficiency of modern agriculture, and why vertical farming has a pretty tall order ahead of it to beat the economics of outdoor farming. It's quite unlikely factors have changed enough since to alter his conclusion: only high-value, high-water-content specialty crops might be economically viable.
This is an absurd false dichotomy. You can pick fruits from the wilderness and not get mauled by bears. Using apps not in walled gardens has nothing to do with attempts to feel morally superior.
I agree 100%. Virtual threads have drawn a lot of skepticism but even Rust once had a version with them. They enable the strong structuted concurrency patterns. Async/await works nicely as long as your use case is "do this work on another thread, free this one up, resume here when the async task is done", but I've found that to be most common in UI work, and still not all that common (like if you want to track its progress, you still got some async state management coding to do). And even then you end up with a function coloring problem. People can try to downplay that, bit it is a giant wart resulting from that approach. I'll take Java's virtual threads combined with their structured concurrency efforts over async/await almost every time.