3 ms·

I think you're vastly underestimating the amount of work required to support a platform like Android. How many people are directly employed by either JetBrains

I think you're vastly underestimating the amount of work required to support a platform like Android. How many people are directly employed by either JetBrains or Google to work on the Android + Kotlin story, vs the total number of Typesafe/Lightbend employees at its peak... which has always been burning through VC money and is financially struggling even after focusing on their core knowledge domain. > (Also, what do you mean about convincing Google?) Google decides what Android becomes or not. What makes you think they would have been interested in Scala in the first place? Even if someone did the integration work for free (which is an insane premise), Google likes boring languages. Plus, Scala's standard library is somewhat at odds with a fast and lean mobile runtime.

klibertp 4y ago
> I think you're vastly underestimating the amount of work required to support a platform like Android. That might be so, but you're not giving me a chance to change my view. I don't know, and don't care honestly, how many people are working on what; I'm asking what did those people do, specifically, that required such an immense amount of work, and what they have to show for that effort. And of course, how many people work on developing Android itself is irrelevant - we're only talking about supporting existing compiler that targets existing implementation of a JVM in an IDE and ecosystem. Put another way: what's so impressive about Kotlin's support for Android? > total number of Typesafe/Lightbend employees at its peak... which has always been burning through VC money and is financially struggling even after focusing on their core knowledge domain. Maybe, then, focusing on their core knowledge domain, working for almost a decade on the "next version" of the language without care, then pulling Python-like 2/3 drama when it finally landed, was simply... a bad business decision? Maybe focusing effort on making the language more accessible to more people would have played out differently? (Just guessing.) > Plus, Scala's standard library is somewhat at odds with a fast and lean mobile runtime. Why? Generics and implicits are compile-time features - what's in the Scala's stdlib that is incompatible with Android APIs? What does Scala have in the stdlib that Kotlin doesn't?
- hocuspocus 4y ago
  I'm not going to try to explain why developing and maintaining tooling takes resources. However, a few things: - Lightbend isn't involved in Scala 3. - Martin Odersky has taught students for decades and knows how to make Scala more accessible. He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. He also has enough industry experience and connections to realize what matters for the ecosystem in the long run. Server middleware and big data frameworks are the perfect fit for Scala on the JVM. There's no evidence for some kind of missed opportunity between Android and Scala. - Scala's standard library is rich, heavy, focused on immutability, and not always interoperable with Java's. Kotlin's standard library is very small and heavily inlined in comparison. On a mobile platform, this matters.
  - klibertp 4y ago
    > why developing and maintaining tooling takes resources. Developing and maintaining anything takes resources, tooling is not special at all. Yet, you still didn't say what exactly does Kotlin do that's so resource-intensive that it's impossible to replicate for Scala for the reason of lack of resources only. Do you know Kotlin's tooling? > Lightbend isn't involved in Scala 3. I don't get what you mean? I mean, so what? I just opened scala-lang.org - which seems to be an official Scala web page - and the information that Scala 3.2.0 was just released is at the very top of the page. It's not like PERL and Raku. And what does it matter who is involved in what if we're talking about the tooling for the language as a whole? > Martin Odersky has taught students for decades and knows how to make Scala more accessible. Apparently not via investing in tooling, though? If you ask Matthias Felleisen[1], who happens to also have been teaching students for 40 years at this point, he'd tell you that tooling is important for accessibility[2]. > He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. I don't know who would, actually. I'm sorry, I don't understand this sentence, could you please explain what you mean by this? > There's no evidence for some kind of missed opportunity between Android and Scala. I'm sorry, but that's just you being in denial. I don't intend to dispute Martin Odersky's credentials, that's completely beside the point. The point is this: in June 2019 Scala was 28th and Kotlin was 43rd on the TIOBE Index. Now, Scala is still ahead: 33rd place vs. 34th for Kotlin. And you have to account for the fact that Kotlin is almost 7 years younger. Sorry to break it you, but that's not how a healthy language's growth looks like. Clearly, there's something wrong somewhere. My interpretation is that Scala missed many chances, and disastrously so - one of them being Android development. It's a bummer, really. I read Odersky's book in 2005, I still have the PDF. I really liked the concept of a scalable language, expressive at all levels of complexity. I learned Scala in 2009, then brushed it off in 2017. I see Kotlin for what it is: a pragmatic knock-off of Scala and Groovy. Groovy did not, but Scala had a chance to win over millions of Android developers (in addition to thousands in data centers), but blew it. I'm not happy with that. (The other great language that could have done better but largely blew it is of course Clojure (currently 47th), but then again, they had it way harder given the language's features) > Scala's standard library is > rich, I don't have a quick way of checking, could you maybe check how many classes/(other relevant entities) are there in Java and Scala respective standard libraries? I strongly suspect Java's bigger. And even that is nothing in front of Python or VW Smalltalk. > heavy, Why is it heavy and in what way? Too much code generated? Too big a JAR to include? > focused on immutability, All default (ie. used most often in idiomatic code) collections in Kotlin are immutable; the practice of favoring val over var is identical in both languages. > not always interoperable with Java's. What do you mean? These are all classes compiled to the same bytecode, how could they ever not be interoperable? Do you mean that you need to convert (for example) collections before you can call methods provided by Scala/Java-specific class? That's perfectly normal and counts as interoperability, and quite a high-class one at that (I mean, try to convert BEAM's list into Python's via C extension and you'll see what "not always interoperable" means...) > Kotlin's standard library is very small Again, can't check it easily, but yes, I get the impression that Kotlin's stdlib is a bit smaller than Scala's. Not by much though. They're both just tiny. Well, not JS-level tiny. Probably somewhere around Scheme's R7RS or OCaml. > and heavily inlined in comparison. Again, Scala compiler is supposed to be "intelligent enough" to produce code faster than hand-written Java in some cases! How come such a compiler has problems inlining the code of stdlib, arguably the most optimized code of all in any language? What weird things are happening in that stdlib that the compiler has such a hard time inlining them? > On a mobile platform, this matters. Sure. But you just said it doesn't matter for Scala, because it's happy powering server middlewares and big data frameworks, even if it means loosing out on a lot of mindshare, contributors and all that. [1] https://en.wikipedia.org/wiki/Matthias_Felleisen https://en.wikipedia.org/wiki/Matthias_Felleisen [2] https://racket-lang.org/ https://racket-lang.org/ and https://docs.racket-lang.org/drracket/interface-essentials.html https://docs.racket-lang.org/drracket/interface-essentials.h...

klibertp 4y ago

> I think you're vastly underestimating the amount of work required to support a platform like Android. That might be so, but you're not giving me a chance to change my view. I don't know, and don't care honestly, how many people are working on what; I'm asking what did those people do, specifically, that required such an immense amount of work, and what they have to show for that effort. And of course, how many people work on developing Android itself is irrelevant - we're only talking about supporting existing compiler that targets existing implementation of a JVM in an IDE and ecosystem. Put another way: what's so impressive about Kotlin's support for Android? > total number of Typesafe/Lightbend employees at its peak... which has always been burning through VC money and is financially struggling even after focusing on their core knowledge domain. Maybe, then, focusing on their core knowledge domain, working for almost a decade on the "next version" of the language without care, then pulling Python-like 2/3 drama when it finally landed, was simply... a bad business decision? Maybe focusing effort on making the language more accessible to more people would have played out differently? (Just guessing.) > Plus, Scala's standard library is somewhat at odds with a fast and lean mobile runtime. Why? Generics and implicits are compile-time features - what's in the Scala's stdlib that is incompatible with Android APIs? What does Scala have in the stdlib that Kotlin doesn't?

hocuspocus 4y ago
I'm not going to try to explain why developing and maintaining tooling takes resources. However, a few things: - Lightbend isn't involved in Scala 3. - Martin Odersky has taught students for decades and knows how to make Scala more accessible. He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. He also has enough industry experience and connections to realize what matters for the ecosystem in the long run. Server middleware and big data frameworks are the perfect fit for Scala on the JVM. There's no evidence for some kind of missed opportunity between Android and Scala. - Scala's standard library is rich, heavy, focused on immutability, and not always interoperable with Java's. Kotlin's standard library is very small and heavily inlined in comparison. On a mobile platform, this matters.
- klibertp 4y ago
  > why developing and maintaining tooling takes resources. Developing and maintaining anything takes resources, tooling is not special at all. Yet, you still didn't say what exactly does Kotlin do that's so resource-intensive that it's impossible to replicate for Scala for the reason of lack of resources only. Do you know Kotlin's tooling? > Lightbend isn't involved in Scala 3. I don't get what you mean? I mean, so what? I just opened scala-lang.org - which seems to be an official Scala web page - and the information that Scala 3.2.0 was just released is at the very top of the page. It's not like PERL and Raku. And what does it matter who is involved in what if we're talking about the tooling for the language as a whole? > Martin Odersky has taught students for decades and knows how to make Scala more accessible. Apparently not via investing in tooling, though? If you ask Matthias Felleisen[1], who happens to also have been teaching students for 40 years at this point, he'd tell you that tooling is important for accessibility[2]. > He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. I don't know who would, actually. I'm sorry, I don't understand this sentence, could you please explain what you mean by this? > There's no evidence for some kind of missed opportunity between Android and Scala. I'm sorry, but that's just you being in denial. I don't intend to dispute Martin Odersky's credentials, that's completely beside the point. The point is this: in June 2019 Scala was 28th and Kotlin was 43rd on the TIOBE Index. Now, Scala is still ahead: 33rd place vs. 34th for Kotlin. And you have to account for the fact that Kotlin is almost 7 years younger. Sorry to break it you, but that's not how a healthy language's growth looks like. Clearly, there's something wrong somewhere. My interpretation is that Scala missed many chances, and disastrously so - one of them being Android development. It's a bummer, really. I read Odersky's book in 2005, I still have the PDF. I really liked the concept of a scalable language, expressive at all levels of complexity. I learned Scala in 2009, then brushed it off in 2017. I see Kotlin for what it is: a pragmatic knock-off of Scala and Groovy. Groovy did not, but Scala had a chance to win over millions of Android developers (in addition to thousands in data centers), but blew it. I'm not happy with that. (The other great language that could have done better but largely blew it is of course Clojure (currently 47th), but then again, they had it way harder given the language's features) > Scala's standard library is > rich, I don't have a quick way of checking, could you maybe check how many classes/(other relevant entities) are there in Java and Scala respective standard libraries? I strongly suspect Java's bigger. And even that is nothing in front of Python or VW Smalltalk. > heavy, Why is it heavy and in what way? Too much code generated? Too big a JAR to include? > focused on immutability, All default (ie. used most often in idiomatic code) collections in Kotlin are immutable; the practice of favoring val over var is identical in both languages. > not always interoperable with Java's. What do you mean? These are all classes compiled to the same bytecode, how could they ever not be interoperable? Do you mean that you need to convert (for example) collections before you can call methods provided by Scala/Java-specific class? That's perfectly normal and counts as interoperability, and quite a high-class one at that (I mean, try to convert BEAM's list into Python's via C extension and you'll see what "not always interoperable" means...) > Kotlin's standard library is very small Again, can't check it easily, but yes, I get the impression that Kotlin's stdlib is a bit smaller than Scala's. Not by much though. They're both just tiny. Well, not JS-level tiny. Probably somewhere around Scheme's R7RS or OCaml. > and heavily inlined in comparison. Again, Scala compiler is supposed to be "intelligent enough" to produce code faster than hand-written Java in some cases! How come such a compiler has problems inlining the code of stdlib, arguably the most optimized code of all in any language? What weird things are happening in that stdlib that the compiler has such a hard time inlining them? > On a mobile platform, this matters. Sure. But you just said it doesn't matter for Scala, because it's happy powering server middlewares and big data frameworks, even if it means loosing out on a lot of mindshare, contributors and all that. [1] https://en.wikipedia.org/wiki/Matthias_Felleisen https://en.wikipedia.org/wiki/Matthias_Felleisen [2] https://racket-lang.org/ https://racket-lang.org/ and https://docs.racket-lang.org/drracket/interface-essentials.html https://docs.racket-lang.org/drracket/interface-essentials.h...