I too live in a region with 80 (Celsius) degree yearly variation (sometimes more; the maximum yearly difference I've lived through is about 90 degrees IIRC: -45 in January to +43 in July), and Fahrenheit makes absolutely no sense to me in this climate.

Celsius works significantly better in cold climates for reasons mentioned in another comment.

+10°C is "it's somewhat cold, put a jacket on". +20°C is comfortable in light clothing. +30°C is pretty hot. +40°C is really hot, put as little clothing as society permits and stay out of direct sun.

Same with negatives, but in reverse.

Boiling water is +100°C, melting ice is very close to 0°C. I used that multiple times to adjust digital thermometers without having to look up anything.

It's the most comfortable system I can imagine. I tried living with Fahrenheit for a month just for fun, and it was absolutely not intuitive.

https://www.token2.com/shop/category/classic-tokens

https://www.token2.com/shop/category/c301-tokens

https://www.token2.com/shop/category/multi-profile-programma...

Other vendors probably have something like that, I link to what I've personally used.

The level of code refactoring tools available in IDEA dwarf anything vscode has been able to come up with, and I don't see that changing. And it's not just for Java (although it gets the best tooling), they're the best for every language that has any popularity at all. Including TypeScript, where IDEA has a significantly better performing lsp features than vscode.

For example, it automatically finds copypasted code (including cases where variable names and code structure might differ) and can automatically extract a single implementation and generalize it for you with a single key press. If you have multiple classes with similar interfaces, it can extract the common bits into an interface and update the classes to become its implementations. It can shuffle types and methods around for you, automatically updating references (which you've mentioned). Autocompletion for absolutely everything, including difficult cases like e.g. SQL inside a Rust snippet inside Markdown. And much more.

Same with those five dollar vl keys people buy off eBay for some unfathomable reason. Pure waste of money.

I wish they would add ZFS to it.

Oracle was consistently the first, lagging behind RHEL for a few hours (for important stuff) to a couple of days (for less important ones). Alma was a very close second. Rocky would spend days to weeks and was by far the slowest.

No, I don't buy the argument that it's good for you because they receive additional testing. If you really need that much stability that you can't take an update after RHEL has done so, introduce your own delays and test your shit on staging. I'd like my upstream to be as quick as practically possible. Oracle and Alma cover that nicely.

All this might have changed in the meantime.

I don't mean Optional, it was never intended for widespread use, according to its own author. It's solvable by using annotations; uber has a solution that allows you to only annotate nullable fields, and the rest is assumed to be (and checked at runtime) as not null. There are never that many nullable fields in sanely designed applications.

Writing Kotlin in other IDEs is about as good as writing it in vim. Java experience is closer to the same level regardless of which of the big three (or two…) you prefer.

I recently finished (however much you can "finish" software) a project in Kotlin and probably won't be using it in the future. Compilation time, although much improved by recent releases, is still twice as slow as Java, you only get decent support for the language in IDEA (which makes sense since the officially stated goal of releasing Kotlin was to drive sales of their IDEs), and feature-wise the only thing it really has over Java is null safety, which is solvable through other means.

You get all the other problems of using a "guest" language (of which there have been many before — most of them long dead) like the disconnect between read-only data classes and records, which necessitates the use of @JvmRecord when you need specifically a record. This disconnect between the language and the JVM too will continue to widen.

Ubuntu ships multiple runtimes for every supported distribution and does backports FWIW.