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.
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.
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.
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.