13 ms·

It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm. So while Scala doesn't have to fear Java's

It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm. So while Scala doesn't have to fear Java's evolutions, Kotlin seems to be risking obsolescence when Java gets good enough - and it's already happening with Java 8. Just look at the article: they talk about Kotlin as a good language for people stuck with Java 6.

incepted 11y ago
> but still very limited compared to Scala. The fact that Kotlin has fewer features than Scala is what makes it appealing to me. Scala has become a kitchen sink with too many features, it's kind of the C++ of the 21st century in that respect.
- kbenson 11y ago
  I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?
  - zck 11y ago
    A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.
    - kbenson 11y ago
      Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane. I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated. I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
      - curun1r 11y ago
        For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable. Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness. Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im]. My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
        kbenson 11y ago
        I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise. I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case). Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.
  - nine_k 11y ago
    Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently. Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.
    - kbenson 11y ago
      If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO. It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective). > BTW, Odersky himself admits it. Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.
      - tormeh 11y ago
        The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.
        deleted 11y ago
        [deleted]
        incepted 11y ago
        > The reason Scala has so many features is that it chooses to be 100% compatible with Java, Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.
  - cousin_it 11y ago
    Language design is an exercise in balance between features and guarantees. More features = fewer guarantees and vice versa.
    - kbenson 11y ago
      It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).
- bad_user 11y ago
  I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea. This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM. As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice. On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)
  - deleted 11y ago
    [deleted]
  - incepted 11y ago
    > you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking. Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools. I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.
    - whateveracct 11y ago
oweiler 11y ago
Compared to Java 8 Kotlin still has quite a lot to offer: * Type-safe DSLs * Named parameters with default values * Non-nullable types * Raw strings (which make working with regular expressions quite nice) * Type inference * Properties * Smart casts * the when keyword which is much better than using switch statements * data classes (very nice when working with APIs which expect Java beans) * a lot of stuff I probably forgot
- rattray 11y ago
  first-class functions is another big one
  - pohl 11y ago
    That was the headline feature of Java 8.
    - NhanH 11y ago
      Java functions are still not first class. The headline feature of Java 8 was lambda function, which arguably isn't first class either (they are implemented as instances of object subtype, so essentially still is object nonetheless)
      - adrusi 11y ago
        They also don't close over their parent scope.
        deleted 11y ago
        [deleted]
        jnericks 11y ago
        // this hack is gross final String[] val = new String[1]; Callable func = () -> val[0] = "Hello"; func.call(); System.out.print(val[0]);
      - 11y ago
yiyocx 11y ago
The key point is that Android will never be on par with the latest version of Java. Scala has a lot of great features but its size and the learning curve is bigger than Kotlin. It's easier to start right now to develop with Kotlin instead Scala.
- justthistime_ 11y ago
  You could also just use Java.
  - kuschku 11y ago
    No, that was the first argument – android will soon be 3 versions behind Java, it already is using Java 6 compiled for Java 5 bytecode. The distance is getting worse with every day.
    - georgemcbay 11y ago
      It also supports a couple of Java 7 features... but... I totally agree with your point here. This far past the Oracle lawsuit and the increasing divergence between "real Java" and "Android Java", it is actually kind of bizarre Google hasn't really presented any kind of useful guidance on what they plan to do moving forward (unless their plan is actually to just keep limping along with a gimped Java implementation indefinately). It is hard not to look at things like Swift and wish Google would make a similar push to update the "offical" Android language. Technically speaking, Kotlin is a great alternative, but without the sort of official blessing Swift has coming from Apple, for most developers it will be politically very difficult to get by the inertia that appears when suggesting you use a "non-standard" language, regardless of how interoperable it is technically. Outside of really lean startups you might as well be asking to write your app in brainfuck if it isn't going to be in Java.
      - pjmlp 11y ago
        This is the proof that Sun was right all along and Google just played a Microsoft on them. Oracle might have chosen some dubious arguments, but the reality is that Google forked Java and doesn't have any will to improve developer's lifes. Before anyone replies how Jonathan praised Google, check Gosling history how things really went.
krschultz 11y ago
Keep in mind the world's largest operating system is stuck with Java 6.
- deleted 11y ago
  [deleted]
coldtea 11y ago
>It feels to me like a better Java, but still very limited compared to Scala That sounds very good. Scala overdid it.
- justthistime_ 11y ago
  To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features.
  - lann 11y ago
    > To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features. That sounds very good. Scala overdid it.
    - biggestbob 11y ago
      You are wrong.
    - justthistime_ 11y ago
      Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost. In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.
      - mike_hearn 11y ago
        Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.
tomjen3 11y ago
Java will never get good enough - for one it will always have checked exceptions and undesirable casting syntax, not to mention no native getters/setters.
pron 11y ago
> It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm. You've basically summarized Kotlin's design goals. Java was designed to be a simple language for widespread use, hiding an extremely powerful runtime beneath it. The very first paragraph describing its design reads[1]: Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea. So: 1/ not PhD thesis material, 2/ familiar, 3/ adopt tried-and-true solutions. Scala's design is the exact opposite of each and every one of these goals, but Kotlin tries very much to follow them. As such, they are very different languages (even though they share many features) because they are guided by opposite philosophies, and are therefore meant for completely different audiences. Kotlin aims to be exactly what Java would have been if it had been designed today; Scala aims to be something completely different. [1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

