> And C is a "slightly cleaned-up assemble with a bit of syntax sugar".

Going from machine-specific assembly to crossplatform C was a huge killer feature at the time.

> I am curious why do you say Scala and Ceylon have killer features, what are those features that Kotlin doesn't have?

Higher-kinded types and/or union types. Those are the real game-changers, even if they don't look like it in simple examples. More concretely, the real value proposition for moving from Java to Scala or Ceylon is "replace all your magic annotation/XML-based proxying/bytecode manipulation with ordinary library functions that follow the ordinary rules of the language".

The term "killer app" refers to an app so amazing, people buy your platform just to use that one app. A killer language feature would be a feature so amazing, people use your language just to get that one feature irregardless of the rest.

One property of a killer app is that people tend to know it when they see it. You don't normally need to educate people as to why they want your app, they already know they do.

Kotlin does have a whole bunch of features and particularly DSL features (with more added in 1.1) to allow usage of "ordinary functions" in places where previously you might have used annotations or bytecode generation.

But in practice the market doesn't seem to value these things all that highly, perhaps because most of the time, people are writing ordinary code that doesn't benefit much from them. It's tough to claim something is a killer feature when people aren't saying "We use Ceylon because it has HKTs" (by 'people' here I mean, more than one or two bloggers).

If you look at any discussion of Kotlin then people do tend to identify killer features for them, but they're not normally type system features, they're more like interop or tooling related features. Ceylon and Scala teams recognise the importance of these things too, but the relative prioritisations have been different, so it isn't surprising that the results appeal to different market segments.

> The term "killer app" refers to an app so amazing, people buy your platform just to use that one app. A killer language feature would be a feature so amazing, people use your language just to get that one feature irregardless of the rest.

Yep. That's how I feel about HKT. I'm never going to program in a language without HKT again if I can possibly help it, and I'll put up with a lot of nonsense from Scala (like the IDE situation being a choice between the one that locks up for seconds at a time and the one that puts spurious error highlights on all your code) if the alternative is not having HKT.

> One property of a killer app is that people tend to know it when they see it. You don't normally need to educate people as to why they want your app, they already know they do.

Eh maybe. The quote about "faster horses" comes to mind. What everyone wants is a language that makes it easy to say what you mean and have it come out correct. But it's hard to know what kind of language facilities would help you do that until you've worked with them - and not just done some small examples but written a real line-of-business app while making a real effort to work with the grain of what those features give you.

But is raw HKT enough or is what you really want libraries like scalaz?

I think people can imagine new type system features more easily than you think. But this stuff has been studied:

http://sns.cs.princeton.edu/docs/asr-oopsla13.pdf

Programmers don't tend to value new type system features that highly. I don't think it's to do with ignorance. I'm well aware of Haskell's newtype and would like it on the JVM/with Kotlin, as I think it's easier to write correct software when you have that feature. but I'm not going to pick a language based only on that. The incremental benefit just isn't all that large.

Access to a giant number of quality libraries, though, that is in fact a killer feature. I'll use a language just to get access to libraries. Like how people use Scala just because of Spark or Java because of Hadoop or because they want to write a Minecraft mod.

ScalaZ is trivial once you have the concepts, I can and have reimplemented all the parts of it I need (repeatedly in fact). The same goes for Shapeless - it's good to have a standard definition of these things, but there's really not that much to them, they're actually very small libraries. I need HKT because now that I have HKT in my mental toolkit I'll think of solutions to my requirements in terms of them, and it's really painful to have to manually expand out if the language doesn't let me write down the description I have.

> ScalaZ is trivial once you have the concepts

So are quantum mechanics and string theory.

And... everything, really. Everything is trivial once you have the concepts. That's a tautology.

Look, I understand the value of higher kinded types and I really enjoy the kind of Haskell code I write when I make use of them. It's abstraction and reusability at its pinnacle. It feels great.

But by calling it a "killer feature", you are showing that you lost track with the real world and you forgot how long it took you to get there, and whether it's really necessary to be productive at your day job.

