Hacker News Reader

Comment by lmm | Hacker News Reader

> I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely.

It doesn't offer a compelling advantage. "Slightly cleaned-up Java with a bit of syntax sugar" is not enough to justify having to make all your tooling (IDEs, profilers, monitoring, code coverage ...) support a new language. And if you are going to make all that effort, why would you not pick a language that offers some genuine killer features in return, like Scala or Ceylon? And it's got a lot of special cases, a lot of stuff in the language that should just be libraries, that I think will make it hard to maintain in the long run (the "CoffeeScript of Java" line is probably fair). If anything it seems overhyped to me.

View on HN

> "Slightly cleaned-up Java with a bit of syntax sugar"

This is not an accurate description of Kotlin.

Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java.

https://kotlinlang.org/docs/reference/comparison-to-java.htm...

> Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java.

Kotlin does have nullability handling yes, but it's a very limited special-case feature - it's a language-level builtin rather than something you can use in your own libraries. E.g. if you want to have an error message in the failure case rather than just null (i.e. some kind of Result type), you can't reuse any of the null-safety functionality (whereas in Scala or Ceylon you can write the same methods to work with either optional/nullable or result-like types).

Data immutability isn't at all difficult in Java. It's tedious (sprinkling "final" everywhere), but not hard.

> it's a language-level builtin rather than something you can use in your own libraries

The only people who still think that a library approach is superior to a compiler approach are Scala users.

I'll clarify this for you: if it's a library construct, it can be ignored. And as a matter of fact, there is nothing in Scala forcing you to use `Option`. You can completely ignore it and enjoy your time diagnosing NullPointerExceptions everywhere.

When a feature is enforced by the compiler, such as Kotlin and Ceylon, you don't get any easy way out: you have to think about null cases or you will not be able to compile your code. Period.

You're conflating two different issues. Yes, Scala allows null and yes, this is unfortunate, though it raises the question of whether there's any better way to do Java interop (you can either assume all Java calls are non-null unless checked, assume all Java calls are nullable and force checking, or trust annotations; all these approaches suck in their own way). It can be mitigated with WartRemover.

But the right way to represent absence - whether you call it null or option or something else - is clearly with a normal type that follows the normal rules of the language, not a special language-builtin type with special language-builtin rules. Some light syntactic sugar for commonly-used types makes sense (like Ceylon's "?"), but what it desugars to should always be something you could write a normal library type for. Indeed if your language doesn't let you implement the constructs you need for this kind of type in a custom type in a library, that should be a red flag that your language isn't expressive enough for general-purpose use.

> (you can either assume all Java calls are non-null unless checked, assume all Java calls are nullable and force checking, or trust annotations; all these approaches suck in their own way)

Agreed, which is why Kotlin has explored all of these options and ending up implementing neither.

Look up "platform types".

Oh my god. I didn't think it was possible to do worse than all three approaches I mentioned, but they found a way.

> Platform types are non-denotable, meaning that one can not write them down explicitly in the language.

> "Slightly cleaned-up Java with a bit of syntax sugar"

And C is a "slightly cleaned-up assemble with a bit of syntax sugar". I think kotlin has a lot of features that Java (even Scala an Ceylon) doesn't have, moreover it forces you to use good patterns when programming (it got a lot of ideas of effective java book).

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

Personally I have used Scala and I prefer kotlin over it, even Java over Scala.

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

> And if you are going to make all that effort, why would you not pick a language that offers some genuine killer features in return, like Scala or Ceylon?

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.

Scala because it's too different from Java for many Java programmers to be able to jump in and be immediately productive. 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.

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

Reply on news.ycombinator.com