> Ceylon because it's a ghost town language that no one uses and that only programming language enthusiasts have even heard of. That's a catch 22 but it's the truth.
I know :(. It's just very frustrating to have seen Ceylon and Kotlin come out at roughly the same time with roughly the same goals, one better designed than the other, and then watched the other one win.
> Scala because it's too different from Java for many Java programmers to be able to jump in and be immediately productive.
Idiomatic Scala that makes extensive use of native-to-Scala libraries has this property; Scala written in a Java-like style doesn't. I think it's too early to say that Kotlin won't experience the same thing as an idiomatic Kotlin style and native-to-Kotlin libraries emerge.
> It solves problems a lot of Java programmers don't even know they have.
The fact that Kotlin isn't that much different from Java is its compelling advantage. And the places it is different, like non-null types, solve problems that almost every Java programmer is going to understand and relate to.
I think you would have to have a very finely calibrated level of attention to notice null was causing you problems and not notice that exceptions, AOP magic and the like were also causing you problems. I mean I'm sure many Java programmers regard bizarre transactionality bugs ( http://thecodelesscode.com/case/211 is a good example ) as an unfortunate fact of life rather than something to be fixed by better languages - but I expect those same people would also regard null pointer exceptions as an unfortunate fact of life.
> I mean I'm sure many Java programmers regard bizarre transactionality bugs ( http://thecodelesscode.com/case/211 is a good example ) as an unfortunate fact of life rather than something to be fixed by better languages
This is very true but I'll actually admit even I'm not clear how more powerful languages would solve the specific problem you linked. Not saying they can't, just that I don't know how they can.
> but I expect those same people would also regard null pointer exceptions as an unfortunate fact of life.
Not so sure about this one. In my experience it's pretty common for developers to ask "Why can't Java be smarter and realize I never want a NPE and instead of throwing one just automatically make the result of the line it happens on null?"
Obviously that's not the same as asking for non-nullable types but it is asking for the language to solve the NPE problem.
> This is very true but I'll actually admit even I'm not clear how more powerful languages would solve the specific problem you linked. Not saying they can't, just that I don't know how they can.
Well, it's not so much solving it as solving it practically. Even in Java it's obvious what the solution is: have a single method for performing database transactions that opens and closes the transaction so that it's impossible to get the transaction boundaries wrong (the problem the annotations were introduced to solve), and have operations that need to happen inside a transaction represented with a type that can only be used by calling that method (combined with some way of enforcing that you can't "smuggle" the database connection out of that type - or else by separating interface and implementation and ensuring that the module in which your database operations are defined simply doesn't even have access to the database libraries).
The reason people don't do this in Java is that you lose compositionality. The idea exists up to a point - it's sometimes called the "command pattern" - but if you have a bunch of functions that return commands then you need to be able to combine them to happen in a single command (so that you can run them all in the same transaction), and if you don't have that then you lose the ability to split up your code into small reusable functions. You can write functions for composing commandey functions, but you have to write them all yourself for your specific command which ends up being pretty much the same problem. To be able to have a library of functions for dealing with commands in a generic way you have to be working in a language with HKT. Ideally you also want syntax sugar for composition (in Scala, for/yield) so that you can compose command-ey functions more-or-less like regular functions.
> In my experience it's pretty common for developers to ask "Why can't Java be smarter and realize I never want a NPE and instead of throwing one just automatically make the result of the line it happens on null?"
> Obviously that's not the same as asking for non-nullable types but it is asking for the language to solve the NPE problem.
Up to a point, but I suspect they'd ask the same about exceptions. And I don't think they'll find Kotlin satisfactory in that regard either - IME this line of "magically fix it" thinking doesn't actually work, because the appropriate action takes some actual business-dependent logic to determine.
I know :(. It's just very frustrating to have seen Ceylon and Kotlin come out at roughly the same time with roughly the same goals, one better designed than the other, and then watched the other one win.
> Scala because it's too different from Java for many Java programmers to be able to jump in and be immediately productive.
Idiomatic Scala that makes extensive use of native-to-Scala libraries has this property; Scala written in a Java-like style doesn't. I think it's too early to say that Kotlin won't experience the same thing as an idiomatic Kotlin style and native-to-Kotlin libraries emerge.
> It solves problems a lot of Java programmers don't even know they have. The fact that Kotlin isn't that much different from Java is its compelling advantage. And the places it is different, like non-null types, solve problems that almost every Java programmer is going to understand and relate to.
I think you would have to have a very finely calibrated level of attention to notice null was causing you problems and not notice that exceptions, AOP magic and the like were also causing you problems. I mean I'm sure many Java programmers regard bizarre transactionality bugs ( http://thecodelesscode.com/case/211 is a good example ) as an unfortunate fact of life rather than something to be fixed by better languages - but I expect those same people would also regard null pointer exceptions as an unfortunate fact of life.