Everything is driven by real-world, day job productivity. Just yesterday I sketched out how to implement EitherT to a colleague at my day job (which bans ScalaZ) - not as an abstract exercise but because he was writing some code that he could tell ought to be expressible more simply than it was.

Not being permitted to use ScalaZ really doesn't matter - this is not the first job where I've had to reimplement it and I doubt it'll be the last. EitherT is a triviality, it's a couple of lines in any language with HKT. I could write it in my sleep (and not because I'm some super-smart developer; virtually anyone who's used EitherT could). The same goes for everything in ScalaZ really, at least all the useful parts - the things in it are remarkable not for any complex logic they contain but for the lack of any such logic. In many cases once you've conceived of the type signature the implementation requires no further thought at all. (In the Haskell world they even have a tool, djinn, for generating that kind of thing). But not being able to write the thought down would be a real pain - we'd have to write longer code which would cost the client in the short term, and that longer code would obscure the important parts and be less maintainable, which would cost the client more in the long term.

I mean that's the real proof that the killer feature is not ScalaZ itself but the type-system feature - the fact that I'm willing to take a job where ScalaZ is banned, but wouldn't take one in a language without HKT.

> Higher-kinded

I made small research and I see higher-kinded types very similar to generics, what is the main difference?

> union types

You have Multiple Inheritance in kotlin, which does more or less the same.

> the real value proposition for moving from Java to Scala or Ceylon is "replace all your magic annotation/XML-based proxying/bytecode manipulation with ordinary library functions that follow the ordinary rules of the language"

I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too. Sorry, it doesn't make any sense to me the sentence. Can you explain it?

> I made small research and I see higher-kinded types very similar to generics, what is the main difference?

Higher-kinded types mean you can have type parameters that are themselves parameterized. E.g. in Java (or Kotlin) you can do

    interface MyType<T> {
      T something();
    }

and you can have a MyType<List<String>> where something() returns List<String>. But you can't do

    interface MyType<T<_>> {
      T<String> something();
      T<Integer> somethingElse();
    }

and have a MyType<List> where something() returns List<String> and somethingElse() returns List<Integer>.

> You have Multiple Inheritance in kotlin, which does more or less the same.

Only if you control the classes involved, and most of the time you don't - I can't see any way to create a union where one of the types is from an external library, not even by making them both subtypes of a common interface. (Particularly frustrating since Kotlin supports extension methods, which have all the same complexity for the reader, but as far as I can see you can add a method to a library type but you can't add an interface onto it). (Also Ceylon's native union types are nicer than subtypes).

> I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too.

What I mean is, real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML. E.g. Spring/Guice, Hibernate/JPA, Jersey, Jackson, Quasar... . It's worth saying that this happens for a good reason: Java isn't expressive enough to practically express functionality that people need, and thus they resort to using these techniques instead (the realistic alternatives are callback hell, dropped transactions, copy-pasted code...). But HKT (and related/similar functionality) give you enough expressiveness to replace these things with plain old code.

Thanks for the explanation.

I think higher-kinded types is one of those things that make me not like Scala. I cannot think about an use case, but there should be few.

> Only if you control the classes involved

You see it like a problem, I see it like a good practice. You should do whatever you want with code that wasn't meant for something else. There were a long discussion in the kotlin forums about this.

> real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML

I see this in Python, Ruby and other languages. Real-world codebases are similar.

It is clear we think different and we are not going to agree, but I liked the conversation and I learnt new things on the way. Thanks

> I cannot think about an use case, but there should be few.

Once you're used to having them in the toolbox you use them all the time.

> You see it like a problem, I see it like a good practice. You should do whatever you want with code that wasn't meant for something else.

Would you say your classes shouldn't have fields that are third-party library types? Having variants that are third-party library types is just the converse.

> I see this in Python, Ruby and other languages.

I can't speak to Ruby but I have Python experience. springpython is seen as a joke. Python decorators are actual Python functions written in normal Python, not hints to some magic framework that does the actual implementation. Metaclasses are problematic but they don't break the rules of the language to anything like the same extent as happens in the Java world.