It was AstroTurfed to hell and back here and on Reddit. I know that much.

> Setting aside the objections some have to exceptions generally: Checked exceptions, in contrast to unchecked, means that if a function/method deep in your call stack is changed to throw an exception, you may have to change many function (to at least denote that they will throw that exception or some exception) between the handler and the thrower. It's an objection to the ergonomics around modifying systems.

And if you change a function deep in the call stack to return a different type on the happy path? Same thing. Yet, people don't complain about that and give up on statically type checking return values.

I honestly think the main reason that some people will simultaneously enjoy using Result/Try/Either types in languages like Rust while also maligning checked exceptions is because of the mental model and semantics around the terminology. I.e., "checked exception" and "unchecked exception" are both "exceptions", so our brains lumped those two concepts together; whereas returning a union type that has a success variant and a failure variant means that our brains are more willing lump the failure return and the successful return together.

To be fair, I do think it's a genuine design flaw to have checked and unchecked exceptions both named and syntactically handled similarly. The return type approach is a better semantic model for modelling expected business logic "failure" modes.

I'm with you when it comes to checked exceptions. I have several ranty comments on this site about how everyone has been wrong to cargo-cult hatred of the feature for the last decade or so.

But, I'd still rather have safe/correct null type checking, because at the end of the day, I can always write MY code to return a Result/Try/Either type instead of throwing unchecked exceptions for expected business logic "failure" paths.

That's a fair point. You don't have to write Java with giant graphs of objects-in-objects-in-objects and heavy mixing of (often mutable) data and logic in the same classes, but it's hard to deny that the culture, conventions, and idioms in the Java ecosystem can be quite different from the culture, conventions, and idioms in Kotlin.

On the other hand, when I see Kotlin code that's not written by JetBrains (especially on the backend), it often does just look like Java code with cleaner syntax...

That's a whole huge can of worms, too. Coroutines and the suspend keyword were a great innovative feature at the time (very clever implementation on the JVM and good API design given the limitations of the implementation and syntax design constraints), but now that Java has so-called virtual threads, you don't "need" Kotlin for convenient(-ish), simple(-ish), scalable, structured concurrency like you used to, either.

One could rightly debate over whether Kotlin's coroutines design and APIs are better than Java's virtual threads for writing asynchronous code. But, at the core, the story used to be that Kotlin had coroutines and lightweight structured concurrency "built-in" (with a blessed first-party helper library for the actual concurrency part) and Java did not have anything that accomplished the same goals. Now it does.

EDIT: Forgot to confirm that I do, in fact, use Kotlin for a fairly large and moderately complex backend system (multiple deployed systems, including one HTTP REST-ish API).

I'm of two minds about it.

I started working with Kotlin back when Java was still a very ~~stagnant~~ stable language. I definitely find Kotlin's syntax to be much more comfortable, expressive, and in many ways much more simple than Java's.

But at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system (which is, admittedly, mitigated decently well in practice by Java tooling configurations and ugly annotations), and value types (zero heap-allocation wrapper classes).

Another thing to keep in mind is that now that Java is actually adding features again, the Kotlin developers will have to also play "catch-up" to Java in ways that it didn't have to when it first gained popularity. It puts Kotlin in an awkward spot when Java's implementation of sealed classes and interfaces was initially better and more flexible than Kotlin's, or when Java's `switch` is now more powerful than Kotlin's `when`, etc.

Kotlin is also betting heavily on their multi-platform stuff, which I'm skeptical about. It seems to me that it will further slow the ability to add useful features to the language if you have to cater to the lowest-common-denominator between Java and JavaScript (and Objective-C? -is that how it works for iOS?) runtimes. Instead of being the best language for a given platform, it'll just be a pretty good language for a few platforms. I wish them all the best in dethroning JavaScript from infecting every computing platform and domain, but I'm just skeptical.

So, honestly, I don't actually recommend people start new projects in Kotlin. I'd suggest going for Java, or something that's meaningfully different in semantics and philosophy like Clojure or Scala. I say this, but I'm not actually sure that I'd be able to follow my own advice, because I really don't want to have to stomach Java's syntax, idioms (way too many annotations), and stupid null handling.

Well, 4:3 is less wide than 16:9 or 16:10 or whatever else we're doing these days.

But, I do agree that this was likely never the driver. In fact, I've always thought the "obvious" explanation is simply that window controls and title bars are at the top, and since tabs are like nested windows inside a window, they would follow basically the same patterns...

I always felt the same way while I was in grad school. The fact that my tuition was covered by working as either a teaching assistant or as a research assistant on a grant, AND that I actually got a paycheck that was mostly-enough to survive on, was something that I was very grateful for.

It was not something one could live on long-term (no chance to save money whatsoever, could never buy a home or decent car, etc). But, I wasn't starving and I wasn't taking on debt.

At the same time, it is a sacrifice. Most of my friends the same age were making "real" money, buying homes, going on nice vacations, saving for retirement, etc. So, I get extra irritated and defensive when I hear people who have no idea what they're talking about repeat conspiracy theories about science and academia. If I wanted to be a rich scam artist, I'm pretty sure there were better options than a science PhD...

Is this different than how military spending is spread, though? That's not a rhetorical question- I'm not tuned in enough to know.

Even though I've seen military bases in the middle of nowhere, I've certainly seen some bases and defense contractors (Raytheon, Lockheed, etc) in non-rural areas.

I'm cynically, and pessimistically, kind of assuming that it's really just about what's being funded in this case. Military spending is pretty much always supported by both politicians and the public, whereas there is a VERY strong anti-science and anti-academia wave in our culture at the moment (even more so than I always used to think there was...).