10 ms·

That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that K

by edem 9y ago

That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.

ojosilva 9y ago
Exactly, that's what I meant. Traction is more like acceleration than it is speed.
lmm 9y ago
Kotlin is 6 years old, so about half the age of Scala - and, despite the heavy marketing, less than half the popularity on the chart in the article. We'll see what happens; Scala's growth has been slow and organic, but the flipside of that is that its success is down to the merits of its design. (There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. Kotlin has some good aspects to its design, but the anti-intellectual hostility to good formalisms and refusal to learn anything from Scala's mistakes rubs me the wrong way)
- edem 9y ago
  Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapolate the trend it you can see that it will surpass Scala within a year. Higher kinded types in themselves don't have any business value so I don't see why it can't be displaced by Kotlin or Clojure. I don't see any "anti-intellectual hostility" either. Actually I'm working on a library which wraps Clojure's STM and persistent data structures. I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy (thus it lacks direction as well).
  - lmm 9y ago
    > Higher kinded types in themselves don't have any business value They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about. > I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. What exactly is "forced on you" in Scala? > Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. That's a legitimate language design philosophy and I'm glad there are languages that pursue it, but I don't find it makes for maintainability in the long run; macros are too powerful to be able to reason about code that uses them, so for a maintainable codebase your macros need to be restricted to a subset of what's possible - and to be able to maintain that it would be better to standardize more restricted alternatives that cover the important use cases. What Scala features would you say are tacked-on? I find it very coherent, with just a few powerful, orthogonal features - it's not quite as minimal as Clojure, sure, but it feels like it's got a lot fewer special cases than Kotlin or any number of modern languages. The libraries some people have written are a lot more... variable, but that's not a sign of issues with the language - if anything it's the opposite.
    - edem 9y ago
      > They make it much easier to fulfil business requirements in a clear, maintainable way Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. > What exactly is "forced on you" in Scala? Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. > Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable. Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
- mike_hearn 9y ago
  It's 6 years old if you count from the time it started development. But nobody was seriously using it at scale until it stabilised, which was the start of last year. Judged from its 1.0 "ok you can use this now" release, it's a little under 2 years old.
  - lmm 9y ago
    Sure, but if you're measuring that way then Scala is a lot less than 13 years old.

by edem 9y ago

That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.

ojosilva 9y ago

Exactly, that's what I meant. Traction is more like acceleration than it is speed.

lmm 9y ago

Kotlin is 6 years old, so about half the age of Scala - and, despite the heavy marketing, less than half the popularity on the chart in the article. We'll see what happens; Scala's growth has been slow and organic, but the flipside of that is that its success is down to the merits of its design. (There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. Kotlin has some good aspects to its design, but the anti-intellectual hostility to good formalisms and refusal to learn anything from Scala's mistakes rubs me the wrong way)

edem 9y ago
Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapolate the trend it you can see that it will surpass Scala within a year. Higher kinded types in themselves don't have any business value so I don't see why it can't be displaced by Kotlin or Clojure. I don't see any "anti-intellectual hostility" either. Actually I'm working on a library which wraps Clojure's STM and persistent data structures. I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy (thus it lacks direction as well).
- lmm 9y ago
  > Higher kinded types in themselves don't have any business value They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about. > I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. What exactly is "forced on you" in Scala? > Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. That's a legitimate language design philosophy and I'm glad there are languages that pursue it, but I don't find it makes for maintainability in the long run; macros are too powerful to be able to reason about code that uses them, so for a maintainable codebase your macros need to be restricted to a subset of what's possible - and to be able to maintain that it would be better to standardize more restricted alternatives that cover the important use cases. What Scala features would you say are tacked-on? I find it very coherent, with just a few powerful, orthogonal features - it's not quite as minimal as Clojure, sure, but it feels like it's got a lot fewer special cases than Kotlin or any number of modern languages. The libraries some people have written are a lot more... variable, but that's not a sign of issues with the language - if anything it's the opposite.
  - edem 9y ago
    > They make it much easier to fulfil business requirements in a clear, maintainable way Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. > What exactly is "forced on you" in Scala? Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. > Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable. Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
mike_hearn 9y ago
It's 6 years old if you count from the time it started development. But nobody was seriously using it at scale until it stabilised, which was the start of last year. Judged from its 1.0 "ok you can use this now" release, it's a little under 2 years old.
- lmm 9y ago
  Sure, but if you're measuring that way then Scala is a lot less than 13 years old.