Do we need optionals in OOP?


After developing a modest side project in both languages (roughly two to three thousand lines of code), I can say that golang is much faster. The time to the correctly working project was about the same between the two.
Golang doesn’t interfere with my freedom of expression.

Rust actively prevents me from making decisions I’ll come to regret.

Surprisingly, after dabbling in Rust, I’ve received compliments on the way I code in C.

Of course, this is all just hearsay and my own personal experience.

The excitement I once felt about the null handling in Scala and Kotlin has faded somewhat.
The phrase “without null” is, to begin with, a complete fabrication. Each of them is null. There’s really no way around it; they’ll have to. You’ll need null if you want to communicate with the JDK, as it’s used extensively within the JDK.

Now, however, they do have tools at their disposal to streamline the process of dealing with null. Both of these creations are impressive in their design. (Especially Kotlin’s, though perhaps I’m missing out on something great in Scala 3 because I haven’t tried it yet. I just think “we’re going to openly acknowledge it and tame it as much as we can” sounds better than “we’re going to try to sweep it under the carpet” in terms of aesthetics. But there’s a sort of Amdahl’s Law analogue hiding in that situation: the upper bound on how much practical null safety you can achieve is constrained by how much you can avoid relying on modules that were written in Java. Having to rely on even a small amount of code written in languages like C makes it clear to me that the same is true of languages like Haskell. However, since working directly with Java code is less unusual in Scala and Kotlin, it no longer concerns me as much.

Option types, in my opinion, are completely unnecessary in object-oriented languages. There are exceptions, but they tend to fall into “proves the rule” territory. OCaml, for example.
Not just because of the null problem. It’s not just that dealing with options requires you to adopt a “conditional logic everywhere” mentality. In a functional language, and perhaps even a procedural one, that makes perfect sense. However, this is the antithesis of good OOP.