Not to say that it's impossible to write exactly as fast code in Kotlin as in Java (or faster - thanks to its inline functions: https://kotlinlang.org/docs/reference/inline-functions.html), there are a few reasons why it requires greater discipline to do so in Kotlin than in Java: 1) It's collection types List<Int>, Map<Long, Double> are natural to use and too easy to forget to use fastutil's primitive collections. However, this is currently an issue in Java code, too: see https://github.com/apache/incubator-druid/issues/6861. 2) Collection transformations are eager on each step by default, so you have not to forget to insert `.asSequence()` in the beginning of a multi-step transformation to avoid creating excessive garbage 3) companion object's methods are actually instance methods (not statics), so you have not to forget to add @JvmStatic annotation.
On Sat, 12 Oct 2019 at 09:43, Julian Hyde <jh...@apache.org> wrote: > 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 > >
