undefined | Better HN

0 pointskaba03y ago0 comments

20 years ago there were no generics, so you couldn’t have implemented it that way. You could have written a class OptionalLong { long value; boolean isSet; } at the time and that would have only a single allocation overhead. Alternatively, have an array of longs and a boolean array marking which ones are set, with a trivial wrapper object over that for essentially zero overhead.

Java’s tradeoffs are maintainability in huge teams over multiple years with relatively fast performance even if you write your code very naively, with top notch tooling, observability, etc. In the rare case you have to optimize in the hot loops you can allow to have less readable code like I mentioned.

0 comments

1 comments · 1 top-level

alkonaut3y ago

> 20 years ago there were no generics, so you couldn’t have implemented it that way. You could have written a class OptionalLong

That was the actual reason, yeah. Basically having to make IntList and so on.

> Java’s tradeoffs are maintainability in huge teams over multiple years with relatively fast performance

When I did switch to C# in 2003, it was very young. Since then generics have been bolted on and so on, but I didn't find any hit to maintainability due to this. What I do think was sad though is that when Generics were bolted on (and value types obviously were there all along), that the APIs didn't immediately include some easy and obvious wins like Option<T>. Those have been reimplemented since ad nauseam.

j / k navigate · click thread line to collapse