incepted 11y ago

> but still very limited compared to Scala. The fact that Kotlin has fewer features than Scala is what makes it appealing to me. Scala has become a kitchen sink with too many features, it's kind of the C++ of the 21st century in that respect.

kbenson 11y ago
I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?
- zck 11y ago
  A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.
  - kbenson 11y ago
    Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane. I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated. I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
    - curun1r 11y ago
      For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable. Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness. Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im]. My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
      - kbenson 11y ago
        I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise. I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case). Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.
- nine_k 11y ago
  Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently. Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.
  - kbenson 11y ago
    If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO. It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective). > BTW, Odersky himself admits it. Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.
    - tormeh 11y ago
      The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.
      - deleted 11y ago
        [deleted]
      - incepted 11y ago
        > The reason Scala has so many features is that it chooses to be 100% compatible with Java, Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.
- cousin_it 11y ago
  Language design is an exercise in balance between features and guarantees. More features = fewer guarantees and vice versa.
  - kbenson 11y ago
    It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).
bad_user 11y ago
I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea. This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM. As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice. On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)
- deleted 11y ago
  [deleted]
- incepted 11y ago
  > you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking. Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools. I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.
  - whateveracct 11y ago

oweiler 11y ago

Compared to Java 8 Kotlin still has quite a lot to offer: * Type-safe DSLs * Named parameters with default values * Non-nullable types * Raw strings (which make working with regular expressions quite nice) * Type inference * Properties * Smart casts * the when keyword which is much better than using switch statements * data classes (very nice when working with APIs which expect Java beans) * a lot of stuff I probably forgot

rattray 11y ago
first-class functions is another big one
- pohl 11y ago
  That was the headline feature of Java 8.
  - NhanH 11y ago
    Java functions are still not first class. The headline feature of Java 8 was lambda function, which arguably isn't first class either (they are implemented as instances of object subtype, so essentially still is object nonetheless)
    - adrusi 11y ago
      They also don't close over their parent scope.
      - deleted 11y ago
        [deleted]
      - jnericks 11y ago
        // this hack is gross final String[] val = new String[1]; Callable func = () -> val[0] = "Hello"; func.call(); System.out.print(val[0]);
    - 11y ago

yiyocx 11y ago

The key point is that Android will never be on par with the latest version of Java. Scala has a lot of great features but its size and the learning curve is bigger than Kotlin. It's easier to start right now to develop with Kotlin instead Scala.

justthistime_ 11y ago
You could also just use Java.
- kuschku 11y ago
  No, that was the first argument – android will soon be 3 versions behind Java, it already is using Java 6 compiled for Java 5 bytecode. The distance is getting worse with every day.
  - georgemcbay 11y ago
    It also supports a couple of Java 7 features... but... I totally agree with your point here. This far past the Oracle lawsuit and the increasing divergence between "real Java" and "Android Java", it is actually kind of bizarre Google hasn't really presented any kind of useful guidance on what they plan to do moving forward (unless their plan is actually to just keep limping along with a gimped Java implementation indefinately). It is hard not to look at things like Swift and wish Google would make a similar push to update the "offical" Android language. Technically speaking, Kotlin is a great alternative, but without the sort of official blessing Swift has coming from Apple, for most developers it will be politically very difficult to get by the inertia that appears when suggesting you use a "non-standard" language, regardless of how interoperable it is technically. Outside of really lean startups you might as well be asking to write your app in brainfuck if it isn't going to be in Java.
    - pjmlp 11y ago
      This is the proof that Sun was right all along and Google just played a Microsoft on them. Oracle might have chosen some dubious arguments, but the reality is that Google forked Java and doesn't have any will to improve developer's lifes. Before anyone replies how Jonathan praised Google, check Gosling history how things really went.

krschultz 11y ago

Keep in mind the world's largest operating system is stuck with Java 6.

deleted 11y ago
[deleted]

coldtea 11y ago

>It feels to me like a better Java, but still very limited compared to Scala That sounds very good. Scala overdid it.

justthistime_ 11y ago
To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features.
- lann 11y ago
  > To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features. That sounds very good. Scala overdid it.
  - biggestbob 11y ago
    You are wrong.
  - justthistime_ 11y ago
    Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost. In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.
    - mike_hearn 11y ago
      Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.

tomjen3 11y ago

Java will never get good enough - for one it will always have checked exceptions and undesirable casting syntax, not to mention no native getters/setters.

pron 11y ago

> It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm. You've basically summarized Kotlin's design goals. Java was designed to be a simple language for widespread use, hiding an extremely powerful runtime beneath it. The very first paragraph describing its design reads[1]: Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea. So: 1/ not PhD thesis material, 2/ familiar, 3/ adopt tried-and-true solutions. Scala's design is the exact opposite of each and every one of these goals, but Kotlin tries very much to follow them. As such, they are very different languages (even though they share many features) because they are guided by opposite philosophies, and are therefore meant for completely different audiences. Kotlin aims to be exactly what Java would have been if it had been designed today; Scala aims to be something completely different. [1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....