Yes, and that is really important when it comes to language use. The more people who use the language, the more it can develop and the more libraries that can be built for it.

The other advantage of Kotlin is that it builds on top of the existing Java code base. Java has had decades to build up an ecosystem of frameworks and libraries. Kotlin builds on these with excellent interop.

I like Kotlin too but in fairness this is a Ceylon thread ;)

From what I can see, Ceylon has a blend of strengths that should make it appeal to a certain segment of the market. On one hand, it's a fresh start and has a lot of the cleanness and terseness that I like from Kotlin. On the other, Gavin is clearly very much into type systems and type theory, and Ceylon has a more complex/powerful type system than Kotlin does.

I'll admit that I'm not totally sure whether the additional complexity is worth it, but I'm very open to being persuaded.

So it seems to me like Ceylon should appeal to people who currently like Scala or Haskell and push the type systems to the limit, but really want something without historical baggage like XML literals and other oddities. And I'm sure there are plenty of programmers like that.

The real question will be interop costs. Kotlin doesn't have any and that's the main reason people can consider it in existing projects, or introduction inside large corporations. Ceylon takes a more Scala-like approach where it has its own standard library, its own collections, etc.

not having interop costs also makes Kotlin much more realistically useable for Android apps, which could really help bootstrap its adoption.

Android could use a better language than Java 7 (or even 8) and Kotlin seems to be the only one that can easily replace it.

Well the thing is that Ceylon offers fantastically smooth interop with both Java and JavaScript. That's one of it's main selling features for most people.

Right, but by "interop" I didn't just mean the ability to call into Java code and vice-versa, although I admit that's the traditional definition. Scala can do that too.

What I meant is, Kotlin raised the bar in the interop department to new heights: it uses the same collection types, so there's no conversion between Java and some other SDK, but still manages to enhance them via compiler magic and extensions. It has an auto-converter tool so nobody has to waste time rewriting code that already works in order to use the new features. It can use annotation processors, etc.

Of course it also pays a fairly steep price to get that.

> but still manages to enhance them via compiler magic and extensions

The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design.

It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...

Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently.

In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to.

It may be that in the end, Kotlin succeeds where Scala struggled, simply because the Kotlin designers do a better job.

Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.)

It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago.

Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch.

    The Kotlin designers specifically call out Scala's
    mistakes when discussing why they do things differently.

Yes, I have to give them that. They (and their "fans") excel at PR, marketing and FUD.

Different languages have different design tradeoffs. I had many profitable exchanges with Andrey Breslav and other Kotlin designers. We can have a technical discussion about the design choices without getting into a fight about who is more competent.

Could you please give a few examples of "all the broken, half-designed stuff they are trying to ship"?

- extension methods

- property syntax + magic identifier

- reified

- immutable wrappers around mutable collections

- const

- multiple redundant ways of defining generic upper bounds

- companion objects + syntax

- operator/infix rules

- constantly changing nullability rules

I think you are falling into the mistake of associating what you call design with features. How features are implemented and how consistent they are with some pure notion of their role is secondary to how they serve the high-level design goals. Once you understand Kotlin's design goals you see that the features and their implementation make a lot of sense. If you think the features aim to serve another goal, then the features might seem inconsistent. Outside of academic languages, language features exist to serve particular purpose, and so their "academic" form may be compromised to serve that purpose better. There is no point in isolating features from their purpose and then arguing over them without first understanding their goal in that particular language, as the same feature can serve different (or subtly different) purposes in different languages, or a feature must be twisted in order to allow the goal to be better achieved. There is no way to say whether a feature is good or "broken" without first analyzing the language's goals, and a feature that may be bad in one language may be great in another.

As Scala (or Ceylon) has such radically different goals from Kotlin, it doesn't make much sense to discuss which features were imported and how without first understanding the why. Kotlin's designers didn't say, "I like this Scala feature but not that one"; they said, "we have this goal and this Scala feature serves it but that one doesn't". A language is not measured by what features it has, but by how those features serve its goals, and whether those goals are appropriate to begin with (i.e. provide a good cost/benefit ratio).

Sorry, but I don't plan on reading your confused ramblings.

Have I done something to offend you? Because you are being extremely rude. You are entitled to think whatever you want about my ramblings, confused or otherwise, and you are even entitled to not try to understand them or even read them at all. But your outbursts are inappropriate. Continue expressing yourself in this way and you will be banned from HN.

What's broken about extension methods? I have zero experience Scala and about a week's worth of experience with Kotlin, but so far I'm finding extension methods to be pretty straightforward and useful. What am I missing?

Extremely poor cost/benefit ratio.

Extremely poor cost/benefit ratio for what purpose? If your main goal is to adopt existing classes and libraries as your own (i.e. without any loss of functionality compared to language-native libraries), then extension methods obviously have an extremely high cost/benefit ratio. You can't analyze a feature in isolation of the language's goals. Features exist to serve a purpose, and are measured by how well they serve it.

To give an analogy, a shoulder-fired missile might have a terrible cost/benefit ratio if you're trying to hunt an antelope, but if you're trying to disable a tank, then I'd say it's cost/benefit ratio is pretty good.

Ceylon also has excellent Java/JVM (and JavaScript) interop. You should try it :)