Pre Valhalla   | Valhalla

  sumSimple       328,110 us/op  | 327,927 us/op

  sumOptionalLong 1201,987 us/op | 326,949 us/op

  sumNulls        570,800 us/op  | 584,967 us/op

  sumOptional     2223,887 us/op | 572,833 us/op

Normal usage of this stuff is not going to cause any more issues than trigger the OCD of people that obsess about this stuff. And in the rare case that you do have an issue, you can do something more optimal indeed.

System.out.println(Integer.valueOf(22) == Integer.valueOf(22)); // true

System.out.println(Integer.valueOf(2200) == Integer.valueOf(2200)); // false

Which is a bit confusing to say the least. I realize one should never be using == with objects, but still.

In nutshell, on my old i5 2500k:

ints 0.6ns/op

cached Integer 0.6ns/op

boxed Integer 1.3ns/op

OptionalInt 3.5ns/op

Optional<Integer> 4.2ns/op (time includes boxing the int)

Where an op is getting the number, checking it, then an addition.

For hot loops inside a jmh benchmark, you can use @OperationsPerInvocation(MAX) and it will spit out the results in this more readable format for the time just inside the loop.

The post your link links to explains exactly how they intend to avoid this problem.

For what it's worth, Java's also got this class: https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

Although in practice there isn't much performance difference in my experience.

Yes, I was working with code once which wrapped string IDs into a FooId object (a good idea in principle) and all of the following had different meanings:

    FooId x = null;
    FooId x = new FooId(null);
    FooId x = new FooId("");
    FooId x = new FooId(...an actual ID...)

I'm so glad I left that company...

In fact it is mostly the opposite, all the Kotlin concepts that don't exist in Java (the language), need additional bytecodes to fake their semantics on top of JVM bytecodes optimized for Java semantics.

Like functions, lazy initializations, delegation, or co-routines.

So this test is as “unfair” as benchmarking Rust’s allocation performance against Java, for example

NonMinI32 could also be interesting as a symmetrical number type, representing [−2³¹ + 1, 2³¹ − 1] and leaving the bit pattern 0x80000000 for niche optimisations.

Combine those annotations with a linter + pipeline that marks nullability warnings as errors and you've come pretty close to Kotlin's advantages. Of course, Kotlin also has some more advanced mutability controls and other advantages that Java doesn't get for free.

When it comes to simple values, null vs non-null can be solved by using primitives (long) instead of objects (Long), as primitives can never be null.

Disagree. The Kotlin way of doing it leads to really subtle bugs in generic code, because T? is usually different from T but sometimes it's not. (For example, if you write a generic cache that caches the result of f(x) in a map, it's really easy to accidentally write code that doesn't cache the result if it's null, and not notice).

Also a lot of the time you don't actually want Optional, you want Either, because you want to know why the value wasn't present. Either is really limited in Kotlin.

1. They are not composable (can't map or flatmap or fold/reduce them).

2. They can only represent one extra value, if you need more, you are back to square one (eg. you can't return an error value, only the fact that there is no value).

If we make another step, one could argue that even optionals are lacking, one should model the possible domain values with sums and products in such a way that no nulls or optionals are required. Do not try this in a language with such a basic type system as Java or even Kotlin though, you will run into the limits of the type system almost immediately.

Is Kotlin better because it works out of the box or are there differences in the feature set?

Disagree. If you don't PUT the nulls into the language, you don't need a brigade of PhDs to develop the static analysis to tell you whether you have nulls.

I'm sick of worshipping at the altar of backward compatibility. Just because we used to choose to include nulls doesn't mean we need to keep choosing to include them.

Nullable<T> itself is not exactly the same as Option<T> since it does not cover types that already allow nulls. It adds nulls rather then removing them.

Many people roll their own Option<T> or Result<T,E> type, since it's easy enough to start, and it's usually a class type.

1) https://learn.microsoft.com/en-us/dotnet/api/system.nullable...

2) https://github.com/mcintyre321/OneOf/blob/master/OneOf/OneOf...

https://sharplab.io/#v2:EYLgtghglgdgNAFxBAzmAPgAgLACgACATAMx...

Note that "Long" in Java can be null because it is boxed, "long" (lowercase) however cannot be null, but it also can't be Optional<long>. Java sucks :)

EDIT: I'd love to see a C# version of this.

> The task was to compute a sum of all the numbers, skipping the number whenever it is equal to a magic constant. The variants differ by the way how skipping is realized:

> 1. We return primitive longs and check if we need to skip by performing a comparison with the magic value directly in the summing loop.

> 2. We return boxed Longs and we return null whenever we need to skip a number.

> 3. We return boxed Longs wrapped in Optional and we return Optional.empty() whenever we need to skip a number.

Seems pretty reasonable to me.

This also applies to null/Maybe as well: both would violate the principle of least surprise (e.g. the AWS DynamoDB SDK has queries return an 'Array<Item>'; but this is 'null' if there are no matches!). It also complicates the domain model, making two distinct forms of empty value ('None' versus 'Some(List())'; or '[]' versus 'null'), which may not have any semantic difference.

> You should almost never use it as a field of something

I agree, although it's often preferable to expose methods rather than fields anyway; in which case it's a return value, which seems OK.

> or a method parameter

Sure, that's what polymorphism/overloading is good for, e.g. instead of `foo(int arg1, Optional<String> arg2)` we can have separate `foo(int arg1, String arg2)` and `foo(int arg1)` definitions (where the latter will probably call the former with some default).

> I think routinely using it as a return value for getters would definitely be over-use

I agree, since that would indicate our model is too weak, and missing some domain-relevant information. For example, if many of our 'Order' methods return optional results, there's probably a finer-grained distinction to be made, like 'PendingOrder', 'FulfilledOrder', etc. which don't need the optional qualifiers.

(Personally I try to avoid the term "getter": APIs should make sense without reference to their underlying implementation; whether that happens to be "getting" a field, or calling out to some other methods/objects, etc. That's the point of encapsulation :) )

Say how a general-purpose Maybe type in Java would be different than Optional.

"We made a vehicle with an engine and four wheels but never intended it to be a car."

    foo?.Bar(baz);

   var result = foo?.Bar(baz);