I'm glad you brought up Kotlin. Its approach to nullable types is elegant and pragmatic. If a string argument allows nulls, you give it type 'String?'; if not, give it type 'String'[1]. Unlike Scala's Option or Java's Optional, the arguments have the same runtime type; the difference between 'String?' and 'String' is handled by the compiler and has no runtime overhead.
As far as I can tell, Kotlin is as efficient as Java (since most of its features are syntactic sugar around Java features, and you can avoid extensions like delegates and receivers). There's no reason to only "write non-performance critical parts of code and tests in Kotlin". There are, however, plenty of other good reasons to keep Druid in good old Java. Better the devil you know. Julian [1] https://kotlinlang.org/docs/reference/null-safety.html On Fri, Oct 11, 2019 at 5:16 AM Roman Leventov <leventov...@gmail.com> wrote: > > A few notes: > > (1) There is a very long-running project towards fixing static nullability > problems (identified by IntelliJ). The way of fixing is always properly > using/not using @Nullable and annotating all packages in the project > with @EverythingIsNonNullByDefault (see > https://github.com/apache/incubator-druid/pull/5957#discussion_r206792747, > https://github.com/apache/incubator-druid/pull/8198). I don't believe this > project will ever complete. It would be nice if we were able to have > ratcheting ( > https://robertgreiner.com/continuous-code-improvement-using-ratcheting/) > for the number of "Nullability problems" inspection violations in the > project in our TeamCity build, but unfortunately, this is not currently > possible, too. > > (2) However, I think (1) is more a purism than a stressing practical need, > because I don't actually see NPE being a huge source of bugs in production. > NPEs frequently bubble up in tests when you refactor code, but then you fix > tests before committing the code. This is a slightly longer feedback loop > than if these nullability problems didn't allow you to compile the code, > but not dramatically. > > (3) With regard to nullability, it might be a better idea to make Druid a > mixed Java/Kotlin project and write non-performance critical parts of code > and tests in Kotlin. Kotlin has a very succinct syntax for handling > nullability, among other benefits. > > > On Fri, 11 Oct 2019 at 03:46, Gian Merlino <g...@apache.org> wrote: > > > For reference, a (brief) earlier conversation about this: > > https://github.com/apache/incubator-druid/issues/4275, which links to > > https://github.com/apache/incubator-druid/pull/4254#discussion_r116628607, > > which links to > > > > https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 > > . > > > > I really enjoyed programming with Scala's Option type, back when I had > > spend a couple of years writing Scala code. They are awesome. Java > > Optionals are sadly not quite as good, especially in ecosystem support > > (they're not adopted very well in libraries or in the jdk itself) but also > > in functionality (in Scala they're tightly integrated into the collections > > library, which allows for some nice idioms). > > > > After that Scala break, when I came back to Java I wrote a lot of the > > indexing service module. You can tell because it has Guava Optionals > > everywhere. I mostly used it the way that Goetz recommended, as a method > > return type in commonly used interfaces or utility methods. It was a bit > > clunky but it was overall nice. I don't regret it. But now I mostly don't > > use them anymore, and started using null-returns (with @Nullable > > annotations) instead since it jives better with the rest of the codebase. > > > > Jad, or anyone else, have you worked on Java codebases where Optional was > > heavily used? What was the experience like? > > > > Also, has anyone had experience introducing a preference for Optionals into > > a large pre-existing codebase? > > > > On Wed, Oct 9, 2019 at 12:46 PM Jad Naous <jad.na...@imply.io> wrote: > > > > > Sir Tony Hoare on inventing null while working on ALGOL (from wikipedia > > > below): > > > > > > Speaking at a software conference called QCon London > > > <https://qconlondon.com/> in 2009, he apologised for inventing the null > > > reference <https://en.wikipedia.org/wiki/Null_pointer>:[23] > > > <https://en.wikipedia.org/wiki/Tony_Hoare#cite_note-23> > > > > > > I call it my billion-dollar mistake. It was the invention of the null > > > reference in 1965. At that time, I was designing the first comprehensive > > > type system for references in an object oriented language (ALGOL W > > > <https://en.wikipedia.org/wiki/ALGOL_W>). My goal was to ensure that all > > > use of references should be absolutely safe, with checking performed > > > automatically by the compiler. But I couldn't resist the temptation to > > put > > > in a null reference, simply because it was so easy to implement. This has > > > led to innumerable errors, vulnerabilities, and system crashes, which > > have > > > probably caused a billion dollars of pain and damage in the last forty > > > years. > > > > > > How about we stop passing nulls around as method arguments, field values, > > > return values, etc and use Optional instead? Benefits: > > > - No more NPEs > > > - Better documentation through code > > > - Less mistakes > > > > > > I'm not suggesting we go rewrite everything, but rather just starting to > > > only return and accept Optionals in methods/constructors/etc. > > > > > > Jad. > > > > > > -- > > > Jad Naous > > > Imply | VP R&D > > > 650-521-3425 > > > jad.na...@imply.io > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
